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

[Laszlo Ersek]

On 10/01/15 14:22, Gabriel L. Somlo 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 ?

I think Ard was speaking about the guest kernel (his pointer certainly
looks like a kernel repo). With regard to firmware, edk2's
ArmVirtPkg/ArmVirtQemu.dsc builds just fine for 32-bit ARM guests.

So, it's not a QEMU or guest firmware problem; I think it's a guest
kernel problem.

Your question could be reformulated as "why has ACPI adoption been slow
in the ARM kernel", and my answer is "let's not go there". :)

> 
>>> 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 :)

Re your other email... If you can convince people in your organization
that hold the strings of purses to buy aarch64 hardware on the org
level, you can buy it right now. It's pricier than the 96Boards EE stuff
is supposed to be, but it's available. Should you feel a burning desire
to test ACPI (or other) work in aarch64 KVM guests. :)

Thanks
Laszlo

> 
> Thanks,
> --Gabriel
>