Re: [Qemu-devel] QEMU virt board: extending various limits

[Igor Mammedov]

On Tue, 16 Jan 2018 20:28:49 +0000
Ard Biesheuvel <address@hidden> wrote:

> On 16 January 2018 at 20:18, Laszlo Ersek <address@hidden> 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/address@hidden>,
> > 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.

my idea was to drop fixed RAM base for virt board (at least for
new machine types) so that QEMU could specify it dynamically and
firmware would get base from x0 instead of compiled in constant.

Though it's more complex for firmware, It should benefit both qemu
and firmware in the long run.
  - we won't have to update lockstep updates if there will be need
    to move base in the future
  - not need maintain/invent compat machinery to make sure that
    old/new firmware will work fine on old/new qemu
  - qemu won't have to introduce fragmented RAM layout and keep it
    in as continuous region which is simpler to maintain and hard
    to break by accident.

So I think that dynamic memory base would be better approach to
maintain zoo of qemu and firmware and reduce chances of breaking
some combo that used to work by accident.