On Tue, Dec 16, 2014 at 12:32 PM, Stuart Yoder <b08248@xxxxxxxxx> 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?) I found the section reference, but would still like to understand why the architecture requires it. Stuart _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
