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

[Ard Biesheuvel]

On 1 October 2015 at 14:22, Gabriel L. Somlo <address@hidden> wrote:
> On Wed, Sep 30, 2015 at 12:21:08PM +0200, Laszlo Ersek wrote:
>> 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)
>
> I'm noticing that even on 32-bit arm there are ACPI tables generated and
> inserted into fw_cfg, so is there any reason OTHER than lack of firmware
> support for ACPI not being supported on 32-bit arm ?
>

The 32-bit ARM/Linux kernel simply does not implement *any* kind of
ACPI support or awareness, so whether the firmware implements it or
not is irrelevant.

>> > 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 to both of you for the pointers, I will probably invest some
> time in getting set up with UEFI firmware for my arm guests at some
> point, when the dust settles on all the other fun :)
>
> Thanks,
> --Gabriel