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
Attachment:
signature.asc
Description: OpenPGP digital signature