From: Jan Kiszka <jan.kiszka@web.de>
To: Alexander Graf <agraf@suse.de>, Kevin O'Connor <kevin@koconnor.net>
Cc: Andrew Theurer <habanero@linux.vnet.ibm.com>,
"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
Gleb Natapov <gleb@redhat.com>, seabios <seabios@seabios.org>,
ya su <suya94335@gmail.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Avi Kivity <avi@redhat.com>
Subject: [Qemu-devel] HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits)
Date: Sun, 28 Aug 2011 22:42:49 +0200 [thread overview]
Message-ID: <4E5AA849.5090400@web.de> (raw)
In-Reply-To: <F2AA4282-91FD-493A-9337-AB4922C2925A@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2011-08-28 20:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4B17C12B.4020300@linux.vnet.ibm.com>
[not found] ` <4B17CC5F.20101@redhat.com>
[not found] ` <CA+tHM2HH437Y4KLmGO+59wvR-TMSacGnxgt5QB8w5LDtJ+p3Xw@mail.gmail.com>
[not found] ` <4E59F15E.6000201@redhat.com>
2011-08-28 18:54 ` [Qemu-devel] windows workload: many ept_violation and mmio exits Alexander Graf
2011-08-28 20:42 ` Jan Kiszka [this message]
2011-08-28 22:14 ` [Qemu-devel] HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits) Kevin O'Connor
2011-08-29 5:32 ` [Qemu-devel] HPET configuration in Seabios Avi Kivity
2011-08-29 10:25 ` Jan Kiszka
2011-08-29 11:00 ` Avi Kivity
2011-08-29 11:05 ` Jan Kiszka
2011-08-29 11:11 ` Avi Kivity
2011-08-29 11:12 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E5AA849.5090400@web.de \
--to=jan.kiszka@web.de \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=habanero@linux.vnet.ibm.com \
--cc=kevin@koconnor.net \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.org \
--cc=suya94335@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).