On 05/22/18 23:22, Michael S. Tsirkin wrote: > On Tue, May 22, 2018 at 03:17:32PM -0600, Alex Williamson wrote: >> On Tue, 22 May 2018 21:51:47 +0200 >> Laszlo Ersek <ler...@redhat.com> wrote:
>>> But 64-bit is ill-partitioned and/or crowded too: first you have the >>> cold-plugged >4GB DRAM (whose size the firmware can interrogate), then >>> the hotplug DIMM area up to "etc/reserved-memory-end" (ditto), then the >>> 64-bit PCI MMIO aperture (whose size the firmware decides itself, >>> because QEMU cannot be asked about it presently). Placing the additional >>> MMCFGs somewhere would need extending the total order between these >>> things at the design level, more fw_cfg files, more sanity checks in >>> platform code in the firmware, and, quite importantly, adding support to >>> multiple discontiguous MMCFGs to core edk2 code. >> >> Hmm, we're doing something wrong if we can't figure out some standards >> within QEMU for placing per domain 64-bit MMIO and MMCFG ranges. > > I thought in this patch it is done by firmware. Sure, the firmware programs the exbar registers already, but it needs to rely on some information to figure out the values it should program. (Also, the information should not arrive in the form of *just* an ACPI table; that's too hard and/or too late to parse for the firmware.) Right now the "information" is a hard-coded constant that's known not to conflict with other parts. Furthermore, I didn't highlight it earlier, but we can't go arbitrarily high -- if EPT is enabled, then the physical address width of the host CPU limits the guest-physical memory address space (incl. memory mapped devices). Thanks Laszlo