[Top] [All Lists]

Re: [PATCH 00/18] KVM/MIPS32: Support for the new Virtualization ASE (VZ

To: David Daney <>
Subject: Re: [PATCH 00/18] KVM/MIPS32: Support for the new Virtualization ASE (VZ-ASE)
From: "Maciej W. Rozycki" <>
Date: Mon, 27 May 2013 13:45:11 +0100 (BST)
Cc: Sanjay Lal <>,,, Ralf Baechle <>, Gleb Natapov <>, Marcelo Tosatti <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <n> <> <> <> <> <>
User-agent: Alpine 2.03 (LFD 1266 2009-07-14)
On Mon, 20 May 2013, David Daney wrote:

> >   That's rather risky as the implementation of this register (and its
> > presence in the first place) is processor-specific.  Do you maintain a
> > list of PRId values the use of this register is safe with?
> > 
> FWIW:  The MIPS-VZ architecture module requires the presence of CP0 scratch
> registers that can be used for this in the exception handlers without having
> to worry about using these implementation dependent registers.  For the
> trap-and-emulate only version, there really is no choice other than to
> re-purpose some of the existing CP0 registers.

 Sure, I've just been wondering what the implementation does to make sure 
it does not go astray on a random processor out there.

 FWIW, offhand the ErrorEPC register, that's been universally present 
since MIPS III (and I doubt anyone cares of virtualising on earlier 
implementations), seems to me promising as a better choice -- of course 
that register can get clobbered if an error-class exception happens early 
on in exception processing, but in that case we're in a worse trouble than 
just clobbering one of the guest registers anyway and likely cannot 
recover at all regardless.


<Prev in Thread] Current Thread [Next in Thread>