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

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

> > 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.
> This is what I don't understand.
> 
> Hyperprivops should only occur in Linux, shouldn't them ?

Do you mean that they should only occur in guest kernel
mode and never in guest user mode?  Yes, I agree.
 
> The Linux kernel doesn't use the break instructions for 
> itself, does it ?

I don't know about current kernels, but certainly in past
Linux/ia64 kernels, Linux uses break instructions.  If I
recall correctly, launching a kernel thread required a
pl0 system call via a break instruction.

> So, if I am correct the linux kernel could use break insns 
> without ic=0/ic=1 
> for hyperprivops.
> 
> I really think this could work for linux.
> What about other OS ?  I don't see why they would use break 
> in kernel mode.
> The only exception may be debugger/single stepping.

I agree a kernel debugger might use break instructions
with pl=0.

Is there a reason you are proposing to change the design
of hyperprivops?  I realize that the few hyperprivops you
just implemented are a bit ugly because it is necessary
to save/restore virtual psr.ic and virtual psr.i, but
these were never previously implemented as hyperprivops
because they were relatively low frequency.  The virtual
psr.ic trick works nicely for the high frequency ones.

Do you think the pl=2 approach will yield a significant
performance advantage?  Or is there some other reason?

Thanks,
Dan

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