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.
