qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin O'Connor <kevin@koconnor.net>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Andrew Theurer <habanero@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	seabios <seabios@seabios.org>, ya su <suya94335@gmail.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Alexander Graf <agraf@suse.de>, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] HPET configuration in Seabios (was: Re: windows workload: many ept_violation and mmio exits)
Date: Sun, 28 Aug 2011 18:14:37 -0400	[thread overview]
Message-ID: <20110828221437.GA27777@morn.localdomain> (raw)
In-Reply-To: <4E5AA849.5090400@web.de>

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.

-Kevin

  reply	other threads:[~2011-08-28 22:14 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         ` [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 [this message]
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=20110828221437.GA27777@morn.localdomain \
    --to=kevin@koconnor.net \
    --cc=agraf@suse.de \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=habanero@linux.vnet.ibm.com \
    --cc=jan.kiszka@web.de \
    --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).