Re: [Qemu-devel] windows workload: many ept_violation and mmio exits

Re: [Qemu-devel] windows workload: many ept_violation and mmio exits

[Alexander Graf]

On 28.08.2011, at 02:42, Avi Kivity wrote:

> On 08/26/2011 08:32 AM, ya su wrote:
>> hi,Avi:
>> 
>>     I met the same problem, tons of hpet vm_exits(vector 209, fault
>> address is in the guest vm's hpet mmio range), even I disable hpet
>> device in win7 guest vm, it still produce a larget amount of vm_exits
>> when trace-cmd ;  I add -no-hpet to start the vm, it still has HPET
>> device inside VM.
>> 
>>     Does that means the HPET device in VM does not depend on the
>> emulated hpet device in qemu-kvm? Is there any way to disable the VM
>> HPET device to prevent so many vm_exits?  Thansk.
>> 
> 
> Looks like a bug to me.

IIRC disabling the HPET device doesn't remove the entry from the DSDT, no? So the guest OS might still think it's there while nothing responds (read returns -1).


Alex

[Qemu-devel] HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits)

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

On 2011-08-28 20:54, Alexander Graf wrote:
> 
> On 28.08.2011, at 02:42, Avi Kivity wrote:
> 
>> On 08/26/2011 08:32 AM, ya su wrote:
>>> hi,Avi:
>>>
>>>     I met the same problem, tons of hpet vm_exits(vector 209, fault
>>> address is in the guest vm's hpet mmio range), even I disable hpet
>>> device in win7 guest vm, it still produce a larget amount of vm_exits
>>> when trace-cmd ;  I add -no-hpet to start the vm, it still has HPET
>>> device inside VM.
>>>
>>>     Does that means the HPET device in VM does not depend on the
>>> emulated hpet device in qemu-kvm? Is there any way to disable the VM
>>> HPET device to prevent so many vm_exits?  Thansk.
>>>
>>
>> Looks like a bug to me.
> 
> IIRC disabling the HPET device doesn't remove the entry from the DSDT, no? So the guest OS might still think it's there while nothing responds (read returns -1).

Exactly. We have a fw_cfg interface in place for quite a while now
(though I wonder how the firmware is supposed to tell -no-hpet apart
from QEMU versions that don't provide this data - both return count =
255), but SeaBios still exposes one HPET block at a hard-coded address
unconditionally.

There was quite some discussion about the corresponding Seabios patches
back then but apparently no consensus was found. Re-reading it, I think
Kevin asked for passing the necessary DSDT fragments from QEMU to the
firmware instead of using a new, proprietary fw_cfg format. Is that
still the key requirement for any patch finally fixing this bug?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Qemu-devel] HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits)

