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: Andrew Jones
Subject: Re: [Qemu-devel] QEMU virt board: extending various limits
Date: Wed, 17 Jan 2018 17:53:48 +0100
User-agent: Mutt/1.6.0.1 (2016-04-01)

On Wed, Jan 17, 2018 at 04:18:30PM +0000, Peter Maydell wrote:
> On 17 January 2018 at 16:15, Igor Mammedov <address@hidden> wrote:
> > 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.
> 
> "base of ram is fixed" is about the one thing we've told
> people they can rely on without fishing it out of the
> device tree, so I think I'll just rule changing that out
> of consideration now :-)
>

So that leaves three choices:

1) New machine type that has a different or non-fixed RAM base

(Makes the QEMU/AAVMF zoo even worse.)

2) Implement spit memory where one chunk is guaranteed to be at
   the 1G boundary, e.g. 'size <= 1G' at 1G

(The QEMU work will no doubt snowball, especially when considering
 memory hotplug. Although hotplug will likely warrant using DIMMs
 anyway, which means one 'size <= 1G' at 1G DIMM could be a non-removable,
 there by default DIMM, and other DIMM(s) would go elsewhere in order to
 implement the split memory.)

3) Leave memory like it is and just put everything else we want to expand
   in high memory, probably above the second PCIe window. I.e. CPU
   redistributor regions 124 and up and an additional PCIe ECAM space
   would go up there.

(Easiest, most backward compatible thing to do. Is there risk with putting
 those things above 4G? Someday we may want to shift those things and the
 second PCIe window even higher, if we ever want to support more than 515
 GB of memory, but I guess that shouldn't be a problem.)

Thanks,
drew



reply via email to

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