> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com] > Sent: Thursday, August 2, 2018 2:26 PM > > vmx_vmexit_handler() assumes that if > SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS is set, that the value in > EPTP_INDEX is valid. Unfortunately, the function which sets this bit > (vmx_vcpu_update_vmfunc_ve) doesn't actually set EPTP_INDEX; it will > only be set the next time vmx_vcpu_update_eptp() is called. > > This means that if a vcpu makes a vmexit between these two points, the > EPTP_INDEX it reads will be invalid. The first time this race happens > for a domain, EPTP_INDEX will most likely be zero, which is the index > for the "host" p2m -- and thus is often correct. But the second time > this race happens, the value will typically be INVALID_ALTP2M, which > will hit the following BUG: > > BUG_ON(idx >= MAX_ALTP2M); > > Worse, if for some reason the current altp2m was *not* `0` during this > window (say, because a toolstack changed the VM to a different view), > then the accounting of active vcpus for an altp2m will be thrown off. > > Fix this by always updating EPTP_INDEX to the current altp2m index > when enabling #VE. > > Reported-by: Razvan Cojocaru <rcojoc...@bitdefender.com> > Signed-off-by: George Dunlap <george.dun...@citrix.com> > Reviewed-by: Razvan Cojocaru <rcojoc...@bitdefender.com> > Tested-by: Razvan Cojocaru <rcojoc...@bitdefender.com>
Acked-by: Kevin Tian <kevin.t...@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
