From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH] kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform Date: Fri, 25 Jul 2014 15:23:51 +0100 Message-ID: <20140725142351.GK5269@arm.com> References: <1406230067-926-1-git-send-email-will.deacon@arm.com> <20140724195528.GC9143@arm.com> <20140725093127.GB5269@arm.com> <53D26392.9080602@amd.com> <20140725140851.GJ5269@arm.com> <53D266AF.8010406@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Peter Maydell , Paolo Bonzini , "gleb@kernel.org" , "kvmarm@lists.cs.columbia.edu" , kvm-devel , Christoffer Dall , Marc Zyngier , Don Dutile , "stable@vger.kernel.org" To: Joel Schopp Return-path: Content-Disposition: inline In-Reply-To: <53D266AF.8010406@amd.com> Sender: stable-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Fri, Jul 25, 2014 at 03:16:15PM +0100, Joel Schopp wrote: > On 07/25/2014 09:08 AM, Will Deacon wrote: > >> This would break with my SOC device tree which looks like this. N= ote > >> this device tree works just fine without checks. > >> > >> gic: interrupt-controller@e1101000 { > >> compatible =3D "arm,gic-400-v2m"; > >> #interrupt-cells =3D <3>; > >> #address-cells =3D <0>; > >> interrupt-controller; > >> msi-controller; > >> reg =3D <0x0 0xe1110000 0 0x1000>, /* gic dist */ > >> <0x0 0xe112f000 0 0x2000>, /* gic cpu */ > >> <0x0 0xe114f000 0 0x2000>, /* gic virtual ic*/ > >> <0x0 0xe116f000 0 0x2000>, /* gic virtual cpu*/ > >> <0x0 0xe1180000 0 0x1000>; /* gic msi */ > >> interrupts =3D <1 8 0xf04>; > >> }; > > I appreciate it may work, but that's only because the kernel is act= ually > > using an alias of GICV at 0xe1160000 by accident. I would say that = you're > > getting away with passing an incorrect description. > The problem is that by the spec the size is 0x2000 and was never > properly rearchitected from 4K to variable page size support. The > workaround is that each of the 4K in the 64K page (16 of them) are > really mapped to the same location in hardware. So the contents of > 0xe1160000 is the same as the contents of 0xe116f000. See =E2=80=9CAp= pendix F: > GIC-400 and 64KB Translation Granule=E2=80=9D in v2.1 of the ARM _Ser= ver Base > System Architecture_ specification. I've read that document, but it's not mandated and I don't think I have= a single piece of hardware that actually follows it. Even the CPUs don't = seem to perform the aliasing suggesting there (take a look at the A57 and A5= 3 TRMs -- there are reserved regions in there). > Now if we were to change the entry to <0x0 0xe1160000 0 0x2000> it wo= uld > be obviously broken because the second half would map to a duplicate = of > the first half. I think you'd need something like <0x0 0xe1160000 0 0x20000> and we'd h= ave to change the GIC driver to do the right thing. What we currently have = is unsafe on most hardware, yet happens to work on your system. Will