On 16/12/14 18:32, Stuart Yoder wrote: > On Tue, Dec 16, 2014 at 3:13 AM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >> The problem is slightly more complicated than it did look initially: >> >> It is expected that the GICV physical address straddles two 64k pages, >> so that GICV_DIR can be trapped independently from the rest of the GICV >> accesses, irrespective of the page size. For this reason, we often >> end-up with GICV being at an address looking like 0xbcdef000, and >> aliases of the first part of GICV all the way in >> [0xbcde0000-0xbcdee000], and the second half aliased in >> [0xbcdf0000-0xbcdff000]. >> >> It appears that a number of platforms have other things sitting in the >> range [0xbcde0000-0xbcdeffff], and with 64k pages there is no way we can >> prevent the guest from accessing this. >> >> Other platforms have an equally braindead mapping, with the first 4k of >> GICV is *only* at 0xbcde0000 and the second one *only* at 0xbcdf0000 (in >> violation of the GIC architecture spec). > > Why does the GIC architecture require this? > (do you have a spec section # reference?) GICv2 Architecture Spec (IHI0048B), Page 74, 4.1.3, CPU Interface Register Map. The GICC_DIR is clearly at offset 0x1000 from GICC_CTLR (and not offset 0x10000). Also, section 5.4 states "The GIC virtual CPU interface registers have the same general format as the GIC physical CPU interface registers and expected behavior is that a virtual machine cannot distinguish between them." One of the implication is that GICV cannot have a different mapping. As for the why: nothing in the spec says that you can spread your registers randomly all over the address space. Anyone remembered sparse IO mappings on Alpha and the pain in caused? Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
