HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits)
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
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
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.
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
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
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
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
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
participants (4)
-
Avi Kivity -
Jan Kiszka -
Jan Kiszka -
Kevin O'Connor