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

[Laszlo Ersek]

On 09/30/15 11:59, Ard Biesheuvel wrote:
> On 29 September 2015 at 20:26, Gabriel L. Somlo <address@hidden> wrote:
>> On Tue, Sep 29, 2015 at 12:40:16PM +0200, 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; cat
>>> /proc/iomem?) I can help with that, if you'd like.
>>
>> I have a F22 arm setup generated by virt-builder, which I start using:
>>
>> bin/qemu-system-arm -M virt,accel=tcg -cpu cortex-a15 \
>>   -kernel ./ArmVirtBuilder/vmlinuz-4.0.4-301.fc22.armv7hl+lpae \
>>   -initrd ./ArmVirtBuilder/initramfs-4.0.4-301.fc22.armv7hl+lpae.img \
>>   -append "console=ttyAMA0 root=/dev/vda3 ro" \
>>   -device virtio-blk-device,drive=hd0 \
>>   -drive id=hd0,if=none,snapshot=on,file=./ArmVirtBuilder/fedora-22.img \
>>   -device virtio-net-device,netdev=usernet \
>>   -netdev user,id=usernet \
>>   -monitor stdio
>>
> 
> Note that you are booting 32-bit ARM here, which does not support ACPI nor 
> UEFI.
> (UEFI is work in progress, so you can try my ARM 32-bit UEFI tree if
> you need to: 
> https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm-efi-combined-v2)
> 
> You will need to create an arm64 / AArch64 setup and boot the virt
> model using 'qemu-system-aarch64 -M virt -cpu cortex-a57 ...' instead.
> In either case, as Laszlo pointed out, you need UEFI firmware in QEMU
> as well.

I'm about to follow up with my test results, and I considered writing up
a more or less complete guide for Gabriel to test this with an aarch64
guest.

However: if Gabriel has no access to actual aarch64 hardware (ie. cannot
run KVM guests), then I don't think he should bother. Booting just the
UEFI firmware on qemu-system-aarch64 with TCG acceleration is fine, but
for checking "/proc/iomem", he'd really need to boot into guest Linux,
and *that* takes absolutely forever with TCG.

(Dependent on your guest distro, of course; I have tested Fedora 21+ and
RHELSA / RHEL-7 candidates thus far. I wouldn't recommend TCG for those.)

So, I'll just leave these links here for posterity (they could be
somewhat outdated), and I offer to help with aarch64 guest testing in
the future as well, if the patch series overlaps with my interests.

https://wiki.linaro.org/LEG/UEFIforQEMU
https://fedoraproject.org/wiki/Architectures/AArch64/Install_with_QEMU

Thanks
Laszlo