From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVD4o-0000Dx-FA for qemu-devel@nongnu.org; Fri, 28 Aug 2015 02:23:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVD4k-0001i4-HR for qemu-devel@nongnu.org; Fri, 28 Aug 2015 02:23:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVD4k-0001hy-9f for qemu-devel@nongnu.org; Fri, 28 Aug 2015 02:23:46 -0400 References: <1433787255-4372-1-git-send-email-mst@redhat.com> <55762E63.7010606@redhat.com> <20150609072936-mutt-send-email-mst@redhat.com> <964733846.17699064.1433829751766.JavaMail.zimbra@zmail13.collab.prod.int.phx2.redhat.com> <20150609112550-mutt-send-email-mst@redhat.com> <5576F1E0.9050504@redhat.com> <20150609160429-mutt-send-email-mst@redhat.com> <55DF1E34.4030503@redhat.com> <20150827205706-mutt-send-email-mst@redhat.com> From: Laszlo Ersek Message-ID: <55DFFE6E.1080906@redhat.com> Date: Fri, 28 Aug 2015 08:23:42 +0200 MIME-Version: 1.0 In-Reply-To: <20150827205706-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 0/4] acpi: xsdt support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: ghammer@redhat.com, Paolo Bonzini , imammedo@redhat.com, qemu-devel@nongnu.org, shannon.zhao@linaro.org On 08/27/15 19:58, Michael S. Tsirkin wrote: > On Thu, Aug 27, 2015 at 04:27:00PM +0200, Laszlo Ersek wrote: >> On 06/09/15 16:05, Michael S. Tsirkin wrote: >>> On Tue, Jun 09, 2015 at 04:02:08PM +0200, Laszlo Ersek wrote: >>>> On 06/09/15 11:49, Michael S. Tsirkin wrote: >>>>> On Tue, Jun 09, 2015 at 02:02:31AM -0400, Paolo Bonzini wrote: >>>>>> I would just patch OVMF to ignore the RSDT if there is an XSDT. >>>>>> >>>>>> Alternatively, can you check for ACPI 2.0 support via _OSI, and load the ACPI 2.0 bits via LoadTable? Hopefully XP does not BSOD if the invalid (for ACPI 1.0) opcodes are in a Then block or in a separate method... Then you can use just an RSDT. >>>>>> >>>>>> Paolo >>>>> >>>>> >>>>> So it's even easier. The following doesn't crash XP: >>>>> >>>>> Method(ADDR, 0, Serialized) { >>>>> /* Region is local to method to avoid crashing ACPI 1.0 guests */ >>>>> DataTableRegion(IDPT, "UEFI", "BXPC", "VMGENI"); >>>>> Field (IDPT, AnyAcc, NoLock, Preserve) { >>>>> Offset (54), >>>>> VGIA, 64 // address of "etc/acpi/vmgenid" blob >>>>> } >>>>> Return(Add(VGIA), 40); >>>>> } >>>>> >>>>> Simply because XP doesn't ever call ADDR. >>>>> Method must be serialized since attempts to create two >>>>> regions or fields with the same name would crash OSPM. >>>> >>>> That sounds like a huge relief to me, so thank you for researching it. >>>> >>>> Laszlo >>> >>> Mind you, I still think it's worth it to support XSDT eventually, >>> but the immediate need to do this in 2.4 timeframe is gone. >> >> ... I'll have to make the OVMF linker/loader a little bit smarter, so >> that this QEMU patch series doesn't break it. Because, unfortunately, >> XSDT seems to be a hard requirement for DataTableRegion(), according to >> the ACPI spec. (Thus, unless SeaBIOS installs an XSDT too, >> DataTableRegion() may not work in the ADDR method of the vmgenid device.) > > That's not really true. ACPI is simply pushing XSDT everywhere, > you will find it hardly ever mentions legacy tables like RSDP anymore. > > And in practice, this works fine with all existing guests. > > > So yes let's do it, but no, don't make this a dependency of > this series. Okay, thanks. I made a note for later. Laszlo >> (FWIW I checked the ACPICA source, and AFAICS, DataTableRegion() *of >> ACPICA* should locate tables from the RSDT too just fine. But, IIRC, >> Windows does not use ACPICA, and the ACPI spec requires XSDT. Quite >> unfortunate.) >> >> The idea I have for OVMF is to track the offsets for each blob from >> which tables have been installed already. Then I can detect further >> pointers (located in any other blobs) pointing to the same offsets, and >> forego duplicate table installations. This should fix the problem I >> reported in this thread, and then this patch set should work for OVMF too. >> >> ... I've come across this today while writing "docs/specs/vmgenid.txt". >> >> Laszlo