On 07/24/2014 02:55 PM, Will Deacon wrote: > On Thu, Jul 24, 2014 at 08:47:23PM +0100, Peter Maydell wrote: >> On 24 July 2014 20:27, Will Deacon <will.deacon@xxxxxxx> wrote: >>> If the physical address of GICV isn't page-aligned, then we end up >>> creating a stage-2 mapping of the page containing it, which causes us to >>> map neighbouring memory locations directly into the guest. >>> >>> As an example, consider a platform with GICV at physical 0x2c02f000 >>> running a 64k-page host kernel. If qemu maps this into the guest at >>> 0x80010000, then guest physical addresses 0x80010000 - 0x8001efff will >>> map host physical region 0x2c020000 - 0x2c02efff. Accesses to these >>> physical regions may cause UNPREDICTABLE behaviour, for example, on the >>> Juno platform this will cause an SError exception to EL3, which brings >>> down the entire physical CPU resulting in RCU stalls / HYP panics / host >>> crashing / wasted weeks of debugging. >> This seems to me like a specific problem with Juno rather than an >> issue with having the GICV at a non-page-aligned start. The >> requirement to be able to expose host GICV as the guest GICC >> in a 64K pages system is just "nothing else in that 64K page >> (or pages, if the GICV runs across two pages) is allowed to be >> unsafe for the guest to touch", which remains true whether the >> GICV starts at 0K in the 64K page or 60K. > I agree, and for that we would need a new ioctl so we can query the > page-offset of the GICV on systems where it is safe. Given that such an > ioctl doesn't exist today, I would like to plug the hole in mainline kernels > with this patch, we can relax in the future if systems appear where it would > be safe to map the entire 64k region. I have such a system. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
