From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Schopp Subject: Re: [PATCH] kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform Date: Thu, 24 Jul 2014 15:01:39 -0500 Message-ID: <53D16623.2020201@amd.com> References: <1406230067-926-1-git-send-email-will.deacon@arm.com> <20140724195528.GC9143@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , "gleb@kernel.org" , "kvmarm@lists.cs.columbia.edu" , kvm-devel , Christoffer Dall , "Marc Zyngier" , Don Dutile , "stable@vger.kernel.org" To: Will Deacon , Peter Maydell Return-path: In-Reply-To: <20140724195528.GC9143@arm.com> Sender: stable-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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 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.