On Wed, May 08, 2019 at 04:38:10PM -0700, Nadav Amit wrote: > > On May 8, 2019, at 4:21 PM, Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > > > From: Nadav Amit <nadav.amit@xxxxxxxxx> > > Date: Wed, May 8, 2019 at 10:47 AM > > To: Paolo Bonzini > > Cc: <kvm@xxxxxxxxxxxxxxx>, Nadav Amit, Jim Mattson, Sean Christopherson > > > >> From: Nadav Amit <nadav.amit@xxxxxxxxx> > >> > >> Intel SDM 26.6.5 says regarding interrupt-window exiting that: "These > >> events wake the logical processor if it just entered the HLT state > >> because of a VM entry." A similar statement is told about NMI-window > >> exiting. > >> > >> However, running tests which are similar to verify_nmi_window_exit() and > >> verify_intr_window_exit() on bare-metal suggests that real CPUs do not > >> wake up. Until someone figures what the correct behavior is, just reset > >> the activity state to "active" after each test to prevent the whole > >> test-suite from getting stuck. > >> > >> Cc: Jim Mattson <jmattson@xxxxxxxxxx> > >> Cc: Sean Christopherson <sean.j.christopherson@xxxxxxxxx> > >> Signed-off-by: Nadav Amit <nadav.amit@xxxxxxxxx> > > Reviewed-by: Jim Mattson <jmattson@xxxxxxxxxx> > > > > I think I have been assuming that "wake the logical processor" means > > "causes the logical processor to enter the 'active' activity state." > > Maybe that's not what "wake" means? > > I really don’t know. Reading the specifications, I thought that the test is > valid. I don’t manage to read it any differently than you did. "logic processor" in this context means the physical CPU, it doesn't imply anything about what gets saved into the VMCS. I assume the purpose of that blurb is to make it clear that the guest won't get stuck in HLT state if there's a virtual interrupt pending. The relevant SDM section is "Saving Non-Register State": The activity-state field is saved with the logical processor's activity state before the VM exit[1]. See Section 27.1 for details of how events leading to a VM exit may affect the activity state. The revelant bits of Section 27.1 - "Architectural State Before a VM Exit": If the logical processor is in an inactive state and not executing instructions, some events may be blocked but other may return the logical processor to the active state. Unblocked events may cause VM exits. If an unblocked event causes a VM exit directly, a return to the active state occurs only after the VM exit completes. <more irrevelant words> In other words, because the CPU was in HLT before VM-Exit, that's what gets saved into the VMCS. My guess is that the behavior is defined this way because technically the vCPU hasn't received a wake event, the VMM has simply requested a VM Exit. The wake event (from the vCPU's perspective) comes when the VMM actually injects an interrupt/NMI.
