[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