qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] HPET configuration in Seabios


From: Avi Kivity
Subject: Re: [Qemu-devel] HPET configuration in Seabios
Date: Mon, 29 Aug 2011 08:32:00 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]