HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits)

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

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux