On 10/13/17 15:21, Ard Biesheuvel wrote: > On 13 October 2017 at 13:51, Laszlo Ersek <lersek@xxxxxxxxxx> wrote: >> Hi Ard, Leif, >> >> the current physical memory map of the "virt" machine type doesn't leave >> much room for ECAM / MMCONFIG, which limits the number of PCI Express >> root ports and downstream ports (each port takes a separate bus number, >> and each bus number eats up a chunk of the ECAM area). Also, each port >> can only accommodate a single PCI Express device. In practice this >> limits the number of (hot-pluggable) PCIe devices to approx. 16, which >> is deemed by some "not scaleable enough". (For devices that only need to >> be cold-plugged, they can be placed directly on the root complex, as >> integrated devices, possibly grouping them into multifunction devices >> even; so those don't need bus numbers.) >> >> In order to grow the MMCONFIG area (and for some other reasons >> possibly), the phys memmap of "virt" should be shuffled around a bit. >> This affects the "system" DRAM too. >> > > Is it really necessary to put the ECAM area below 4 GB? For ARM, I > understand this would be an issue, but does the spec actually mandate > anything like this? No, I don't think it's inherently necessary to put ECAM under 4GB. It's just that I approached the problem such that the firmware would be burdened with the lion's share of the complexity, in order to keep things "compatible" for the rest of the guest world. (Speaking personally, I'd absolutely prefer to keep the DRAM base untouched, at 1GB, but I was invited to take a good hard look at what moving the DRAM base would take for the firmware, and I made an honest effort to determine the impact. It doesn't imply that I like the result in the least, or that I personally subscribe to the idea.) Thanks! Laszlo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
