OS usually expects BIOS to set certain bits in MSR_IA32_FEATURE_CONTROL
for some features (e.g. VMX and LMCE). QEMU provides a fw_cfg file
"etc/msr_feature_control" to advise bits that should be set in
MSR_IA32_FEATURE_CONTROL. If this file exists, SeaBIOS will set the
advised bits in that MSR.
Si
On Mi, 2016-06-22 at 14:53 +0800, Haozhong Zhang wrote:
> OS usually expects BIOS to set certain bits in MSR_IA32_FEATURE_CONTROL
> for some features (e.g. VMX and LMCE). QEMU provides a fw_cfg file
> "etc/msr_feature_control" to advise bits that should be set in
> MSR_IA32_FEATURE_CONTROL. If this
On 06/22/16 08:53, Haozhong Zhang wrote:
> OS usually expects BIOS to set certain bits in MSR_IA32_FEATURE_CONTROL
> for some features (e.g. VMX and LMCE). QEMU provides a fw_cfg file
> "etc/msr_feature_control" to advise bits that should be set in
> MSR_IA32_FEATURE_CONTROL. If this file exists, S
On 07/06/16 00:19, Laszlo Ersek wrote:
> On 06/22/16 08:53, Haozhong Zhang wrote:
> > OS usually expects BIOS to set certain bits in MSR_IA32_FEATURE_CONTROL
> > for some features (e.g. VMX and LMCE). QEMU provides a fw_cfg file
> > "etc/msr_feature_control" to advise bits that should be set in
> >
> I forgot to restore MSR_IA32_FEATURE_CONTROL in the resume path, and
> MSR_IA32_FEATURE_CONTROL is zero after S3 resume.
This is a bug. Sorry Laszlo. :)
> Not restore MSR_IA32_FEATURE_CONTROL during S3 resume does not affect
> at least Linux guest (tested 4.5). Current QEMU may advise the gues
Hi Ashok,
On 07/06/16 02:18, Paolo Bonzini wrote:
> > I forgot to restore MSR_IA32_FEATURE_CONTROL in the resume path, and
> > MSR_IA32_FEATURE_CONTROL is zero after S3 resume.
>
> This is a bug. Sorry Laszlo. :)
>
> > Not restore MSR_IA32_FEATURE_CONTROL during S3 resume does not affect
> > at
On 07/06/16 08:28, Haozhong Zhang wrote:
> Hi Ashok,
>
> On 07/06/16 02:18, Paolo Bonzini wrote:
>>> I forgot to restore MSR_IA32_FEATURE_CONTROL in the resume path, and
>>> MSR_IA32_FEATURE_CONTROL is zero after S3 resume.
>>
>> This is a bug. Sorry Laszlo. :)
>>
>>> Not restore MSR_IA32_FEATURE
On 07/06/16 08:42, Laszlo Ersek wrote:
> On 07/06/16 08:28, Haozhong Zhang wrote:
> > Hi Ashok,
> >
> > On 07/06/16 02:18, Paolo Bonzini wrote:
> >>> I forgot to restore MSR_IA32_FEATURE_CONTROL in the resume path, and
> >>> MSR_IA32_FEATURE_CONTROL is zero after S3 resume.
> >>
> >> This is a bug
On 07/06/16 08:49, Haozhong Zhang wrote:
> On 07/06/16 08:42, Laszlo Ersek wrote:
>> On 07/06/16 08:28, Haozhong Zhang wrote:
>>> Hi Ashok,
>>>
>>> On 07/06/16 02:18, Paolo Bonzini wrote:
> I forgot to restore MSR_IA32_FEATURE_CONTROL in the resume path, and
> MSR_IA32_FEATURE_CONTROL is ze
On 07/06/16 08:42, Laszlo Ersek wrote:
> On 07/06/16 08:28, Haozhong Zhang wrote:
>> Hi Ashok,
>>
>> On 07/06/16 02:18, Paolo Bonzini wrote:
I forgot to restore MSR_IA32_FEATURE_CONTROL in the resume path, and
MSR_IA32_FEATURE_CONTROL is zero after S3 resume.
>>>
>>> This is a bug. Sorry
On 06/07/2016 13:04, Laszlo Ersek wrote:
> Actually, I think there is a bug in KVM at the moment. I ran the
> following test:
>
> - modified OVMF to set the MSR to value 0x5 on just the BSP
> - booted an i440fx and a Q35 (SMM-enabled) OVMF guest
> - checked "rdmsr -a 0x3a" in both
> - ran "pm-su
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.
> 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 MS
On 07/07/16 14:12, Paolo Bonzini wrote:
>
>> 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
On 07/07/2016 14:44, Laszlo Ersek wrote:
> Regarding MTRRs... that's a bit messy. PlatformPei only progams the
> MTRRs only on the BSP. For the normal boot path, this is no problem,
> because when EFI_MP_SERVICES_PROTOCOL starts up (in CpuDxe), the MTRR
> settings are broad-cast to all APs. It is
15 matches
Mail list logo