Re: [PATCH 0/2] Fix Xen boot on XGene

From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien.grall@gmail.com>
Cc: xen-devel@lists.xenproject.org, julien.grall@arm.com,
	Stefano Stabellini <sstabellini@kernel.org>,
	wei.liu2@citrix.com
Subject: Re: [PATCH 0/2] Fix Xen boot on XGene
Date: Wed, 26 Oct 2016 15:12:49 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1610261448560.9978@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <CAF3u54CCcPgehjTwPVLFQ+-MzB9gUsDAir9wD=NG2D739j2kdg@mail.gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2179 bytes --]

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, <sstabellini@kernel.org> wrote:
>       Hi all,
> 
>       the following commit:
> 
>       commit 21550029f709072aacf3b90edd574e7d3021b400
>       Author: Julien Grall <julien.grall@citrix.com>
>       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.

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel