Re: [Xen-devel] AMD VMMCALL and VM86 mode

[Suravee Suthikulpanit <Suravee.Suthikulpanit@xxxxxxx>]

On 12/12/16 01:37, Andrew Cooper wrote:
> On 11/12/16 17:33, Boris Ostrovsky wrote:
> > ----- andrew.cooper3@xxxxxxxxxx wrote:
> >
> > > On 09/12/16 19:55, Andrew Cooper wrote:
> > > > On 09/12/16 19:55, Boris Ostrovsky wrote:
> > > > > On 12/09/2016 02:01 PM, Andrew Cooper wrote:
> > > > > > Hello,
> > > > > >
> > > > > > While working on XSA-192, I found a curious thing.  On AMD
> > > hardware, the
> > > > > > VMMCALL instruction appears to behave like a nop if executed in
> > > VM86
> > > > > > mode.  All other processor modes work fine.
> > > > > >
> > > > > > The documentation suggests it should be valid in any situation,
> > > but I
> > > > > > never get a #VMEXIT from it.
> > > > > And I assume GENERAL2_INTERCEPT_VMMCALL is set (which is what we
> > > have in
> > > > > Xen by default)?
> > > > Yes, because I have already used hypercalls to get text to the
> > > console
> > > > before entering vm86 mode.
> > > >
> > > > > What happens if you don't set it?
> > > > Let me do some hacking and see.
> > > Outside of vm86 mode, VMMCALL raises #UD, which is expected as it
> > > wasn't
> > > intercepted.
> > >
> > > From within vm86 mode, I now get #GP rather than #UD.
> > >
> > > There is certainly an argument to be made that VMMCALL inside vm86
> > > mode
> > > should trap to the vm86 monitor and #GP would be the expected way of
> > > that happening, but this also doesn't match the documentation.
> > Just curious: why do you think #GP could be a reasonable exception here?
> In vm86 mode, #GP is raised for privileged instructions which should
> break for auditing in the vm86 monitor.  It would be reasonable to
> include "talking to the hypervisor" as a privileged action.
>
> > It's #UD because if not intercepted it doesn't make sense to execute it.
> I agree with this, if privilege isn't considered an issue.  If a
> hypervisor doesn't actually get involved, the instruction shouldn't
> complete.
>
> > But either way, I think AMD should clarify this. Suravee, can you find out what 
> > the expected behavior is?
> IMO, it should either consistently #GP and break to the vm86 monitor, or
> #UD/#VMEXIT depending on whether it is intercepted by the hypervisor.
> Either way the documentation should be clarified.
>
> Having said this, given that its behaviour is consistent on any AMD
> processor I choose to try, and given that vm86 mode is very legacy these
> days, I doubt a reasonable argument can be made to fixing the behaviour.
>
> ~Andrew
So, just to confirm your observation. When executing VMMCALL in vm86 
mode with the hypervisor is set to intercept VMMCALL and not-intercept 
VMMCALL, you are seeing #GP in both cases or just in the later?
According to the HW folks, in the vm86 mode, we should observe the same 
behavior as in protected mode. (e.g. #UD in guest if not intercept 
VMMCALL, and #vmexit if intercept)
Could you please describe how you are reproducing this behavior? What 
processors are you using to reproduce this behavior?
Thanks,
Suravee

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel