[SeaBIOS] HPET configuration in Seabios
Jan Kiszka
jan.kiszka at siemens.com
Mon Aug 29 12:25:32 CEST 2011
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
More information about the SeaBIOS
mailing list