Re: [Qemu-devel] [PATCH v4 4/5] acpi: arm: add fw_cfg device node to dsdt

[Laszlo Ersek]

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 <address@hidden>
>> ---
>>  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 <address@hidden>

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 <address@hidden>

Thanks
Laszlo