On 26/06/18 12:53, Andrew Cooper wrote: > On 26/06/18 12:50, Jan Beulich wrote: >>>>> On 26.06.18 at 12:52, <andrew.coop...@citrix.com> wrote: >>> 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. >> Telling us that an NMI can occur at any point between >> vmx_asm_vmexit_handler and the point where guest state was >> saved in SPEC_CTRL_ENTRY_FROM_HVM. So afaict if the macro is >> indeed unsafe right now, it's the macro that needs to change, >> not the patch we're discussing here. > No... It tells you the exact opposite. > > NMIs are not delivered while the NMI shadow is in effect, and is why we > deliberately execute an IRET in the NMI path in vmx_vmexit_handler()
Actually never mind. I'm being very dumb... Let me experiment ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