[Kevin O'Connor]

On Sun, Aug 28, 2011 at 10:42:49PM +0200, Jan Kiszka wrote:
> On 2011-08-28 20:54, Alexander Graf wrote:
> > 
> > On 28.08.2011, at 02:42, Avi Kivity wrote:
> > 
> >> On 08/26/2011 08:32 AM, ya su wrote:
> >>> hi,Avi:
> >>>
> >>>     I met the same problem, tons of hpet vm_exits(vector 209, fault
> >>> address is in the guest vm's hpet mmio range), even I disable hpet
> >>> device in win7 guest vm, it still produce a larget amount of vm_exits
> >>> when trace-cmd ;  I add -no-hpet to start the vm, it still has HPET
> >>> device inside VM.
> >>>
> >>>     Does that means the HPET device in VM does not depend on the
> >>> emulated hpet device in qemu-kvm? Is there any way to disable the VM
> >>> HPET device to prevent so many vm_exits?  Thansk.
> >>>
> >>
> >> Looks like a bug to me.
> > 
> > IIRC disabling the HPET device doesn't remove the entry from the DSDT, no? So the guest OS might still think it's there while nothing responds (read returns -1).
> 
> Exactly. We have a fw_cfg interface in place for quite a while now
> (though I wonder how the firmware is supposed to tell -no-hpet apart
> from QEMU versions that don't provide this data - both return count =
> 255), but SeaBios still exposes one HPET block at a hard-coded address
> unconditionally.
> 
> There was quite some discussion about the corresponding Seabios patches
> back then but apparently no consensus was found. Re-reading it, I think
> Kevin asked for passing the necessary DSDT fragments from QEMU to the
> firmware instead of using a new, proprietary fw_cfg format. Is that
> still the key requirement for any patch finally fixing this bug?

My preference would be to use the existing ACPI table passing
interface (fw_cfg slot 0x8000) to pass different ACPI tables to
SeaBIOS.

SeaBIOS doesn't currently allow that interface to override tables
SeaBIOS builds itself, but it's a simple change to rectify that.

When this was last proposed, it was raised that the header information
in the ACPI table may then not match the tables that SeaBIOS builds.
I think I proposed at that time that SeaBIOS could use the header of
the first fw_cfg table (or some other fw_cfg interface) to populate
the headers of its table headers.  However, there was no consensus.

Note - the above is in regard to the HPET table.  If the HPET entry in
the DSDT needs to be removed then that's a bigger change.

-Kevin

Re: [Qemu-devel] HPET configuration in Seabios

[Avi Kivity]

On 08/29/2011 01:14 AM, Kevin O'Connor wrote:
> On Sun, Aug 28, 2011 at 10:42:49PM +0200, Jan Kiszka wrote:
> >  On 2011-08-28 20:54, Alexander Graf wrote:
> >  >
> >  >  On 28.08.2011, at 02:42, Avi Kivity wrote:
> >  >
> >  >>  On 08/26/2011 08:32 AM, ya su wrote:
> >  >>>  hi,Avi:
> >  >>>
> >  >>>      I met the same problem, tons of hpet vm_exits(vector 209, fault
> >  >>>  address is in the guest vm's hpet mmio range), even I disable hpet
> >  >>>  device in win7 guest vm, it still produce a larget amount of vm_exits
> >  >>>  when trace-cmd ;  I add -no-hpet to start the vm, it still has HPET
> >  >>>  device inside VM.
> >  >>>
> >  >>>      Does that means the HPET device in VM does not depend on the
> >  >>>  emulated hpet device in qemu-kvm? Is there any way to disable the VM
> >  >>>  HPET device to prevent so many vm_exits?  Thansk.
> >  >>>
> >  >>
> >  >>  Looks like a bug to me.
> >  >
> >  >  IIRC disabling the HPET device doesn't remove the entry from the DSDT, no? So the guest OS might still think it's there while nothing responds (read returns -1).
> >
> >  Exactly. We have a fw_cfg interface in place for quite a while now
> >  (though I wonder how the firmware is supposed to tell -no-hpet apart
> >  from QEMU versions that don't provide this data - both return count =
> >  255), but SeaBios still exposes one HPET block at a hard-coded address
> >  unconditionally.
> >
> >  There was quite some discussion about the corresponding Seabios patches
> >  back then but apparently no consensus was found. Re-reading it, I think
> >  Kevin asked for passing the necessary DSDT fragments from QEMU to the
> >  firmware instead of using a new, proprietary fw_cfg format. Is that
> >  still the key requirement for any patch finally fixing this bug?
>
> My preference would be to use the existing ACPI table passing
> interface (fw_cfg slot 0x8000) to pass different ACPI tables to
> SeaBIOS.
>
> SeaBIOS doesn't currently allow that interface to override tables
> SeaBIOS builds itself, but it's a simple change to rectify that.
>
> When this was last proposed, it was raised that the header information
> in the ACPI table may then not match the tables that SeaBIOS builds.
> I think I proposed at that time that SeaBIOS could use the header of
> the first fw_cfg table (or some other fw_cfg interface) to populate
> the headers of its table headers.  However, there was no consensus.
>
> Note - the above is in regard to the HPET table.  If the HPET entry in
> the DSDT needs to be removed then that's a bigger change.
>

Can't seabios just poke at the hpet itself and see if it exists or not?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: [Qemu-devel] HPET configuration in Seabios

[Jan Kiszka]

On 2011-08-29 07:32, Avi Kivity wrote:
> On 08/29/2011 01:14 AM, Kevin O'Connor wrote:
>> On Sun, Aug 28, 2011 at 10:42:49PM +0200, Jan Kiszka wrote:
>> >  On 2011-08-28 20:54, Alexander Graf wrote:
>> >  >
>> >  >  On 28.08.2011, at 02:42, Avi Kivity wrote:
>> >  >
>> >  >>  On 08/26/2011 08:32 AM, ya su wrote:
>> >  >>>  hi,Avi:
>> >  >>>
>> >  >>>      I met the same problem, tons of hpet vm_exits(vector 209,
>> fault
>> >  >>>  address is in the guest vm's hpet mmio range), even I disable
>> hpet
>> >  >>>  device in win7 guest vm, it still produce a larget amount of
>> vm_exits
>> >  >>>  when trace-cmd ;  I add -no-hpet to start the vm, it still has
>> HPET
>> >  >>>  device inside VM.
>> >  >>>
>> >  >>>      Does that means the HPET device in VM does not depend on the
>> >  >>>  emulated hpet device in qemu-kvm? Is there any way to disable
>> the VM
>> >  >>>  HPET device to prevent so many vm_exits?  Thansk.
>> >  >>>
>> >  >>
>> >  >>  Looks like a bug to me.
>> >  >
>> >  >  IIRC disabling the HPET device doesn't remove the entry from the
>> DSDT, no? So the guest OS might still think it's there while nothing
>> responds (read returns -1).
>> >
>> >  Exactly. We have a fw_cfg interface in place for quite a while now
>> >  (though I wonder how the firmware is supposed to tell -no-hpet apart
>> >  from QEMU versions that don't provide this data - both return count =
>> >  255), but SeaBios still exposes one HPET block at a hard-coded address
>> >  unconditionally.
>> >
>> >  There was quite some discussion about the corresponding Seabios
>> patches
>> >  back then but apparently no consensus was found. Re-reading it, I
>> think
>> >  Kevin asked for passing the necessary DSDT fragments from QEMU to the
>> >  firmware instead of using a new, proprietary fw_cfg format. Is that
>> >  still the key requirement for any patch finally fixing this bug?
>>
>> My preference would be to use the existing ACPI table passing
>> interface (fw_cfg slot 0x8000) to pass different ACPI tables to
>> SeaBIOS.
>>
>> SeaBIOS doesn't currently allow that interface to override tables
>> SeaBIOS builds itself, but it's a simple change to rectify that.
>>
>> When this was last proposed, it was raised that the header information
>> in the ACPI table may then not match the tables that SeaBIOS builds.
>> I think I proposed at that time that SeaBIOS could use the header of
>> the first fw_cfg table (or some other fw_cfg interface) to populate
>> the headers of its table headers.  However, there was no consensus.
>>
>> Note - the above is in regard to the HPET table.  If the HPET entry in
>> the DSDT needs to be removed then that's a bigger change.
>>
> 
> Can't seabios just poke at the hpet itself and see if it exists or not?
> 

Would be hard for the BIOS to guess the locations of the blocks unless
we define the addresses used by QEMU as something like base + hpet_no *
block_size in all cases.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] HPET configuration in Seabios

[Avi Kivity]

On 08/29/2011 01:25 PM, Jan Kiszka wrote:
> >
> >  Can't seabios just poke at the hpet itself and see if it exists or not?
> >
>
> Would be hard for the BIOS to guess the locations of the blocks unless
> we define the addresses used by QEMU as something like base + hpet_no *
> block_size in all cases.
>

Currently we have a fixed address.  We could do:

  if available in fw_cfg:
      use that (may indicate no hpet)
  elif fixed address works:
      use that
  else
      no hpet


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] HPET configuration in Seabios

[Jan Kiszka]

On 2011-08-29 13:00, Avi Kivity wrote:
> On 08/29/2011 01:25 PM, Jan Kiszka wrote:
>>>
>>>  Can't seabios just poke at the hpet itself and see if it exists or not?
>>>
>>
>> Would be hard for the BIOS to guess the locations of the blocks unless
>> we define the addresses used by QEMU as something like base + hpet_no *
>> block_size in all cases.
>>
> 
> Currently we have a fixed address.  We could do:
> 
>   if available in fw_cfg:
>       use that (may indicate no hpet)
>   elif fixed address works:
>       use that
>   else
>       no hpet

Currently, we also only have a single HPET block, but that's just
because of some QEMU limitations that will vanish sooner or later. Then
nothing will prevent multiple "-device hpet,base=XXX".

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] HPET configuration in Seabios

[Avi Kivity]

On 08/29/2011 02:05 PM, Jan Kiszka wrote:
> On 2011-08-29 13:00, Avi Kivity wrote:
> >  On 08/29/2011 01:25 PM, Jan Kiszka wrote:
> >>>
> >>>   Can't seabios just poke at the hpet itself and see if it exists or not?
> >>>
> >>
> >>  Would be hard for the BIOS to guess the locations of the blocks unless
> >>  we define the addresses used by QEMU as something like base + hpet_no *
> >>  block_size in all cases.
> >>
> >
> >  Currently we have a fixed address.  We could do:
> >
> >    if available in fw_cfg:
> >        use that (may indicate no hpet)
> >    elif fixed address works:
> >        use that
> >    else
> >        no hpet
>
> Currently, we also only have a single HPET block, but that's just
> because of some QEMU limitations that will vanish sooner or later. Then
> nothing will prevent multiple "-device hpet,base=XXX".
>

Yes, so we should enable the fw_cfg interface before that happens.


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] HPET configuration in Seabios

[Jan Kiszka]

On 2011-08-29 13:05, Jan Kiszka wrote:
> On 2011-08-29 13:00, Avi Kivity wrote:
>> On 08/29/2011 01:25 PM, Jan Kiszka wrote:
>>>>
>>>>  Can't seabios just poke at the hpet itself and see if it exists or not?
>>>>
>>>
>>> Would be hard for the BIOS to guess the locations of the blocks unless
>>> we define the addresses used by QEMU as something like base + hpet_no *
>>> block_size in all cases.
>>>
>>
>> Currently we have a fixed address.  We could do:
>>
>>   if available in fw_cfg:
>>       use that (may indicate no hpet)
>>   elif fixed address works:
>>       use that
>>   else
>>       no hpet
> 
> Currently, we also only have a single HPET block, but that's just
> because of some QEMU limitations that will vanish sooner or later. Then
> nothing will prevent multiple "-device hpet,base=XXX".

That said, some HPET probing (without any fw_cfg) may be a short-term
workaround to fix Seabios until we defined The solution for
communicating HPET block configurations.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux