Re: [Xen-devel] HVM x86 deprivileged mode: AMD SVM TR problem

[Ben Catterall <Ben.Catterall@xxxxxxxxxx>]

On 19/08/15 16:43, Tim Deegan wrote:
> At 16:04 +0100 on 19 Aug (1440000260), Ben Catterall wrote:
> > I've hit a blocker on getting this working for AMD's SVM and would
> > appreciate any thoughts. Hopefully I've missed a much simpler way of
> > doing this or I've missed something!
> >
> > So, AMD and Intel differ in how they handle the TR on a VMEXIT and
> > VMRUM. On a VMEXIT, Intel Save the guest's TR and then restore the
> > host's TR. AMD do not save the guest's TR nor do they restore the host's
> > TR.
> >
> > So, we need to context switch it out. The only ways that I know of to do
> > this are with the ltr and str instructions. Now, ltr will throw #GP if
> > loaded with a null selector and, when loaded, will immediately fetch
> > from the current GDT the descriptor's data.
> >
> > After issuing a VMEXIT and moving into deprivileged mode, I need a valid
> > TSS so that we can handle exceptions in ring 3, otherwise, thanks to an
> > invalid TSS selector in the TR causing a system shutdown (AMD manual),
> > the guest could crash the system.
> >
> > At the moment, I can save the guest's TR, load the host's TR and then
> > happily handle exceptions when we are in ring 3 now so that's fixed the
> > shutdown issue. But, when moving back to the guest, I have no easy way
> > to restore the TR.
> I think the CPU will load that state for you from the VMCB when
> entering the guest.  (At least, if it doesn't, I don't know how VCPU
> migration works at the moment.)  So only the VMEXIT path needs any
> attention.
This pointed me in another direction, thanks!

From what I've understood, the behaviour of VMEXIT and VMRUN 
instructions don't save/load that state from the VMCB. Though, if that's 
the case, I'd also like to know how the migration code works :).
However, AMD provides VMSAVE and VMLOAD (section 15.4.4 AMD manual 2) 
which DO save/load the TR (and other registers) but, it's an optional 
extra and Xen's entry.S for SVM doesn't use it. (I can't find any uses 
via grep in the source code either)
I guess if we use this then this alleviates much of the complexity as, 
looking at what it saves, I think we would be fine to use VMSAVE and 
VMLOAD just when we are doing a HVM depriv operation, and not need to 
call them every time we took a VMEXIT and that then gets round this problem.
Thanks!
> Cheers,
>
> Tim.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel