From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QxuSA-00053G-UW for qemu-devel@nongnu.org; Mon, 29 Aug 2011 01:32:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QxuS9-0002Ln-Ql for qemu-devel@nongnu.org; Mon, 29 Aug 2011 01:32:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18331) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QxuS9-0002Lh-FS for qemu-devel@nongnu.org; Mon, 29 Aug 2011 01:32:09 -0400 Message-ID: <4E5B2450.3050209@redhat.com> Date: Mon, 29 Aug 2011 08:32:00 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4B17C12B.4020300@linux.vnet.ibm.com> <4B17CC5F.20101@redhat.com> <4E59F15E.6000201@redhat.com> <4E5AA849.5090400@web.de> <20110828221437.GA27777@morn.localdomain> In-Reply-To: <20110828221437.GA27777@morn.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] HPET configuration in Seabios List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: Andrew Theurer , Gleb Natapov , "kvm@vger.kernel.org list" , seabios , ya su , Alexander Graf , QEMU Developers , Jan Kiszka On 08/29/2011 01:14 AM, Kevin O'Connor wrote: > 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. > Can't seabios just poke at the hpet itself and see if it exists or not? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.