From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3TS7-0007ID-Jg for qemu-devel@nongnu.org; Mon, 30 Nov 2015 13:45:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3TS2-0004TW-Ju for qemu-devel@nongnu.org; Mon, 30 Nov 2015 13:45:31 -0500 Received: from g2t4620.austin.hp.com ([15.73.212.81]:57756) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3TS2-0004RE-DF for qemu-devel@nongnu.org; Mon, 30 Nov 2015 13:45:26 -0500 References: <563A8509.4010102@hpe.com> <563AA879.2030301@redhat.com> From: liang yan Message-ID: <565C993E.9000605@hpe.com> Date: Mon, 30 Nov 2015 11:45:18 -0700 MIME-Version: 1.0 In-Reply-To: <563AA879.2030301@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Could not add PCI device with big memory to aarch64 VMs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: "Hayes, Bill" , edk2-devel@ml01.01.org, qemu-devel@nongnu.org, "Ramirez, Laura L (HP Labs)" , Ard Biesheuvel On 11/04/2015 05:53 PM, Laszlo Ersek wrote: > On 11/04/15 23:22, liang yan wrote: >> Hello, Laszlo, >> >> >> (2)It also has a problem that once I use a memory bigger than 256M for >> ivshmem, it could not get through UEFI, >> the error message is >> >> PciBus: Discovered PCI @ [00|01|00] >> BAR[0]: Type = Mem32; Alignment = 0xFFF; Length = 0x100; Offset = >> 0x10 >> BAR[1]: Type = Mem32; Alignment = 0xFFF; Length = 0x1000; Offset >> = 0x14 >> BAR[2]: Type = PMem64; Alignment = 0x3FFFFFFF; Length = >> 0x40000000; Offset = 0x18 >> >> PciBus: HostBridge->SubmitResources() - Success >> ASSERT >> /home/liang/studio/edk2/ArmVirtPkg/PciHostBridgeDxe/PciHostBridge.c(449): ((BOOLEAN)(0==1)) >> >> >> I am wandering if there are memory limitation for pcie devices under >> Qemu environment? >> >> >> Just thank you in advance and any information would be appreciated. > (CC'ing Ard.) > > "Apparently", the firmware-side counterpart of QEMU commit 5125f9cd2532 > has never been contributed to edk2. > > Therefore the the ProcessPciHost() function in > "ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c" ignores the > DTB_PCI_HOST_RANGE_MMIO64 type range from the DTB. (Thus only > DTB_PCI_HOST_RANGE_MMIO32 is recognized as PCI MMIO aperture.) > > However, even if said driver was extended to parse the new 64-bit > aperture into PCDs (which wouldn't be hard), the > ArmVirtPkg/PciHostBridgeDxe driver would still have to be taught to look > at that aperture (from the PCDs) and to serve MMIO BAR allocation > requests from it. That could be hard. > > Please check edk2 commits e48f1f15b0e2^..e5ceb6c9d390, approximately, > for the background on the current code. See also chapter 13 "Protocols - > PCI Bus Support" in the UEFI spec. > > Patches welcome. :) > > (A separate note on ACPI vs. DT: the firmware forwards *both* from QEMU > to the runtime guest OS. However, the firmware parses only the DT for > its own purposes.) Hello, Laszlo, Thanks for your advices above, it's very helpful. When debugging, I also found some problems for 32 bit PCI devices. Hope could get some clues from you. I checked on 512M, 1G, and 2G devices.(4G return invalid parameter error, so I think it may be taken as a 64bit devices, is this right?). First, All devices start from base address 3EFEFFFF. ProcessPciHost: Config[0x3F000000+0x1000000) Bus[0x0..0xF] Io[0x0+0x10000)@0x3EFF0000 Mem[0x10000000+0x2EFF0000)@0x0 PcdPciMmio32Base is 10000000===================== PcdPciMmio32Size is 2EFF0000===================== Second, It could not get new base address when searching memory space in GCD map. For 512M devices, *BaseAddress = (*BaseAddress + 1 - Length) & (~AlignmentMask); BaseAddress is 3EFEFFFF========================== new BaseAddress is 1EEF0000========================== ~AlignmentMask is E0000000========================== Final BaseAddress is 0000 Status = CoreSearchGcdMapEntry (*BaseAddress, Length, &StartLink, &EndLink, Map); For bigger devices: all stops when searching memory space because below code, Length will bigger than MaxAddress(3EFEFFFF) if ((Entry->BaseAddress + Length) > MaxAddress) { continue; } I also checked on ArmVirtQemu.dsc which all set to 0. gArmPlatformTokenSpaceGuid.PcdPciBusMin|0x0 gArmPlatformTokenSpaceGuid.PcdPciBusMax|0x0 gArmPlatformTokenSpaceGuid.PcdPciIoBase|0x0 gArmPlatformTokenSpaceGuid.PcdPciIoSize|0x0 gArmPlatformTokenSpaceGuid.PcdPciIoTranslation|0x0 gArmPlatformTokenSpaceGuid.PcdPciMmio32Base|0x0 gArmPlatformTokenSpaceGuid.PcdPciMmio32Size|0x0 gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x0 Do you think I should change from PcdPciMmio32Base and PcdPciMmio32Size, or do some change for GCD entry list, so it could allocate resources for PCI devices(CoreSearchGcdMapEntry)? Looking forward to your reply. Thanks, Liang > Thanks > Laszlo >