All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Alexander Graf <agraf@suse.de>, Kevin O'Connor <kevin@koconnor.net>
Cc: Avi Kivity <avi@redhat.com>,
	Andrew Theurer <habanero@linux.vnet.ibm.com>,
	ya su <suya94335@gmail.com>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Gleb Natapov <gleb@redhat.com>, seabios <seabios@seabios.org>
Subject: 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 --]

WARNING: multiple messages have this Message-ID (diff)
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 --]

  reply	other threads:[~2011-08-28 20:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-03 13:46 windows workload: many ept_violation and mmio exits Andrew Theurer
2009-12-03 14:34 ` Avi Kivity
2011-08-26  5:32   ` ya su
2011-08-28  7:42     ` Avi Kivity
2011-08-28 18:54       ` Alexander Graf
2011-08-28 18:54         ` [Qemu-devel] " Alexander Graf
2011-08-28 20:42         ` Jan Kiszka [this message]
2011-08-28 20:42           ` [Qemu-devel] HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits) Jan Kiszka
2011-08-28 22:14           ` Kevin O'Connor
2011-08-28 22:14             ` [Qemu-devel] " Kevin O'Connor
2011-08-29  5:32             ` HPET configuration in Seabios Avi Kivity
2011-08-29  5:32               ` [Qemu-devel] " Avi Kivity
2011-08-29 10:25               ` Jan Kiszka
2011-08-29 10:25                 ` [Qemu-devel] " Jan Kiszka
2011-08-29 11:00                 ` Avi Kivity
2011-08-29 11:00                   ` [Qemu-devel] " Avi Kivity
2011-08-29 11:05                   ` Jan Kiszka
2011-08-29 11:05                     ` [Qemu-devel] " Jan Kiszka
2011-08-29 11:11                     ` Avi Kivity
2011-08-29 11:11                       ` [Qemu-devel] " Avi Kivity
2011-08-29 11:12                     ` Jan Kiszka
2011-08-29 11:12                       ` [Qemu-devel] " 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.