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