On 07/06/16 14:18, Paolo Bonzini wrote:
On 06/07/2016 13:04, Laszlo Ersek wrote:
I checked kvm/next (currently at 196f20ca52e8c7281932663c348fa54b82d03914), and vmx_vcpu_reset() does not seem to zero vmx->msr_ia32_feature_control.
This is true, but QEMU does zero it.
Indeed. Sorry for wasting your time.
Although, I am very happy about the following:
Now, what I absolutely can't tell you is whether this zeroing should happen regardless of "init_event", or just for a specific value of "init_event". Whenever I look at "init_event", I have to track it down to the commit that added it, then locate all the commits that fixed it, then guess whether the SDM language "logical processor reset" implies a specific "init_event" value or not. So, I have no idea about "init_event".
It should be preserved by INIT, but not by reset or S3.
This is great (I hope!) because this way I have a chance to stay out of the implementations of EFI_MP_SERVICES_PROTOCOL and EFI_PEI_MP_SERVICES_PPI. (They live under UefiCpuPkg.)
I've worried that if I only *call* these interfaces to set the MSR, then the next (independent) use of the same interfaces would clear the MSR through the INIT-SIPI-SIPI. That would have forced me to modify the protocol / PPI implementations so that any use of them would reprogram the MSR every time, after the INIT-SIPI-SIPI.
This way however (hopefully) it should suffice to call the PPI only -- the results should survive from PEI to DXE to the runtime OS on the normal boot path, and from PEI to the runtime OS on the S3 resume path.
So I need to know whether those INIT-SIPI-SIPI sequences are supposed to clear the MSR -- in other words, whether I have to write patches that explicitly sustain the MSR across these IPIs.
No, INIT hardly changes any MSR.
Thank you for your help! Laszlo