On 09/29/15 20:26, Gabriel L. Somlo 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 <so...@cmu.edu>
>>> ---
>>> 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
>
> I used it to successfully test my (rude, mmio-poking) kernel sysfs
> driver, but somehow it doesn't seem to pay any attention to ACPI.
>
> /proc/iomem looks the same before and after my patch, so no entry for
> fw_cfg once I add it to the ssdt host-side.
>
> 'acpidump -b' says "Could not get ACPI tables, AE_NOT_FOUND". There's
> no /proc/acpi or /sys/firmware/acpi...
>
> Although ACPI tables do get placed in fw_cfg (after loading my linux
> kernel driver I can see the "/etc/acpi/tables" blob). And if I 'iasl -d'
> that, I can see the FWCF node in the ssdt :)
>
> In the short run, if you can test on your end that'd be great. Also,
> if you have any idea why I'm not seeing ACPI at all (missing kernel
> module, or wrong firmware, or ???) please let me know...
You are not seeing ACPI tables in the guest because you aren't using a
guest firmware that downloads and installs them (-> ArmVirtQemu, aka.
AAVMF, built from edk2). I'll test your series for that scenario and
report back later.
Thanks
Laszlo
> Thanks,
> --Gabriel
>
>>
>> Reviewed-by: Laszlo Ersek <ler...@redhat.com>
>>
>> Thanks
>> Laszlo
