From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhEcP-0007FL-Pg for qemu-devel@nongnu.org; Wed, 30 Sep 2015 06:28:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhEcK-0004FU-PJ for qemu-devel@nongnu.org; Wed, 30 Sep 2015 06:28:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhEcK-0004FO-Hy for qemu-devel@nongnu.org; Wed, 30 Sep 2015 06:28:08 -0400 References: <1443389342-2186-1-git-send-email-somlo@cmu.edu> <1443389342-2186-5-git-send-email-somlo@cmu.edu> <560A6A90.3070807@redhat.com> From: Laszlo Ersek Message-ID: <560BB933.4070405@redhat.com> Date: Wed, 30 Sep 2015 12:28:03 +0200 MIME-Version: 1.0 In-Reply-To: <560A6A90.3070807@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 4/5] acpi: arm: add fw_cfg device node to dsdt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, drjones@redhat.com, matt.fleming@intel.com, ehabkost@redhat.com, mst@redhat.com, zhaoshenglong@huawei.com, leif.lindholm@linaro.org, ard.biesheuvel@linaro.org, kevin@koconnor.net, kraxel@redhat.com, pbonzini@redhat.com, imammedo@redhat.com, markmb@redhat.com, rth@twiddle.net test results from an aarch64 Linux guest (using KVM and UEFI): On 09/29/15 12:40, Laszlo Ersek wrote: > On 09/27/15 23:29, Gabriel L. Somlo wrote: >> Add a fw_cfg device node to the ACPI DSDT. This is mostly >> informational, as the authoritative fw_cfg MMIO region(s) >> are listed in the Device Tree. However, since we are building >> ACPI tables, we might as well be thorough while at it... >> >> Signed-off-by: Gabriel Somlo >> --- >> hw/arm/virt-acpi-build.c | 15 +++++++++++++++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c >> index 1aaff1f..f314132 100644 >> --- a/hw/arm/virt-acpi-build.c >> +++ b/hw/arm/virt-acpi-build.c >> @@ -110,6 +110,20 @@ static void acpi_dsdt_add_rtc(Aml *scope, const MemMapEntry *rtc_memmap, >> aml_append(scope, dev); >> } >> >> +static void acpi_dsdt_add_fw_cfg(Aml *scope, const MemMapEntry *fw_cfg_memmap) >> +{ >> + Aml *dev = aml_device("FWCF"); >> + aml_append(dev, aml_name_decl("_HID", aml_string("QEMU0002"))); >> + /* device present, functioning, decoding, not shown in UI */ >> + aml_append(dev, aml_name_decl("_STA", aml_int(0xB))); >> + >> + Aml *crs = aml_resource_template(); >> + aml_append(crs, aml_memory32_fixed(fw_cfg_memmap->base, >> + fw_cfg_memmap->size, AML_READ_WRITE)); >> + aml_append(dev, aml_name_decl("_CRS", crs)); >> + aml_append(scope, dev); >> +} >> + >> static void acpi_dsdt_add_flash(Aml *scope, const MemMapEntry *flash_memmap) >> { >> Aml *dev, *crs; >> @@ -529,6 +543,7 @@ build_dsdt(GArray *table_data, GArray *linker, VirtGuestInfo *guest_info) >> (irqmap[VIRT_UART] + ARM_SPI_BASE)); >> acpi_dsdt_add_rtc(scope, &memmap[VIRT_RTC], >> (irqmap[VIRT_RTC] + ARM_SPI_BASE)); >> + acpi_dsdt_add_fw_cfg(scope, &memmap[VIRT_FW_CFG]); >> acpi_dsdt_add_flash(scope, &memmap[VIRT_FLASH]); >> acpi_dsdt_add_virtio(scope, &memmap[VIRT_MMIO], >> (irqmap[VIRT_MMIO] + ARM_SPI_BASE), NUM_VIRTIO_TRANSPORTS); >> > > Looks sane to me. > > Did you test this with an aarch64 Linux guest (acpidump -b; iasl -d; So I dumped and decompiled the DSDT, and the relevant output is: > Device (FWCF) > { > Name (_HID, "QEMU0002") // _HID: Hardware ID > Name (_STA, 0x0B) // _STA: Status > Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings > { > Memory32Fixed (ReadWrite, > 0x09020000, // Address Base > 0x0000000A, // Address Length > ) > }) > } This is correct -- the fw_cfg MMIO register block is correctly described by the above. (The actual size will change once Marc's fw_cfg-DMA series is merged, but that will be reflected by this patch automatically.) Second, > cat > /proc/iomem?) I can help with that, if you'd like. > > Reviewed-by: Laszlo Ersek this is the contents of /proc/iomem: > 00000000-03ffffff : LNRO0015:00 > 04000000-07ffffff : LNRO0015:01 > 09000000-09000fff : ARMH0011:00 > 09000000-09000fff : ARMH0011:00 > 09010000-09010fff : LNRO0013:00 > 09020000-09020009 : QEMU0002:00 <-------- see it here (it's inclusive) > 0a000000-0a0001ff : LNRO0005:00 > 0a000200-0a0003ff : LNRO0005:01 > 0a000400-0a0005ff : LNRO0005:02 > 0a000600-0a0007ff : LNRO0005:03 > 0a000800-0a0009ff : LNRO0005:04 > 0a000a00-0a000bff : LNRO0005:05 > 0a000c00-0a000dff : LNRO0005:06 > 0a000e00-0a000fff : LNRO0005:07 > 0a001000-0a0011ff : LNRO0005:08 > 0a001200-0a0013ff : LNRO0005:09 > 0a001400-0a0015ff : LNRO0005:0a > 0a001600-0a0017ff : LNRO0005:0b > 0a001800-0a0019ff : LNRO0005:0c > 0a001a00-0a001bff : LNRO0005:0d > 0a001c00-0a001dff : LNRO0005:0e > 0a001e00-0a001fff : LNRO0005:0f > 0a002000-0a0021ff : LNRO0005:10 > 0a002200-0a0023ff : LNRO0005:11 > 0a002400-0a0025ff : LNRO0005:12 > 0a002600-0a0027ff : LNRO0005:13 > 0a002800-0a0029ff : LNRO0005:14 > 0a002a00-0a002bff : LNRO0005:15 > 0a002c00-0a002dff : LNRO0005:16 > 0a002e00-0a002fff : LNRO0005:17 > 0a003000-0a0031ff : LNRO0005:18 > 0a003200-0a0033ff : LNRO0005:19 > 0a003400-0a0035ff : LNRO0005:1a > 0a003600-0a0037ff : LNRO0005:1b > 0a003800-0a0039ff : LNRO0005:1c > 0a003a00-0a003bff : LNRO0005:1d > 0a003c00-0a003dff : LNRO0005:1e > 0a003c00-0a003dff : LNRO0005:1e > 0a003e00-0a003fff : LNRO0005:1f > 0a003e00-0a003fff : LNRO0005:1f > 10000000-3efeffff : PCI Bus 0000:00 > 3f000000-3fffffff : PCI MMCONFIG 0000 [bus 00-0f] > 40000000-13fffffff : System RAM > 40080000-40c22523 : Kernel code > 40d20000-414dffff : Kernel data > 7fe00000-ffdfffff : Crash kernel > fff30000-fff8ffff : ACPI RAM > fffe0000-ffffffff : ACPI RAM > 8000000000-8000000000 : PCI Bus 0000:00 Therefore Tested-by: Laszlo Ersek Thanks Laszlo