RE: [Xen-ia64-devel] RE: [PATCH]: disable handling of legacy privified insns

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx] 
> Sent: Friday, March 17, 2006 2:48 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Subject: Re: [Xen-ia64-devel] RE: [PATCH]: disable handling 
> of legacy privified insns
> 
> Just a question: why hyperprivops need ic=0/ic=1 ?
> Since they can only occur in CPL=2, Xen could check CPL 
> instead of ic ?

Answering on-list for documentation to community...

Break instructions and the full range of break immediate
values are reserved for the guest.  Linux/ia64 only uses
one break immediate value for system calls, however other
operating systems (or future changes to Linux/ia64) may
use other break immediate values.  Thus it is unsafe for
Xen/ia64 to assume any specific break immediate value
is not used by a guest.

There are a couple of exceptions:

1) If the break immediate value matches d->arch.breakimm,
   it is assumed to be a Xen hypercall.  Currently,
   the setting for breakimm is hardcoded (0x1000) only
   in domain.c, but this was designed and all code has
   been written such that the immediate value could be
   negotiated (or verified as non-conflicting) in the
   future.

2) If a break instruction is executed with virtual psr.ic
   turned off, this is a hyperprivop.  A native OS cannot
   execute a break instruction with psr.ic off. (I suppose
   it could, but it would regret it :-)  Thus, all
   of the break immediate values are available for
   encoding hyperprivops without the possibility of
   conflicting with guests, and we have randomly chosen
   them (sequentially starting at one).  Perhaps
   another mechanism could have been used, but this one
   has a couple advantages:
   - for the highest frequency hyperprivops, virtual psr.ic
     is already off
   - setting and checking virtual psr.ic is a simple memory
     access to a TR-pinned, high-frequency location (especially
     frequent since virtual  psr.ic and virtual psr.i share
     the same 64-bit word)
   A couple of disadvantages:
   - virtual psr.ic should never be turned off without also
     turning off virtual psr.i
   - some hyperprivops are "special" (hyper_rfi and hyper_ssm_i)
     because they automatically turn on virtual psr.ic; others
     must save it (and virtual psr.i) and restore it after
     the hyperprivop is executed.

Hope that helps!
Dan


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel