Re: [Qemu-devel] [PATCH v4 3/3] i386: publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg

[Laszlo Ersek]

On 06/17/16 22:55, Raj, Ashok wrote:
> On Fri, Jun 17, 2016 at 10:48:17PM +0200, Laszlo Ersek wrote:
>> On 06/17/16 22:21, Raj, Ashok wrote:
>>> On Fri, Jun 17, 2016 at 07:31:08PM +0200, Laszlo Ersek wrote:
>>>>>>
>>>>>> On 16/06/2016 08:06, Haozhong Zhang wrote:
>>>>>>> It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should
>>>>>>> be set before some features (e.g. VMX and LMCE) can be used, which is
>>>>>>> usually done by the firmware. This patch adds a fw_cfg file
>>>>>>> "etc/msr_feature_control" which contains the advised value of
>>>>>>> MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. 
>>>>>>> SeaBIOS).
>>>>>>>
>>>
>>> I'm sorry i'm joining this discussion a bit late returning from vacation. 
>>> In a real platform supporting LMCE, BIOS is responsible for setting the 
>>> bits 
>>> for IA32_FEATURE_CONTROL correctly. There are good reasons why we want the 
>>> BIOS to play this role.
>>>
>>> in a virtualized environment, do we really have to push the same requirement
>>> or would it suffice to just emulate it as we did in the early patches.
>>>
>>> Not sure what exact problem is created by just simply supporting it within
>>> kvm/qemu and not needing the bios for the guest to also adapt these changes.
>>
>> At the moment, my understanding of this feature is superficial, but the
>> mechanisms involved in it don't seem complex. I don't expect
>> difficulties implementing it, I just need the details that I asked for
>> spelled out for me.
>>
>> As to why we should be doing this in the guest firmware(s) -- "because
>> that's what happens on physical machines too" :) Following the phys
>> world to the letter in virt is not always a goal, but it's never wrong.
> 
> But the guest bios does nothing like the BIOS in the real platform.

That's overstated. The guest firmwares do a lot of things they also do
on physical hardware. PCI enumeration / resource assignment, for example.

> for e.g. a real bios would have SMM handlers to work for implementing firmware
> first mechanisms before notifying the OS. None of these exist in the 
> virtalized world.

Both SeaBIOS and OVMF utilize SMM, for various purposes.

OVMF's goals with SMM are briefly documented here:
<https://github.com/tianocore/edk2/blob/master/OvmfPkg/README#L121>.

For SMM support, all of KVM, QEMU, and OVMF needed (many) patches.


Anyway, I'm neutral on this. If the consensus is that the MSR at hand is
none of the guest firmware's business, I won't object -- hey, it's only
less work for me. OTOH, if the consensus is that SeaBIOS should be aware
of the MSR, then it follows that so should OVMF.

Thanks
Laszlo