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

[Eric Auger]

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.

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

>>
>> 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
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
>