From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhdAs-0004tk-4i for qemu-devel@nongnu.org; Thu, 01 Oct 2015 08:41:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhdAo-0007dP-PR for qemu-devel@nongnu.org; Thu, 01 Oct 2015 08:41:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhd5T-00067U-7c for qemu-devel@nongnu.org; Thu, 01 Oct 2015 08:35:51 -0400 References: <1443389342-2186-1-git-send-email-somlo@cmu.edu> <1443389342-2186-5-git-send-email-somlo@cmu.edu> <560A6A90.3070807@redhat.com> <20150929182613.GY2080@HEDWIG.INI.CMU.EDU> <560BB794.9010600@redhat.com> <20151001122242.GJ23832@HEDWIG.INI.CMU.EDU> From: Laszlo Ersek Message-ID: <560D28A1.4040706@redhat.com> Date: Thu, 1 Oct 2015 14:35:45 +0200 MIME-Version: 1.0 In-Reply-To: <20151001122242.GJ23832@HEDWIG.INI.CMU.EDU> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 4/5] acpi: arm: add fw_cfg device node to dsdt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: Peter Maydell , Andrew Jones , Matt Fleming , Eduardo Habkost , "Michael S. Tsirkin" , Ard Biesheuvel , QEMU Developers , Leif Lindholm , Paolo Bonzini , Gerd Hoffmann , Shannon Zhao , Igor Mammedov , markmb@redhat.com, kevin@koconnor.net, Richard Henderson 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 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 >>>>>> --- >>>>>> 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 >