On Sat, Jun 09, 2018 at 01:09:32PM +0100, Marc Zyngier wrote: > On Sat, 09 Jun 2018 11:06:57 +0100, > Christoffer Dall wrote: > > > > On Fri, Jun 01, 2018 at 05:06:28PM +0200, Ard Biesheuvel wrote: > > > When booting a 64 KB pages kernel on a ACPI GICv3 system that > > > implements support for v2 emulation, the following warning is > > > produced > > > > > > GICV size 0x2000 not a multiple of page size 0x10000 > > > > > > and support for v2 emulation is disabled, preventing GICv2 VMs > > > from being able to run on such hosts. > > > > > > The reason is that vgic_v3_probe() performs a sanity check on the > > > size of the window (it should be a multiple of the page size), > > > while the ACPI MADT parsing code hardcodes the size of the window > > > to 8 KB. This makes sense, considering that ACPI does not bother > > > to describe the size in the first place, under the assumption that > > > platforms implementing ACPI will follow the architecture and not > > > put anything else in the same 64 KB window. > > > > Does the architecture actually say that anywhere? > > It implies it in section 8.14 of the GICv3 spec: > > <quote> > To enable use of 64KB pages, the GICV_* memory map must ensure that: > > * The base address of the GICV_* registers is 64KB aligned. > > * An alias of the GICV_* registers is provided starting at offset > 0xF000 from the start of the page such that a second copy of > GICV_DIR exists at the start of the next 64KB page. This provides > support for both 4KB and 64KB pages. > </quote> > > > > So let's just drop the sanity check altogether, and assume that > > > the window is at least 64 KB in size. > > > > This could obviously be dangerous if broken systems actually exist. > > Marc may know more about that than me. An alternative would be to > > modify the ACPI code to assume max(8 KB, page size) instead, and/or a > > command line parameter to override this check. > > While the above is in effect very similar to the corresponding GICv2 > requirements with the ARMv8 architecture (described in SBSA, which > everybody and their dog are unfortunately making a point in ignoring), > this is implemented in the CPU, meaning that integrators do not have > the opportunity to fsck it up. Hooray! > > And as far as I know, this is only implemented on A35, A53, A57, A72 > and A73 (all the other ARMv8 CPUs are purely GICv3, and no other > architectural licensee ever shipped a system with the compat > interface). > > > That said, I'm not directly opposed to this patch, but I'll let Marc > > have a look as well. > > My take on this is that we should play it as per the architecture, and > only add more checks if we're presented with a non-compliant > implementation. > I had some faint memory that we had actually seen that, but I'm clearly mixing things up. Thanks for the extended explanation. -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
