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