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: Ard Biesheuvel
Subject: Re: [Qemu-devel] QEMU virt board: extending various limits
Date: Tue, 16 Jan 2018 20:28:49 +0000

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.



reply via email to

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