[PATCH v4 15/19] arm/arm64: KVM: add virtual GICv3 distributor emulation
eric.auger at linaro.org
Thu Dec 4 02:02:04 PST 2014
On 12/04/2014 10:34 AM, Christoffer Dall wrote:
> 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.
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
>> 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"
>>> 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
> 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.
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
More information about the linux-arm-kernel