RE: [Xen-devel] privileged op emulation

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Altobelli, David
> Sent: 02 June 2006 16:04
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] privileged op emulation
> 
> I'm new to this list, so please forgive me if this has 
> already been discussed or I'm way off target.
> 
> I am interested in how the XEN hypervisor handles privileged ops,
> specifically on x86 platforms.    
> 
> Looking at emulate_privileged_op(), called from 
> do_general_protection() [xen/arch/x86/traps.c], I think there 
> is a problem with how instructions are emulated. Assuming all 
> permission checks pass, the instruction is emulated.  But it 
> is emulated with XEN hypervisor context.  I believe it needs 
> to be emulated with the user's context in place.  I'm not 
> saying XEN gets the wrong answer for the specific instruction 
> (I'm worried about "out"), I'm saying that this instruction 
> might have side effects, and therefore the user's context 
> needs to be restored in registers before this instruction is 
> executed.  I believe XEN needs to validate the op, then 
> restore the users context, run the instruction, and iret to 
> the user, without modifying any registers in between the 
> instruction and the iret.

Are you in this particular case thinking of "weird" side effects like
the OUT instruction is actually causing a SMI, in which the
user-registers are being used for arguments?

In any other case, I can't see what the OTHER registers have as content
should make any difference whatsoever. 

If you are looking at SMI-sideeffects, then I would expect the code to
be likely to break in many other aspects as well. 

Note that emulate_privileged_op() is only emulating special instructions
that are done inside the OS-kernel (because the kernel runs at Ring1, so
the kernel isn't allowed to touch for example CR0, I/O ports (unless the
specific bits in TSS->IOPLMAP is set to allow it, of course). And for a
Xenified kernel, the operations are well-known and we have the source
code to look at for each case of those instructions to inspect if
there's any further need to do something. 

I'm not saying you're wrong (the opposite - you have a valid point), but
at the same time, the existing code works perfectly fine for the limited
environment that it is currently being used in. If it works, don't try
to fix it... 

--
Mats


> 
> Thanks,
> dave
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 


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