Re: HPET configuration in Seabios
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPET configuration in Seabios
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPET configuration in Seabios
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPET configuration in Seabios
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPET configuration in Seabios
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPET configuration in Seabios
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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits)
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
