On Mon, Sep 13, 2021, Xiaoyao Li wrote: > On 9/10/2021 2:59 AM, Sean Christopherson wrote: > > Yes, and no longer being able to run the vCPU is precisely the problem. The > > condition(s) matters because if there's a possibility, however small, that enabling > > NOTIFY_WINDOW can kill a well-behaved guest then it absolutely cannot be enabled by > > default. > > For now, no condition will set it. For future, I believe it will be set only > for some fatal case. However, we cannot guarantee no silicon bug to break a > well-behaved the guest. Maybe let's make it opt-in? Ya, I think an off-by-default module param makes sense. > > > Either KVM_BUG_ON() or a specific EXIT to userspace should be OK? > > > > Not if the VM_CONTEXT_INVALID happens while L2 is running. If software can trigger > > VM_CONTEXT_INVALID at will, then killing the VM would open up the door to a > > malicious L2 killing L1 (which would be rather ironic since this is an anti-DoS > > feature). IIUC, VM_CONTEXT_INVALID only means the current VMCS is garbage, thus > > an occurence while L2 is active means that vmcs02 is junk, but L1's state in vmcs01, > > vmcs12, etc... is still valid. > > > > Maybe we can kill the L2 when VM_CONTEXT_INVALID happens in L2. Ya, synthesizing a nested EXIT_REASON_TRIPLE_FAULT and sanitizing vmcs02/vmcs12 is the least awful solution I can think of. I could have sworn I suggested as much, but apparently that thought never made it from my brain to the keyboard.
