On Thu, May 24, 2018 at 07:01:04PM +0200, Radim Krčmář wrote: > 2018-05-24 18:22+0200, Paolo Bonzini: > > On 24/05/2018 18:08, Konrad Rzeszutek Wilk wrote: > > > On Thu, May 24, 2018 at 05:50:56PM +0200, Radim Krčmář wrote: > > >> If the hypercall was called from userspace or real mode, KVM injects #UD > > >> and then advances RIP, so it looks like #UD was caused by the following > > >> instruction. This probably won't cause more than confusion, but could > > >> give an unexpected access to guest OS' instruction emulator. > > > > > > What does the SDM say about this? Or does the HyperV specification give > > > a firm statement that this is the expectation ? > > > > #UD is a fault and its RIP always points to the instruction that caused > > the exception. But you of course know this already, so I'm not sure I > > understand the question. > > That was my reasoning. And for completeness, TLFS only says this: > > Hypercalls can be invoked only from the most privileged guest processor > mode. In the case of x64, this means protected mode with a current > privilege level (CPL) of zero. Although real-mode code runs with an > effective CPL of zero, hypercalls are not allowed in real mode. An > attempt to invoke a hypercall within an illegal processor mode will > generate a #UD (undefined operation) exception. Which is weird b/c I remember seeing an bug where the opposite was requested - that is VMCALL was allowed from ring 3 in Windows .. or maybe a similar bug where ring3 did a vmcall and something was not handled correctly. Either way the patch seems right.
