qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Laszlo Ersek
Subject: Re: [Qemu-devel] QEMU virt board: extending various limits
Date: Tue, 16 Jan 2018 21:18:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

(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.)

Thanks,
Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]