From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxxye-0000We-Qf for qemu-devel@nongnu.org; Thu, 28 May 2015 09:36:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxxyZ-0001TX-Dx for qemu-devel@nongnu.org; Thu, 28 May 2015 09:36:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49483) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxxyZ-0001TP-2B for qemu-devel@nongnu.org; Thu, 28 May 2015 09:35:59 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 9DEF82B7878 for ; Thu, 28 May 2015 13:35:58 +0000 (UTC) Message-ID: <556719BA.9060600@redhat.com> Date: Thu, 28 May 2015 15:35:54 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1430133591-6197-1-git-send-email-ghammer@redhat.com> <1430133591-6197-5-git-send-email-ghammer@redhat.com> <5566ED24.3060205@redhat.com> <5567030D.8050606@redhat.com> <20150528141210-mutt-send-email-mst@redhat.com> <55671184.30300@redhat.com> <20150528152225-mutt-send-email-mst@redhat.com> In-Reply-To: <20150528152225-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine Generation ID device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Gal Hammer , imammedo@redhat.com, qemu-devel@nongnu.org On 28/05/2015 15:24, Michael S. Tsirkin wrote: > On Thu, May 28, 2015 at 03:00:52PM +0200, Paolo Bonzini wrote: >> >> >> On 28/05/2015 14:21, Michael S. Tsirkin wrote: >>>> And the way I can fix it would be...? Is there another memory region= I can >>>> use? >>>> >>>> Thanks, >>>> >>>> Gal. >>> >>> I think we hammered out an interesting alternative off-list: get hold= of >>> some AddressRegionNVS memory and copy data from MMIO or port io over >>> there when you get an interrupt. >> >> That doesn't work because there's no way to get the base address of a >> DataTableRegion. >> >> You could use a linker ADD_POINTER command, but it wouldn't work for >> UEFI. >=20 > Hmm why not? UEFI runs these as well. But it only uses them to find a pointer to the base of the tables. The actual relocation is done by the platform-independent UEFI libraries. So you would have the following: 1) OVMF loads the loader script and resolves the pointers. ADDR now correctly points inside the table that has the VMGENID. 2) OVMF calls the AcpiProtocol->InstallAcpiTable, which _copies_ the tables to memory that it allocates. The type of memory is correct (NVS) but the ADDR is now wrong because it points inside the old copy. 3) OVMF notices that the loader script has a pointer to inside the UEFI table. So it does not free the table, but this doesn't help: the DataTableRegion points to the copy of the table, but ADDR points to the original. Whenever the GPE event runs, it writes the VMGENID into the copy of the table, not into ADDR. It's a pity, yes, but it's very hard to fix. Paolo >> So I think it's best to just stay with this one. If we do find >> something better we can always change it later. >> >> Paolo