On 12/04/2014 10:34 AM, Christoffer Dall wrote:

On Wed, Dec 03, 2014 at 12:03:59PM +0000, Andre Przywara wrote:

quoted

On 03/12/14 11:39, Peter Maydell wrote:

quoted

On 3 December 2014 at 11:28, Arnd Bergmann [off-list ref] wrote:

quoted

On Wednesday 03 December 2014 11:10:18 Andre Przywara wrote:

quoted

Currently we have in QEMU:
   0 MB -  128 MB: Flash
 128 MB -  144 MB: CPU peripherals (GIC for now only)
 144 MB -  144 MB: UART (64k)
 144 MB -  144 MB: RTC (64k)
 160 MB -  256 MB: virtio (32 * 512 Bytes used)
 256 MB - 1024 MB: PCI
1024 MB - ???? MB: DRAM

So we waste quite some space between 144 MB and 256 MB, where we
currently use only 3 64K pages. If we would move those three pages
closer to the 256 MB region, we could extend the GIC mapping space from
16 MB (127 VCPUs) to almost 128 MB (good for 1022 VCPUs).

Note that part of the reason for that gap is to give us space
to add more memory-mapped peripherals as they are needed.
For instance the fw_cfg conduit for talking to UEFI firmware
is going to need another 64K page in that section.

Hi,

For info I also planned to use 4MB between RTC and virtio for platform
bus (all dynamically instantiated sysbus devices including VFIO platform
devices), currently plugged at 148MB
(http://lists.gnu.org/archive/html/qemu-devel/2014-11/msg04346.html)

Best Regards

Eric

quoted

Sure, that was just to show the situation in general. We could do
something like kvmtool and grow the CPU peripheral space and the device
MMIO pages from different directions to not waste space needlessly.
So UART, RTC, virtio and future devices use space from 128MB upwards,
whereas the GIC uses as much space below 256 MB as needed.

Btw.: Is there an issue with not aligning each virtio device to a 64K
page? Will we never need to separate access to virtio devices in a guest
with MMU help?

quoted

quoted

Having a more compressed mapping sounds useful, but you could also consider
carving the GIC registers out of the PCI range and make PCI memory space
smaller if there are lots of CPUs.

Is there also a 64-bit PCI memory space behind the DRAM?

The "PCI" section at the moment is purely hypothetical -- it's
a lump of reserved space in the memory map that I put in so
we had a place to put PCI later... The DRAM is just the last
thing in the memory map and goes up for as much DRAM as you
asked QEMU to provide, so in that sense there's no "behind"
there.

We could (at least at the moment) shuffle things around a bit,
since guests should all be looking at the DTB to figure where
things are. About the only thing we can't do is move the base
address of RAM or put the flash somewhere other than 0. If
we do need to make changes I'd rather we figured out the new
layout and switched to it rather than doing a set of piecemeal
tweaks, though.

Agreed. As QEMU does not support GICv3 anyway at the moment, there is no
need to rush things.

Is there any sign of a PCI host controller emulation for QEMU on the
horizon?

Yes, we need to have this in Q1 2015 latest.  Linaro has scheduled this
work, but patches are a little while out I'm afraid.

-Christoffer
_______________________________________________
kvmarm mailing list
kvmarm at lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm