On Wed, 26 Oct 2016, Julien Grall wrote: > Hi, > Apologize for not respecting the netiquette. > > On Tue, 25 Oct 2016, 5:49 p.m. Stefano Stabellini, wrote: > Hi all, > > the following commit: > > commit 21550029f709072aacf3b90edd574e7d3021b400 > Author: Julien Grall > Date:   Thu Oct 8 19:23:53 2015 +0100 > >     xen/arm: gic-v2: Automatically detect aliased GIC400 > > > removed PLATFORM_QUIRK_GIC_64K_STRIDE and introduced an heuristic to > check whether the two GICC pages have a 64K stride. However the > heuristic needs device tree to report a GICC region size of 128K to work > properly. That is not the case for some versions of XGene (including the > one I am using, kindly provided by CloudLab.us). > > The patch series fixes the issue by reintroducing platform quirks, > PLATFORM_QUIRK_GIC_64K_STRIDE, and forcing GICC size to 128K if > PLATFORM_QUIRK_GIC_64K_STRIDE. > > We should consider this series for 4.8. > > > The platform you are using has likely a buggy firmware (I cannot find the mail from > APM stating that). > > I am not convinced that we should support a such case. IIRC unmodified Linux will > not work properly on those platform (e.g the GIC will be drived as a GICv1). I agree with you that it is buggy firmware, but unfortunately it is still out there, deployed. I am using a regular unmodified old Linux kernel (4.0) which works fine (and should still work fine with modern Xen hypervisors). I believe this DTS comes from upstream Linux 4.0. The question is: should we carry this workaround to make our users' life easier? Or should we push back the burden of fixing the firmware to the users? There are valid arguments for both, eventually it comes down to finding the right compromise. To be clear I don't feel strongly either way, but I think it is easier for us to carry this workaround than for our users to update the firmware. So in this case I would take these patches. But it might not be the case in the future for other, more invasive, workarounds. Let me know what you think.