> On 1 Oct 2019, at 21:40, Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > On Mon, Sep 30, 2019 at 06:29:52PM -0700, Nadav Amit wrote: >>> On Sep 30, 2019, at 6:23 PM, Liran Alon <liran.alon@xxxxxxxxxx> wrote: >>> >>> If INIT signal won’t be kept pending until exiting VMX operation, target >>> CPU which was sent with INIT signal when it was running guest, basically >>> lost INIT signal forever and just received an exit-reason it cannot do much >>> with. That’s why I thought Intel designed this mechanism like I specified >>> above. >> >> Well, the host can always issue an INIT using an IPI. > > And conversely, if the INIT persisted then the host would be forced to do > VMXOFF, otherwise it effectively couldn't do VM-Enter on that logical CPU. The way I grasped it previously is that hypervisor have 2 different options to respond to an INIT-signal exit-reason: 1) Interpret INIT signal as suppose to be delivered to host (e.g. KVM use-case). i.e. Allow other CPU which send INIT signal to reset it. By just exiting VMX operation with VMXOFF. 2) Interpet INIT signal as suppose to be delivered to guest (e.g. A “passthrough” security hypervisor loaded during boot-chain). In this case, hypervisor would reset vCPU context and then enter guest with wait-for-SIPI activity-state. That blocks pending INIT signal from being delivered and exiting from non-root mode. Then next physical SIPI delivered to CPU will be consumed properly. Anyway, just wanted to layout my previous thoughts on the matter. I think Intel SDM phrasing on this regard is very confusing… -Liran
