On Mon, Feb 01, 2021 at 09:12:47AM -0800, Sean Christopherson wrote: > On Sat, Jan 30, 2021, Jarkko Sakkinen wrote: > > On Tue, Jan 26, 2021 at 10:31:37PM +1300, Kai Huang wrote: > > > From: Sean Christopherson <sean.j.christopherson@xxxxxxxxx> > > > > > > Convert vcpu_vmx.exit_reason from a u32 to a union (of size u32). The > > > full VM_EXIT_REASON field is comprised of a 16-bit basic exit reason in > > > bits 15:0, and single-bit modifiers in bits 31:16. > > > > > > Historically, KVM has only had to worry about handling the "failed > > > VM-Entry" modifier, which could only be set in very specific flows and > > > required dedicated handling. I.e. manually stripping the FAILED_VMENTRY > > > bit was a somewhat viable approach. But even with only a single bit to > > > worry about, KVM has had several bugs related to comparing a basic exit > > > reason against the full exit reason store in vcpu_vmx. > > > > > > Upcoming Intel features, e.g. SGX, will add new modifier bits that can > > > be set on more or less any VM-Exit, as opposed to the significantly more > > > restricted FAILED_VMENTRY, i.e. correctly handling everything in one-off > > > flows isn't scalable. Tracking exit reason in a union forces code to > > > explicitly choose between consuming the full exit reason and the basic > > > exit, and is a convenient way to document and access the modifiers. > > > > I *believe* that the change is correct but I dropped in the last paragraph > > - most likely only because of lack of expertise in this area. > > > > I ask the most basic question: why SGX will add new modifier bits? > > Register state is loaded with synthetic state and/or trampoline state on VM-Exit > from enclaves. For all intents and purposes, emulation and other VMM/hypervisor > behavior that accesses vCPU state is impossible. E.g. on a #UD VM-Exit, RIP > will point at the AEP; emulating would emulate some random instruction in the > untrusted runtime, not the instruction that faulted. > > Hardware sets the "exit from enclave" modifier flag so that the VMM can try and > do something moderately sane, e.g. inject a #UD into the guest instead of > attempting to emulate random instructions. OK, thanks for the explanation! I think this would be a great addition to the commit message (as a reminder). /Jarkko
