[PATCH v4 15/19] arm/arm64: KVM: add virtual GICv3 distributor emulation

[Christoffer Dall]

On Wed, Dec 03, 2014 at 12:03:59PM +0000, Andre Przywara wrote:
> On 03/12/14 11:39, Peter Maydell wrote:
> > On 3 December 2014 at 11:28, Arnd Bergmann <arnd at arndb.de> wrote:
> >> On Wednesday 03 December 2014 11:10:18 Andre Przywara wrote:
> >>> 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.
> 
> 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?
> 
> >> 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