On 16 January 2018 at 20:18, Laszlo Ersek <ler...@redhat.com> wrote: > (adding Ard, Igor, Wei, Leif) > > On 01/16/18 16:07, Peter Maydell wrote: >> We've had discussions before about the various limits in the virt >> board imposed by its current address space layout: >> * number of CPUs limited to 123 (not enough space for more redistributors) >> * number of PCIe devices limited by size of ECAM space >> * max memory size limits >> * (anything else?) >> >> If we want to try to fix these this release cycle now would be a good >> point to figure out our approach so that we have plenty of time to do >> it in. >> >> (Relatedly, I notice patches on list for kvm that allow userspace to >> set the guest physical address size, which may affect how we want >> to do this.) >> >> I'm not going to have time to look at this but am happy to provide >> my opinions on whatever proposals other people would like to suggest. >> >> Probably the first thing to do is figure out whether we can >> raise these limits without having to have a flag day (ie just >> with changing the device tree we provide the guest), or if we >> really have a hard compat break here. We should also try to >> fix all these things at once rather than potentially breaking >> guests several times... > > I've quite lost the context on this since we last talked about it. :) My > request would be that Drew and Igor please (re)state their preferences, > and Ard and myself should put "firmware price tags" on those ideas. > > As far as I remember, the sticking point from last time was whether > guest UEFI remains permitted to rely on the RAM base being fixed at 1GB > (i.e. if UEFI is at liberty to ignore x0 on entry). This decision > provides a framework for all further area movements, and represents a > large difference in firmware difficulty. > > (Personally I'd be ready to *accept* a consensus that UEFI should cope > with a dynamic x0 on entry -- I'm neither proposing nor arguing against > the notion. The large additional complexity in the firmware should be > clear up-front however -- it'll take more time, more bugs, more human > resources. My last writeup is at > <http://mid.mail-archive.com/4cce2b8b-a411-bd5d-a06f-b0b80a5fb2f1@redhat.com>, > although I think Ard has modified some of the code since, so parts of > that text are no longer up to date.) >
The 'contract' was 1 MB at 0x40000000 but UEFI never used more than 512 KB of that without checking the DT. With only very minor changes, we could repurpose this range as 'non-secure SRAM', use it as temporary PEI memory and use whatever the DT describes for DRAM, PCIe etc. For the firmware side, this would be a very natural fit with what the code currently does, and with what many x86 and ARM bare metal platforms do as well. Of course, I am clueless when it comes to the QEMU side of these things, so perhaps this is a terrible idea.
