HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits)

[Jan Kiszka]

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

[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

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.

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

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

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

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

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