From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XopUd-0005fm-IG for qemu-devel@nongnu.org; Thu, 13 Nov 2014 03:11:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XopUX-0005Gc-7D for qemu-devel@nongnu.org; Thu, 13 Nov 2014 03:11:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35120) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XopUW-0005GW-W3 for qemu-devel@nongnu.org; Thu, 13 Nov 2014 03:10:57 -0500 Message-ID: <1415866226.25539.1.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Thu, 13 Nov 2014 09:10:26 +0100 In-Reply-To: References: <20141030180216.GD31629@leverpostej> <5459F4CB.1000009@huawei.com> <20141111152932.GA25295@leverpostej> <20141111163101.GB23267@cbox> <20141111164807.GC25295@leverpostej> <20141111213312.GC19598@cbox> <20141112103854.GA28015@leverpostej> <546349F6.10300@redhat.com> <20141112120419.GE28015@leverpostej> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Mark Rutland , "Ian.Campbell@citrix.com" , "linaro-acpi@lists.linaro.org" , Alexander Spyridakis , Julien Grall , Claudio Fontana , QEMU Developers , Leif Lindholm , "stefano.stabellini@citrix.com" , "grant.likely@linaro.org" , Paolo Bonzini , "tech@virtualopensystems.com" , Parth Dixit , Christoffer Dall Hi, > My understanding from an IRC conversation yesterday was that at > least some of these ACPI blobs contain data which has to be constructed > at the point it is requested (ie is not fixed at the point when > QEMU starts up), because OVMF will do: > * startup > * prod some parts of the hardware to configure it > * request ACPI tables via fw_cfg > and the ACPI tables have to reflect the statu of the hardware > after OVMF's poking, not before. It is this: [root@fedora ~]# cat /proc/ioports [ ... ] 0600-063f : 0000:00:01.3 0600-0603 : ACPI PM1a_EVT_BLK 0604-0605 : ACPI PM1a_CNT_BLK 0608-060b : ACPI PM_TMR 0700-070f : 0000:00:01.3 0700-0707 : piix4_smbus [ ... ] [root@fedora ~]# lspci -vs1.3 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) Subsystem: Red Hat, Inc Qemu virtual machine Flags: medium devsel, IRQ 9 Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4 A bunch of acpi registers are in a hidden pci bar of the piix4 acpi device (likewise on q35). The firmware must map this somewhere, and this must be done pretty early because the firmware uses the acpi pm timer for timekeeping. The acpi tables have references to the apci registers, so the acpi table content must match the actual register location. [ q35 only: similar issue with the pci mmconfig xbar ] So there are three options to solve that: (1) Use a fixed address. Doable, but takes away some flexibility. (2) Have qemu define the address locations. Has some nasty initialization order issues. Also would require (a) a paravirtual interface or (b) a acpi table parser in the firmware. (3) Have firmware define the address location. This is what we did on x86. No paravirt interface needed, the firmware simply programs the registers as it likes, and qemu adapts the acpi tables accordingly. > It wasn't entirely clear to me whether this applies equally > to the ARM UEFI setup as to x86 + OVMF, I think on arm doing (2) is alot easier as DT provides a nice way to pass addresses from qemu to firmware/guest. cheers, Gerd