From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xoyx4-00048w-2d for qemu-devel@nongnu.org; Thu, 13 Nov 2014 13:17:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xoywy-0006NQ-6c for qemu-devel@nongnu.org; Thu, 13 Nov 2014 13:17:02 -0500 Received: from mail-pd0-f180.google.com ([209.85.192.180]:39168) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xoywy-0006Mq-0L for qemu-devel@nongnu.org; Thu, 13 Nov 2014 13:16:56 -0500 Received: by mail-pd0-f180.google.com with SMTP id ft15so15007992pdb.11 for ; Thu, 13 Nov 2014 10:16:52 -0800 (PST) Message-ID: <5464F590.5060507@linaro.org> Date: Thu, 13 Nov 2014 11:16:48 -0700 From: Al Stone MIME-Version: 1.0 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> <1415866226.25539.1.camel@nilsson.home.kraxel.org> In-Reply-To: <1415866226.25539.1.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Gerd Hoffmann , Peter Maydell Cc: "Ian.Campbell@citrix.com" , "linaro-acpi@lists.linaro.org" , Claudio Fontana , QEMU Developers , "stefano.stabellini@citrix.com" , Paolo Bonzini , "tech@virtualopensystems.com" , Parth Dixit , Christoffer Dall On 11/13/2014 01:10 AM, Gerd Hoffmann wrote: > 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 > [ ... ] So this is problematic: the PM1a_EVT_BLK and PM1a_CNT_BLK should not exist if hardware reduced mode ACPI is being used; the values in the FADT should be zero so there should be no ioports (see section 5.2.9 of the ACPI spec). If this is from an ARM platform, it _should_ be in hardware reduced mode. QEMU will have to take that into account. -- ciao, al ----------------------------------- Al Stone Software Engineer Linaro Enterprise Group al.stone@linaro.org -----------------------------------