From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUy93-0008GW-7N for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:27:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUy8z-0004fj-76 for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:27:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUy8z-0004f5-2A for qemu-devel@nongnu.org; Thu, 27 Aug 2015 10:27:09 -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> From: Laszlo Ersek Message-ID: <55DF1E34.4030503@redhat.com> Date: Thu, 27 Aug 2015 16:27:00 +0200 MIME-Version: 1.0 In-Reply-To: <20150609160429-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 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.) (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