On 26/06/18 10:52, Jan Beulich wrote: >>>> On 26.06.18 at 10:45, <andrew.coop...@citrix.com> wrote: >> On 26/06/2018 08:32, Jan Beulich wrote: >>> Use EFLAGS.IF for all ordinary purposes; there's in particular no need >>> to unduly defer NMI/#MC. Clear/set GIF solely around VMRUN itself. This >>> has the additional advantage that svm_stgi_label now indeed marks the >>> only place where GIF is being set. >>> >>> A note regarding the main STI placement: Orignally I had it at the place >>> the main STGI was sitting at so far. However, my Fam15 box reliably >>> locks up hard with this, unless I have the NMI watchdog enabled. I can >>> only deduce that the CPU doesn't like STGI with EFLAGS.IF clear plus >>> some other condition (the lockup occurs only after exiting the boot >>> loader in the guest). As there's nothing wrong with interrupts being on >>> right after VMRUN, I've decided to put the STI right after the CLGI >>> (matching what KVM does, i.e. having a fair chance of working >>> everywhere). >> I'd like some input from AMD on this observation, because it is >> completely bizarre. > Would be nice indeed. > >>> @@ -96,13 +100,11 @@ __UNLIKELY_END(nsvm_hap) >>> SPEC_CTRL_ENTRY_FROM_HVM /* Req: b=curr %rsp=regs/cpuinfo, >>> Clob: acd */ >>> /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */ >>> >>> - STGI >>> -GLOBAL(svm_stgi_label) >> Unfortunately, the stgi label must remain here. >> SPEC_CTRL_ENTRY_FROM_HVM depends on NMIs being blocked to avoid >> corrupting guest state. > I'm afraid I don't follow: How are things safe then without NMIs blocked > for VMX?
27.5.5 VMExits > Updating Non-Register State VM exits caused directly by non-maskable interrupts (NMIs) cause blocking by NMI (see Table 24-3). Other VM exits do not affect blocking by NMI. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
