On 10/25/16 18:31, Alex Williamson wrote: > On Tue, 25 Oct 2016 11:35:13 +0200 > Laszlo Ersek <ler...@redhat.com> wrote: >
>> (3) You didn't say where you got your firmware binary. Recent builds of >> the upstream ArmVirtQemu platform of edk2 utilize the 64-bit MMIO >> aperture of the "virt" machine, for PCI BAR allocation >> <https://bugzilla.tianocore.org/show_bug.cgi?id=65>. >> >> The location of that aperture comes from QEMU, "hw/arm/virt.c": >> >> /* Second PCIe window, 512GB wide at the 512GB boundary */ >> [VIRT_PCIE_MMIO_HIGH] = { 0x8000000000ULL, 0x8000000000ULL }, > > Note that the BARs for the device in question are 32-bit, > non-prefetchable. 512MB is a rather large BAR to force into a 32-bit > address space, but clearly and x86 guest can handle it, perhaps only > one thought. > > Beyond that, I have no idea how aarch64 reserves MMIO space and > communicates that to the guest. I'd expect the standard would be > ACPI with a _CRS method, but then ARM always seems to throw a curve > ball with device tree. Good point; booting the aarch64 guest kernel with "acpi=force" might be worthwhile. (Alternatively, the ArmVirtQemu firmware can be built with -D PURE_ACPI_BOOT_ENABLE.) Thanks Laszlo _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
