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 _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://www.coreboot.org/mailman/listinfo/seabios