[SeaBIOS] [PATCH v3] fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL

[Laszlo Ersek]

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