* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-01-27 7:03 ` Pranavkumar Sawargaonkar 0 siblings, 0 replies; 44+ messages in thread From: Pranavkumar Sawargaonkar @ 2015-01-27 7:03 UTC (permalink / raw) To: devicetree Cc: Feng Kan, arnd, marc.zyngier, jcm, patches, kvmarm, christoffer.dall, Tushar Jagad, Pranavkumar Sawargaonkar, linux-arm-kernel In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page size due to size alignment checking in vgic driver for VCPU Control and VCPU register. This patch corrects the sizes to be inline with the hardware spec. CC: linux-arm-kernel@lists.infradead.org CC: kvmarm@lists.cs.columbia.edu CC: arnd@arndb.de CC: marc.zyngier@arm.com CC: christoffer.dall@linaro.org CC: jcm@redhat.com Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> Signed-off-by: Tushar Jagad <tjagad@apm.com> Signed-off-by: Feng Kan <fkan@apm.com> --- arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi index f1ad9c2..65f0e6d 100644 --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi @@ -81,10 +81,10 @@ compatible = "arm,cortex-a15-gic"; #interrupt-cells = <3>; interrupt-controller; - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ }; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-01-27 7:03 ` Pranavkumar Sawargaonkar 0 siblings, 0 replies; 44+ messages in thread From: Pranavkumar Sawargaonkar @ 2015-01-27 7:03 UTC (permalink / raw) To: linux-arm-kernel In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page size due to size alignment checking in vgic driver for VCPU Control and VCPU register. This patch corrects the sizes to be inline with the hardware spec. CC: linux-arm-kernel at lists.infradead.org CC: kvmarm at lists.cs.columbia.edu CC: arnd at arndb.de CC: marc.zyngier at arm.com CC: christoffer.dall at linaro.org CC: jcm at redhat.com Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> Signed-off-by: Tushar Jagad <tjagad@apm.com> Signed-off-by: Feng Kan <fkan@apm.com> --- arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi index f1ad9c2..65f0e6d 100644 --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi @@ -81,10 +81,10 @@ compatible = "arm,cortex-a15-gic"; #interrupt-cells = <3>; interrupt-controller; - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ }; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-01-27 7:03 ` Pranavkumar Sawargaonkar @ 2015-02-19 15:51 ` Christoffer Dall -1 siblings, 0 replies; 44+ messages in thread From: Christoffer Dall @ 2015-02-19 15:51 UTC (permalink / raw) To: Pranavkumar Sawargaonkar Cc: devicetree, arnd, Feng Kan, marc.zyngier, jcm, patches, Tushar Jagad, kvmarm, linux-arm-kernel On Tue, Jan 27, 2015 at 12:33:26PM +0530, Pranavkumar Sawargaonkar wrote: > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > size due to size alignment checking in vgic driver for VCPU Control and > VCPU register. > > This patch corrects the sizes to be inline with the hardware spec. > > CC: linux-arm-kernel@lists.infradead.org > CC: kvmarm@lists.cs.columbia.edu > CC: arnd@arndb.de > CC: marc.zyngier@arm.com > CC: christoffer.dall@linaro.org > CC: jcm@redhat.com > Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> > Signed-off-by: Tushar Jagad <tjagad@apm.com> > Signed-off-by: Feng Kan <fkan@apm.com> > --- > arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi > index f1ad9c2..65f0e6d 100644 > --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi > +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi > @@ -81,10 +81,10 @@ > compatible = "arm,cortex-a15-gic"; > #interrupt-cells = <3>; > interrupt-controller; > - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ > - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ > - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ > - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ > + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ > + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ > + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ > + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ > interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ > }; > > -- > 1.7.9.5 > This looks good to me and works with 4K and 64K pages on the mustang I have at hand. Acked-by: Christoffer Dall <christoffer.dall@linaro.org> ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-19 15:51 ` Christoffer Dall 0 siblings, 0 replies; 44+ messages in thread From: Christoffer Dall @ 2015-02-19 15:51 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jan 27, 2015 at 12:33:26PM +0530, Pranavkumar Sawargaonkar wrote: > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > size due to size alignment checking in vgic driver for VCPU Control and > VCPU register. > > This patch corrects the sizes to be inline with the hardware spec. > > CC: linux-arm-kernel at lists.infradead.org > CC: kvmarm at lists.cs.columbia.edu > CC: arnd at arndb.de > CC: marc.zyngier at arm.com > CC: christoffer.dall at linaro.org > CC: jcm at redhat.com > Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> > Signed-off-by: Tushar Jagad <tjagad@apm.com> > Signed-off-by: Feng Kan <fkan@apm.com> > --- > arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi > index f1ad9c2..65f0e6d 100644 > --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi > +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi > @@ -81,10 +81,10 @@ > compatible = "arm,cortex-a15-gic"; > #interrupt-cells = <3>; > interrupt-controller; > - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ > - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ > - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ > - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ > + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ > + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ > + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ > + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ > interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ > }; > > -- > 1.7.9.5 > This looks good to me and works with 4K and 64K pages on the mustang I have at hand. Acked-by: Christoffer Dall <christoffer.dall@linaro.org> ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <1422342206-4750-1-git-send-email-psawargaonkar-qTEPVZfXA3Y@public.gmane.org>]
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-01-27 7:03 ` Pranavkumar Sawargaonkar @ 2015-01-27 9:32 ` Jon Masters -1 siblings, 0 replies; 44+ messages in thread From: Jon Masters @ 2015-01-27 9:32 UTC (permalink / raw) To: Pranavkumar Sawargaonkar, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: patches-qTEPVZfXA3Y, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, arnd-r2nGTMty4D4, marc.zyngier-5wv7dgnIgG8, christoffer.dall-QSEj5FYQhm4dnm+yROfE0A, Tushar Jagad, Feng Kan On 01/27/2015 02:03 AM, Pranavkumar Sawargaonkar wrote: > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > size due to size alignment checking in vgic driver for VCPU Control and > VCPU register. > > This patch corrects the sizes to be inline with the hardware spec. > > CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > CC: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org > CC: arnd-r2nGTMty4D4@public.gmane.org > CC: marc.zyngier-5wv7dgnIgG8@public.gmane.org > CC: christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org > CC: jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org > Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> > Signed-off-by: Tushar Jagad <tjagad-qTEPVZfXA3Y@public.gmane.org> > Signed-off-by: Feng Kan <fkan-qTEPVZfXA3Y@public.gmane.org> > --- > arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi > index f1ad9c2..65f0e6d 100644 > --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi > +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi > @@ -81,10 +81,10 @@ > compatible = "arm,cortex-a15-gic"; > #interrupt-cells = <3>; > interrupt-controller; > - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ > - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ > - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ > - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ > + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ > + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ > + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ > + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ > interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ > }; Thanks. I confirm that we have tested this. Jon. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-01-27 9:32 ` Jon Masters 0 siblings, 0 replies; 44+ messages in thread From: Jon Masters @ 2015-01-27 9:32 UTC (permalink / raw) To: linux-arm-kernel On 01/27/2015 02:03 AM, Pranavkumar Sawargaonkar wrote: > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > size due to size alignment checking in vgic driver for VCPU Control and > VCPU register. > > This patch corrects the sizes to be inline with the hardware spec. > > CC: linux-arm-kernel at lists.infradead.org > CC: kvmarm at lists.cs.columbia.edu > CC: arnd at arndb.de > CC: marc.zyngier at arm.com > CC: christoffer.dall at linaro.org > CC: jcm at redhat.com > Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> > Signed-off-by: Tushar Jagad <tjagad@apm.com> > Signed-off-by: Feng Kan <fkan@apm.com> > --- > arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi > index f1ad9c2..65f0e6d 100644 > --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi > +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi > @@ -81,10 +81,10 @@ > compatible = "arm,cortex-a15-gic"; > #interrupt-cells = <3>; > interrupt-controller; > - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ > - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ > - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ > - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ > + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ > + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ > + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ > + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ > interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ > }; Thanks. I confirm that we have tested this. Jon. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-01-27 9:32 ` Jon Masters @ 2015-02-11 4:09 ` Pranavkumar Sawargaonkar -1 siblings, 0 replies; 44+ messages in thread From: Pranavkumar Sawargaonkar @ 2015-02-11 4:09 UTC (permalink / raw) To: devicetree Cc: Feng Kan, Arnd Bergmann, marc.zyngier, Jon Masters, patches, linux-arm-kernel, Tushar Jagad, kvmarm, Christoffer Dall Hi, On Tue, Jan 27, 2015 at 3:02 PM, Jon Masters <jcm@redhat.com> wrote: > On 01/27/2015 02:03 AM, Pranavkumar Sawargaonkar wrote: >> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >> size due to size alignment checking in vgic driver for VCPU Control and >> VCPU register. >> >> This patch corrects the sizes to be inline with the hardware spec. >> >> CC: linux-arm-kernel@lists.infradead.org >> CC: kvmarm@lists.cs.columbia.edu >> CC: arnd@arndb.de >> CC: marc.zyngier@arm.com >> CC: christoffer.dall@linaro.org >> CC: jcm@redhat.com >> Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> >> Signed-off-by: Tushar Jagad <tjagad@apm.com> >> Signed-off-by: Feng Kan <fkan@apm.com> >> --- >> arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi >> index f1ad9c2..65f0e6d 100644 >> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi >> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi >> @@ -81,10 +81,10 @@ >> compatible = "arm,cortex-a15-gic"; >> #interrupt-cells = <3>; >> interrupt-controller; >> - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ >> - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ >> - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ >> - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ >> + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ >> + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ >> + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ >> + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ >> interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >> }; Any comments on this patch ? > > Thanks. I confirm that we have tested this. > > Jon. > > Thanks, Pranav ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-11 4:09 ` Pranavkumar Sawargaonkar 0 siblings, 0 replies; 44+ messages in thread From: Pranavkumar Sawargaonkar @ 2015-02-11 4:09 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tue, Jan 27, 2015 at 3:02 PM, Jon Masters <jcm@redhat.com> wrote: > On 01/27/2015 02:03 AM, Pranavkumar Sawargaonkar wrote: >> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >> size due to size alignment checking in vgic driver for VCPU Control and >> VCPU register. >> >> This patch corrects the sizes to be inline with the hardware spec. >> >> CC: linux-arm-kernel at lists.infradead.org >> CC: kvmarm at lists.cs.columbia.edu >> CC: arnd at arndb.de >> CC: marc.zyngier at arm.com >> CC: christoffer.dall at linaro.org >> CC: jcm at redhat.com >> Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> >> Signed-off-by: Tushar Jagad <tjagad@apm.com> >> Signed-off-by: Feng Kan <fkan@apm.com> >> --- >> arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi >> index f1ad9c2..65f0e6d 100644 >> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi >> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi >> @@ -81,10 +81,10 @@ >> compatible = "arm,cortex-a15-gic"; >> #interrupt-cells = <3>; >> interrupt-controller; >> - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ >> - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ >> - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ >> - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ >> + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ >> + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ >> + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ >> + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ >> interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >> }; Any comments on this patch ? > > Thanks. I confirm that we have tested this. > > Jon. > > Thanks, Pranav ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-01-27 7:03 ` Pranavkumar Sawargaonkar @ 2015-02-19 18:23 ` Rob Herring -1 siblings, 0 replies; 44+ messages in thread From: Rob Herring @ 2015-02-19 18:23 UTC (permalink / raw) To: Pranavkumar Sawargaonkar Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Feng Kan, Arnd Bergmann, Marc Zyngier, jcm-H+wXaHxf7aLQT0dZR+AlfA, patches-qTEPVZfXA3Y, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, Christoffer Dall, Tushar Jagad, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> wrote: > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > size due to size alignment checking in vgic driver for VCPU Control and > VCPU register. > > This patch corrects the sizes to be inline with the hardware spec. This does not make sense. The GIC regions are still only 4 or 8KB and the h/w description should reflect that. For implementations using gic-400 and the addressing decode trick, the rest of the register range is also not safe to access given it is multiple mapped. Also, this wastes virtual space, but I guess we don't care on 64-bit. KVM should be fixed to only check base address alignment. Size alignment does not matter (if it does, then you need to fix all register blocks). Rob > > CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > CC: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org > CC: arnd-r2nGTMty4D4@public.gmane.org > CC: marc.zyngier-5wv7dgnIgG8@public.gmane.org > CC: christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org > CC: jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org > Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> > Signed-off-by: Tushar Jagad <tjagad-qTEPVZfXA3Y@public.gmane.org> > Signed-off-by: Feng Kan <fkan-qTEPVZfXA3Y@public.gmane.org> > --- > arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi > index f1ad9c2..65f0e6d 100644 > --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi > +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi > @@ -81,10 +81,10 @@ > compatible = "arm,cortex-a15-gic"; > #interrupt-cells = <3>; > interrupt-controller; > - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ > - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ > - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ > - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ > + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ > + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ > + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ > + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ > interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ > }; > > -- > 1.7.9.5 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-19 18:23 ` Rob Herring 0 siblings, 0 replies; 44+ messages in thread From: Rob Herring @ 2015-02-19 18:23 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar <psawargaonkar@apm.com> wrote: > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > size due to size alignment checking in vgic driver for VCPU Control and > VCPU register. > > This patch corrects the sizes to be inline with the hardware spec. This does not make sense. The GIC regions are still only 4 or 8KB and the h/w description should reflect that. For implementations using gic-400 and the addressing decode trick, the rest of the register range is also not safe to access given it is multiple mapped. Also, this wastes virtual space, but I guess we don't care on 64-bit. KVM should be fixed to only check base address alignment. Size alignment does not matter (if it does, then you need to fix all register blocks). Rob > > CC: linux-arm-kernel at lists.infradead.org > CC: kvmarm at lists.cs.columbia.edu > CC: arnd at arndb.de > CC: marc.zyngier at arm.com > CC: christoffer.dall at linaro.org > CC: jcm at redhat.com > Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> > Signed-off-by: Tushar Jagad <tjagad@apm.com> > Signed-off-by: Feng Kan <fkan@apm.com> > --- > arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi > index f1ad9c2..65f0e6d 100644 > --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi > +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi > @@ -81,10 +81,10 @@ > compatible = "arm,cortex-a15-gic"; > #interrupt-cells = <3>; > interrupt-controller; > - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ > - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ > - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ > - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ > + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ > + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ > + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ > + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ > interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ > }; > > -- > 1.7.9.5 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <CAL_JsqJQcuX2cp50oHod-QAbhdMg48TaRP+gLGEO2kbFnQ3B+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-02-19 18:23 ` Rob Herring @ 2015-02-19 19:03 ` Christoffer Dall -1 siblings, 0 replies; 44+ messages in thread From: Christoffer Dall @ 2015-02-19 19:03 UTC (permalink / raw) To: Rob Herring Cc: Pranavkumar Sawargaonkar, devicetree-u79uwXL29TY76Z2rM5mHXA, Feng Kan, Arnd Bergmann, Marc Zyngier, jcm-H+wXaHxf7aLQT0dZR+AlfA, patches-qTEPVZfXA3Y, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, Tushar Jagad, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: > On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar > <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> wrote: > > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > > size due to size alignment checking in vgic driver for VCPU Control and > > VCPU register. > > > > This patch corrects the sizes to be inline with the hardware spec. > > This does not make sense. The GIC regions are still only 4 or 8KB and > the h/w description should reflect that. For implementations using > gic-400 and the addressing decode trick, the rest of the register > range is also not safe to access given it is multiple mapped. Also, > this wastes virtual space, but I guess we don't care on 64-bit. > > KVM should be fixed to only check base address alignment. Size > alignment does not matter (if it does, then you need to fix all > register blocks). > It matters if you want to ensure that the 64K page you are assigning to a guest for the GIC virtual CPU interface contains only GIC virtual CPU mappings, and not other random stuff that the guest is not allowed to touch. How else should this be enforced? -Christoffer -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-19 19:03 ` Christoffer Dall 0 siblings, 0 replies; 44+ messages in thread From: Christoffer Dall @ 2015-02-19 19:03 UTC (permalink / raw) To: linux-arm-kernel On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: > On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar > <psawargaonkar@apm.com> wrote: > > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > > size due to size alignment checking in vgic driver for VCPU Control and > > VCPU register. > > > > This patch corrects the sizes to be inline with the hardware spec. > > This does not make sense. The GIC regions are still only 4 or 8KB and > the h/w description should reflect that. For implementations using > gic-400 and the addressing decode trick, the rest of the register > range is also not safe to access given it is multiple mapped. Also, > this wastes virtual space, but I guess we don't care on 64-bit. > > KVM should be fixed to only check base address alignment. Size > alignment does not matter (if it does, then you need to fix all > register blocks). > It matters if you want to ensure that the 64K page you are assigning to a guest for the GIC virtual CPU interface contains only GIC virtual CPU mappings, and not other random stuff that the guest is not allowed to touch. How else should this be enforced? -Christoffer ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-02-19 19:03 ` Christoffer Dall @ 2015-02-21 21:56 ` Rob Herring -1 siblings, 0 replies; 44+ messages in thread From: Rob Herring @ 2015-02-21 21:56 UTC (permalink / raw) To: Christoffer Dall Cc: Pranavkumar Sawargaonkar, devicetree-u79uwXL29TY76Z2rM5mHXA, Feng Kan, Arnd Bergmann, Marc Zyngier, jcm-H+wXaHxf7aLQT0dZR+AlfA, patches-qTEPVZfXA3Y, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, Tushar Jagad, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >> <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> wrote: >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >> > size due to size alignment checking in vgic driver for VCPU Control and >> > VCPU register. >> > >> > This patch corrects the sizes to be inline with the hardware spec. >> >> This does not make sense. The GIC regions are still only 4 or 8KB and >> the h/w description should reflect that. For implementations using >> gic-400 and the addressing decode trick, the rest of the register >> range is also not safe to access given it is multiple mapped. Also, >> this wastes virtual space, but I guess we don't care on 64-bit. >> >> KVM should be fixed to only check base address alignment. Size >> alignment does not matter (if it does, then you need to fix all >> register blocks). >> > It matters if you want to ensure that the 64K page you are assigning to > a guest for the GIC virtual CPU interface contains only GIC virtual CPU > mappings, and not other random stuff that the guest is not allowed to > touch. Good point. > How else should this be enforced? Rely on correct h/w design? You'll have to repeat this every time you want to do pass-thru of a device. What do you do if 64K mapping is not supported? Fallback to emulation of the CPU interface? Are there other DTSs that need to be fixed? Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-21 21:56 ` Rob Herring 0 siblings, 0 replies; 44+ messages in thread From: Rob Herring @ 2015-02-21 21:56 UTC (permalink / raw) To: linux-arm-kernel On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall <christoffer.dall@linaro.org> wrote: > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >> <psawargaonkar@apm.com> wrote: >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >> > size due to size alignment checking in vgic driver for VCPU Control and >> > VCPU register. >> > >> > This patch corrects the sizes to be inline with the hardware spec. >> >> This does not make sense. The GIC regions are still only 4 or 8KB and >> the h/w description should reflect that. For implementations using >> gic-400 and the addressing decode trick, the rest of the register >> range is also not safe to access given it is multiple mapped. Also, >> this wastes virtual space, but I guess we don't care on 64-bit. >> >> KVM should be fixed to only check base address alignment. Size >> alignment does not matter (if it does, then you need to fix all >> register blocks). >> > It matters if you want to ensure that the 64K page you are assigning to > a guest for the GIC virtual CPU interface contains only GIC virtual CPU > mappings, and not other random stuff that the guest is not allowed to > touch. Good point. > How else should this be enforced? Rely on correct h/w design? You'll have to repeat this every time you want to do pass-thru of a device. What do you do if 64K mapping is not supported? Fallback to emulation of the CPU interface? Are there other DTSs that need to be fixed? Rob ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <CAL_JsqLcBOC+AnVe7oATjg2g6Fz2vqwacu8QzS4tXMaxxOP_Xg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-02-21 21:56 ` Rob Herring @ 2015-02-21 23:58 ` Peter Maydell -1 siblings, 0 replies; 44+ messages in thread From: Peter Maydell @ 2015-02-21 23:58 UTC (permalink / raw) To: Rob Herring Cc: Christoffer Dall, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Feng Kan, Marc Zyngier, jcm-H+wXaHxf7aLQT0dZR+AlfA, patches-qTEPVZfXA3Y, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, Tushar Jagad, Pranavkumar Sawargaonkar, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On 22 February 2015 at 06:56, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall > <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >> It matters if you want to ensure that the 64K page you are assigning to >> a guest for the GIC virtual CPU interface contains only GIC virtual CPU >> mappings, and not other random stuff that the guest is not allowed to >> touch. > > Good point. > >> How else should this be enforced? > > Rely on correct h/w design? You'll have to repeat this every time you > want to do pass-thru of a device. The idea is that the device tree lets us describe whether the hardware design is correct or not :-) > What do you do if 64K mapping is not supported? Fallback to emulation > of the CPU interface? In this case KVM can't be supported -- use 4K host pages with this hardware, or don't use KVM... -- PMM -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-21 23:58 ` Peter Maydell 0 siblings, 0 replies; 44+ messages in thread From: Peter Maydell @ 2015-02-21 23:58 UTC (permalink / raw) To: linux-arm-kernel On 22 February 2015 at 06:56, Rob Herring <robherring2@gmail.com> wrote: > On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: >> It matters if you want to ensure that the 64K page you are assigning to >> a guest for the GIC virtual CPU interface contains only GIC virtual CPU >> mappings, and not other random stuff that the guest is not allowed to >> touch. > > Good point. > >> How else should this be enforced? > > Rely on correct h/w design? You'll have to repeat this every time you > want to do pass-thru of a device. The idea is that the device tree lets us describe whether the hardware design is correct or not :-) > What do you do if 64K mapping is not supported? Fallback to emulation > of the CPU interface? In this case KVM can't be supported -- use 4K host pages with this hardware, or don't use KVM... -- PMM ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-02-21 21:56 ` Rob Herring @ 2015-02-23 12:07 ` Christoffer Dall -1 siblings, 0 replies; 44+ messages in thread From: Christoffer Dall @ 2015-02-23 12:07 UTC (permalink / raw) To: Rob Herring Cc: Pranavkumar Sawargaonkar, devicetree-u79uwXL29TY76Z2rM5mHXA, Feng Kan, Arnd Bergmann, Marc Zyngier, jcm-H+wXaHxf7aLQT0dZR+AlfA, patches-qTEPVZfXA3Y, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, Tushar Jagad, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Will Deacon On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: > On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall > <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: > >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar > >> <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> wrote: > >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > >> > size due to size alignment checking in vgic driver for VCPU Control and > >> > VCPU register. > >> > > >> > This patch corrects the sizes to be inline with the hardware spec. > >> > >> This does not make sense. The GIC regions are still only 4 or 8KB and > >> the h/w description should reflect that. For implementations using > >> gic-400 and the addressing decode trick, the rest of the register > >> range is also not safe to access given it is multiple mapped. Also, > >> this wastes virtual space, but I guess we don't care on 64-bit. > >> > >> KVM should be fixed to only check base address alignment. Size > >> alignment does not matter (if it does, then you need to fix all > >> register blocks). > >> > > It matters if you want to ensure that the 64K page you are assigning to > > a guest for the GIC virtual CPU interface contains only GIC virtual CPU > > mappings, and not other random stuff that the guest is not allowed to > > touch. > > Good point. > > > How else should this be enforced? > > Rely on correct h/w design? You'll have to repeat this every time you > want to do pass-thru of a device. > > What do you do if 64K mapping is not supported? Fallback to emulation > of the CPU interface? Agree with Peter on these two points. > > Are there other DTSs that need to be fixed? > Not sure really, AMD Seattle works with 64K pages IIRC. Thanks, -Christoffer -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-23 12:07 ` Christoffer Dall 0 siblings, 0 replies; 44+ messages in thread From: Christoffer Dall @ 2015-02-23 12:07 UTC (permalink / raw) To: linux-arm-kernel On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: > On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: > > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: > >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar > >> <psawargaonkar@apm.com> wrote: > >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > >> > size due to size alignment checking in vgic driver for VCPU Control and > >> > VCPU register. > >> > > >> > This patch corrects the sizes to be inline with the hardware spec. > >> > >> This does not make sense. The GIC regions are still only 4 or 8KB and > >> the h/w description should reflect that. For implementations using > >> gic-400 and the addressing decode trick, the rest of the register > >> range is also not safe to access given it is multiple mapped. Also, > >> this wastes virtual space, but I guess we don't care on 64-bit. > >> > >> KVM should be fixed to only check base address alignment. Size > >> alignment does not matter (if it does, then you need to fix all > >> register blocks). > >> > > It matters if you want to ensure that the 64K page you are assigning to > > a guest for the GIC virtual CPU interface contains only GIC virtual CPU > > mappings, and not other random stuff that the guest is not allowed to > > touch. > > Good point. > > > How else should this be enforced? > > Rely on correct h/w design? You'll have to repeat this every time you > want to do pass-thru of a device. > > What do you do if 64K mapping is not supported? Fallback to emulation > of the CPU interface? Agree with Peter on these two points. > > Are there other DTSs that need to be fixed? > Not sure really, AMD Seattle works with 64K pages IIRC. Thanks, -Christoffer ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-02-23 12:07 ` Christoffer Dall @ 2015-02-23 12:24 ` Jon Masters -1 siblings, 0 replies; 44+ messages in thread From: Jon Masters @ 2015-02-23 12:24 UTC (permalink / raw) To: Christoffer Dall Cc: devicetree, Arnd Bergmann, Feng Kan, Marc Zyngier, Will Deacon, patches, kvmarm, Rob Herring, Tushar Jagad, Pranavkumar Sawargaonkar, linux-arm-kernel Sorry about top post. Quick comment in reply to Seattle point below - yes, it does indeed support 64K and already has the right DTS. -- Computer Architect | Sent from my #ARM Powered Mobile Device On Feb 23, 2015 4:14 AM, Christoffer Dall <christoffer.dall@linaro.org> wrote: > > On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: > > On Thu, Feb 1On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: > On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: > > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: > >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar > >> <psawargaonkar@apm.com> wrote: > >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > >> > size due to size alignment checking in vgic driver for VCPU Control and > >> > VCPU register. > >> > > >> > This patch corrects the sizes to be inline with the hardware spec. > >> > >> This does not make sense. The GIC regions are still only 4 or 8KB and > >> the h/w description should reflect that. For implementations using > >> gic-400 and the addressing decode trick, the rest of the register > >> range is also not safe to access given it is multiple mapped. Also, > >> this wastes virtual space, but I guess we don't care on 64-bit. > >> > >> KVM should be fixed to only check base address alignment. Size > >> alignment does not matter (if it does, then you need to fix all > >> register blocks). > >> > > It matters if you want to ensure that the 64K page you are assigning to > > a guest for the GIC virtual CPU interface contains only GIC virtual CPU > > mappings, and not other random stuff that the guest is not allowed to > > touch. > > Good point. > > > How else should this be enforced? > > Rely on correct h/w design? You'll have to repeat this every time you > want to do pass-thru of a device. > > What do you do if 64K mapping is not supported? Fallback to emulation > of the CPU interface? Agree with Peter on these two points. > > Are there other DTSs that need to be fixed? > Not sure really, AMD Seattle works with 64K pages IIRC. Thanks, -Christoffer ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-23 12:24 ` Jon Masters 0 siblings, 0 replies; 44+ messages in thread From: Jon Masters @ 2015-02-23 12:24 UTC (permalink / raw) To: linux-arm-kernel Sorry about top post. Quick comment in reply to Seattle point below - yes, it does indeed support 64K and already has the right DTS. -- Computer Architect | Sent from my #ARM Powered Mobile Device On Feb 23, 2015 4:14 AM, Christoffer Dall <christoffer.dall@linaro.org> wrote: > > On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: > > On Thu, Feb 1On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: > On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: > > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: > >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar > >> <psawargaonkar@apm.com> wrote: > >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > >> > size due to size alignment checking in vgic driver for VCPU Control and > >> > VCPU register. > >> > > >> > This patch corrects the sizes to be inline with the hardware spec. > >> > >> This does not make sense. The GIC regions are still only 4 or 8KB and > >> the h/w description should reflect that. For implementations using > >> gic-400 and the addressing decode trick, the rest of the register > >> range is also not safe to access given it is multiple mapped. Also, > >> this wastes virtual space, but I guess we don't care on 64-bit. > >> > >> KVM should be fixed to only check base address alignment. Size > >> alignment does not matter (if it does, then you need to fix all > >> register blocks). > >> > > It matters if you want to ensure that the 64K page you are assigning to > > a guest for the GIC virtual CPU interface contains only GIC virtual CPU > > mappings, and not other random stuff that the guest is not allowed to > > touch. > > Good point. > > > How else should this be enforced? > > Rely on correct h/w design? You'll have to repeat this every time you > want to do pass-thru of a device. > > What do you do if 64K mapping is not supported? Fallback to emulation > of the CPU interface? Agree with Peter on these two points. > > Are there other DTSs that need to be fixed? > Not sure really, AMD Seattle works with 64K pages IIRC. Thanks, -Christoffer ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-02-23 12:07 ` Christoffer Dall @ 2015-02-23 16:39 ` Rob Herring -1 siblings, 0 replies; 44+ messages in thread From: Rob Herring @ 2015-02-23 16:39 UTC (permalink / raw) To: Christoffer Dall Cc: Pranavkumar Sawargaonkar, devicetree-u79uwXL29TY76Z2rM5mHXA, Feng Kan, Arnd Bergmann, Marc Zyngier, jcm-H+wXaHxf7aLQT0dZR+AlfA, patches-qTEPVZfXA3Y, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, Tushar Jagad, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Will Deacon On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >> <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >> >> <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> wrote: >> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >> >> > size due to size alignment checking in vgic driver for VCPU Control and >> >> > VCPU register. >> >> > >> >> > This patch corrects the sizes to be inline with the hardware spec. >> >> >> >> This does not make sense. The GIC regions are still only 4 or 8KB and >> >> the h/w description should reflect that. For implementations using >> >> gic-400 and the addressing decode trick, the rest of the register >> >> range is also not safe to access given it is multiple mapped. Also, >> >> this wastes virtual space, but I guess we don't care on 64-bit. >> >> >> >> KVM should be fixed to only check base address alignment. Size >> >> alignment does not matter (if it does, then you need to fix all >> >> register blocks). >> >> >> > It matters if you want to ensure that the 64K page you are assigning to >> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU >> > mappings, and not other random stuff that the guest is not allowed to >> > touch. >> >> Good point. >> >> > How else should this be enforced? >> >> Rely on correct h/w design? You'll have to repeat this every time you >> want to do pass-thru of a device. >> >> What do you do if 64K mapping is not supported? Fallback to emulation >> of the CPU interface? > > Agree with Peter on these two points. > >> >> Are there other DTSs that need to be fixed? >> > Not sure really, AMD Seattle works with 64K pages IIRC. Well, looks we have been inconsistent here: arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 0xe1110000 0 0x1000>, arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 0xe112f000 0 0x2000>, arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 0xe1140000 0 0x10000>, arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 0xe1160000 0 0x10000>; arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c010000 0 0x1000>, arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; If we are going to use 64K sizes, can we have some consistency here please. Which ranges really need 64KB sizes? It should only be the VCPU interface. right? Why does XGene need 128K? If XGene is doing address swizzling, then the CPU and VCPU base addresses are wrong. Seattle is also wrong for the VCPU, but no one has noticed because we don't use the DIR register IIRC. XGene should also add an "arm,gic-400" compatible string or something XGene specific if in fact it is not GIC-400. I think perhaps we need a specific compatible property to indicate a GIC-400 with address swizzling. While we could get away with using the aliased addresses, that seems to be hard to get right and we may regret not doing it in the long term. It would indicate at least it is 64K page safe for example. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-23 16:39 ` Rob Herring 0 siblings, 0 replies; 44+ messages in thread From: Rob Herring @ 2015-02-23 16:39 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall <christoffer.dall@linaro.org> wrote: > On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >> <christoffer.dall@linaro.org> wrote: >> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >> >> <psawargaonkar@apm.com> wrote: >> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >> >> > size due to size alignment checking in vgic driver for VCPU Control and >> >> > VCPU register. >> >> > >> >> > This patch corrects the sizes to be inline with the hardware spec. >> >> >> >> This does not make sense. The GIC regions are still only 4 or 8KB and >> >> the h/w description should reflect that. For implementations using >> >> gic-400 and the addressing decode trick, the rest of the register >> >> range is also not safe to access given it is multiple mapped. Also, >> >> this wastes virtual space, but I guess we don't care on 64-bit. >> >> >> >> KVM should be fixed to only check base address alignment. Size >> >> alignment does not matter (if it does, then you need to fix all >> >> register blocks). >> >> >> > It matters if you want to ensure that the 64K page you are assigning to >> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU >> > mappings, and not other random stuff that the guest is not allowed to >> > touch. >> >> Good point. >> >> > How else should this be enforced? >> >> Rely on correct h/w design? You'll have to repeat this every time you >> want to do pass-thru of a device. >> >> What do you do if 64K mapping is not supported? Fallback to emulation >> of the CPU interface? > > Agree with Peter on these two points. > >> >> Are there other DTSs that need to be fixed? >> > Not sure really, AMD Seattle works with 64K pages IIRC. Well, looks we have been inconsistent here: arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 0xe1110000 0 0x1000>, arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 0xe112f000 0 0x2000>, arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 0xe1140000 0 0x10000>, arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 0xe1160000 0 0x10000>; arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c010000 0 0x1000>, arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; If we are going to use 64K sizes, can we have some consistency here please. Which ranges really need 64KB sizes? It should only be the VCPU interface. right? Why does XGene need 128K? If XGene is doing address swizzling, then the CPU and VCPU base addresses are wrong. Seattle is also wrong for the VCPU, but no one has noticed because we don't use the DIR register IIRC. XGene should also add an "arm,gic-400" compatible string or something XGene specific if in fact it is not GIC-400. I think perhaps we need a specific compatible property to indicate a GIC-400 with address swizzling. While we could get away with using the aliased addresses, that seems to be hard to get right and we may regret not doing it in the long term. It would indicate at least it is 64K page safe for example. Rob ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-02-23 16:39 ` Rob Herring @ 2015-02-24 6:34 ` Pranavkumar Sawargaonkar -1 siblings, 0 replies; 44+ messages in thread From: Pranavkumar Sawargaonkar @ 2015-02-24 6:34 UTC (permalink / raw) To: Rob Herring Cc: devicetree, Arnd Bergmann, Feng Kan, Marc Zyngier, jcm, patches, Will Deacon, linux-arm-kernel, Tushar Jagad, kvmarm Hi Rob, On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring <robherring2@gmail.com> wrote: > On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: >> On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >>> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >>> <christoffer.dall@linaro.org> wrote: >>> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >>> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >>> >> <psawargaonkar@apm.com> wrote: >>> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>> >> > size due to size alignment checking in vgic driver for VCPU Control and >>> >> > VCPU register. >>> >> > >>> >> > This patch corrects the sizes to be inline with the hardware spec. >>> >> >>> >> This does not make sense. The GIC regions are still only 4 or 8KB and >>> >> the h/w description should reflect that. For implementations using >>> >> gic-400 and the addressing decode trick, the rest of the register >>> >> range is also not safe to access given it is multiple mapped. Also, >>> >> this wastes virtual space, but I guess we don't care on 64-bit. >>> >> >>> >> KVM should be fixed to only check base address alignment. Size >>> >> alignment does not matter (if it does, then you need to fix all >>> >> register blocks). >>> >> >>> > It matters if you want to ensure that the 64K page you are assigning to >>> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU >>> > mappings, and not other random stuff that the guest is not allowed to >>> > touch. >>> >>> Good point. >>> >>> > How else should this be enforced? >>> >>> Rely on correct h/w design? You'll have to repeat this every time you >>> want to do pass-thru of a device. >>> >>> What do you do if 64K mapping is not supported? Fallback to emulation >>> of the CPU interface? >> >> Agree with Peter on these two points. >> >>> >>> Are there other DTSs that need to be fixed? >>> >> Not sure really, AMD Seattle works with 64K pages IIRC. > > Well, looks we have been inconsistent here: > > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 > 0xe1110000 0 0x1000>, > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 > 0xe112f000 0 0x2000>, > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 > 0xe1140000 0 0x10000>, > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 > 0xe1160000 0 0x10000>; > > arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c010000 0 0x1000>, > arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, > arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, > arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; > > If we are going to use 64K sizes, can we have some consistency here > please. Which ranges really need 64KB sizes? It should only be the > VCPU interface. right? Why does XGene need 128K? If XGene is doing > address swizzling, then the CPU and VCPU base addresses are wrong. > Seattle is also wrong for the VCPU, but no one has noticed because we > don't use the DIR register IIRC. > > XGene should also add an "arm,gic-400" compatible string or something > XGene specific if in fact it is not GIC-400. X-Gene has gic-400 as an interrupt controller. Only thing is GIC pages are mapped at 64K boundary (with 64K page size) Hence CPU, VCPU interfaces has a size of 128K (2GIC pages) Regarding GICC_DIR, yes there is a problem which needs to be solved since the first page size is 64K. In XEN we already have a small fix to access GICC_DIR with 64K page offset instead of standard 4K. I remember a small discussion in this regard in past (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html) which was deferred at that time. Once this patch is accepted we can post RFC patch to address GICC_DIR and discuss further. > > I think perhaps we need a specific compatible property to indicate a > GIC-400 with address swizzling. While we could get away with using the > aliased addresses, that seems to be hard to get right and we may > regret not doing it in the long term. It would indicate at least it is > 64K page safe for example. > > Rob Thanks, Pranav ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-24 6:34 ` Pranavkumar Sawargaonkar 0 siblings, 0 replies; 44+ messages in thread From: Pranavkumar Sawargaonkar @ 2015-02-24 6:34 UTC (permalink / raw) To: linux-arm-kernel Hi Rob, On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring <robherring2@gmail.com> wrote: > On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall > <christoffer.dall@linaro.org> wrote: >> On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >>> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >>> <christoffer.dall@linaro.org> wrote: >>> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >>> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >>> >> <psawargaonkar@apm.com> wrote: >>> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>> >> > size due to size alignment checking in vgic driver for VCPU Control and >>> >> > VCPU register. >>> >> > >>> >> > This patch corrects the sizes to be inline with the hardware spec. >>> >> >>> >> This does not make sense. The GIC regions are still only 4 or 8KB and >>> >> the h/w description should reflect that. For implementations using >>> >> gic-400 and the addressing decode trick, the rest of the register >>> >> range is also not safe to access given it is multiple mapped. Also, >>> >> this wastes virtual space, but I guess we don't care on 64-bit. >>> >> >>> >> KVM should be fixed to only check base address alignment. Size >>> >> alignment does not matter (if it does, then you need to fix all >>> >> register blocks). >>> >> >>> > It matters if you want to ensure that the 64K page you are assigning to >>> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU >>> > mappings, and not other random stuff that the guest is not allowed to >>> > touch. >>> >>> Good point. >>> >>> > How else should this be enforced? >>> >>> Rely on correct h/w design? You'll have to repeat this every time you >>> want to do pass-thru of a device. >>> >>> What do you do if 64K mapping is not supported? Fallback to emulation >>> of the CPU interface? >> >> Agree with Peter on these two points. >> >>> >>> Are there other DTSs that need to be fixed? >>> >> Not sure really, AMD Seattle works with 64K pages IIRC. > > Well, looks we have been inconsistent here: > > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 > 0xe1110000 0 0x1000>, > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 > 0xe112f000 0 0x2000>, > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 > 0xe1140000 0 0x10000>, > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 > 0xe1160000 0 0x10000>; > > arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c010000 0 0x1000>, > arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, > arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, > arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; > > If we are going to use 64K sizes, can we have some consistency here > please. Which ranges really need 64KB sizes? It should only be the > VCPU interface. right? Why does XGene need 128K? If XGene is doing > address swizzling, then the CPU and VCPU base addresses are wrong. > Seattle is also wrong for the VCPU, but no one has noticed because we > don't use the DIR register IIRC. > > XGene should also add an "arm,gic-400" compatible string or something > XGene specific if in fact it is not GIC-400. X-Gene has gic-400 as an interrupt controller. Only thing is GIC pages are mapped at 64K boundary (with 64K page size) Hence CPU, VCPU interfaces has a size of 128K (2GIC pages) Regarding GICC_DIR, yes there is a problem which needs to be solved since the first page size is 64K. In XEN we already have a small fix to access GICC_DIR with 64K page offset instead of standard 4K. I remember a small discussion in this regard in past (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html) which was deferred at that time. Once this patch is accepted we can post RFC patch to address GICC_DIR and discuss further. > > I think perhaps we need a specific compatible property to indicate a > GIC-400 with address swizzling. While we could get away with using the > aliased addresses, that seems to be hard to get right and we may > regret not doing it in the long term. It would indicate at least it is > 64K page safe for example. > > Rob Thanks, Pranav ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <CANFfpkQF-8Kzq-UoP=xLpkTafGn6ScyiEb6oCs-Lxygb+ummLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-02-24 6:34 ` Pranavkumar Sawargaonkar @ 2015-02-24 14:30 ` Rob Herring -1 siblings, 0 replies; 44+ messages in thread From: Rob Herring @ 2015-02-24 14:30 UTC (permalink / raw) To: Pranavkumar Sawargaonkar Cc: Christoffer Dall, devicetree-u79uwXL29TY76Z2rM5mHXA, Feng Kan, Arnd Bergmann, Marc Zyngier, jcm-H+wXaHxf7aLQT0dZR+AlfA, patches-qTEPVZfXA3Y, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, Tushar Jagad, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Will Deacon On Tue, Feb 24, 2015 at 12:34 AM, Pranavkumar Sawargaonkar <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> wrote: > Hi Rob, > > On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall >> <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>> On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >>>> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >>>> <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>>> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >>>> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >>>> >> <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> wrote: >>>> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>> >> > size due to size alignment checking in vgic driver for VCPU Control and >>>> >> > VCPU register. >>>> >> > >>>> >> > This patch corrects the sizes to be inline with the hardware spec. >>>> >> >>>> >> This does not make sense. The GIC regions are still only 4 or 8KB and >>>> >> the h/w description should reflect that. For implementations using >>>> >> gic-400 and the addressing decode trick, the rest of the register >>>> >> range is also not safe to access given it is multiple mapped. Also, >>>> >> this wastes virtual space, but I guess we don't care on 64-bit. >>>> >> >>>> >> KVM should be fixed to only check base address alignment. Size >>>> >> alignment does not matter (if it does, then you need to fix all >>>> >> register blocks). >>>> >> >>>> > It matters if you want to ensure that the 64K page you are assigning to >>>> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU >>>> > mappings, and not other random stuff that the guest is not allowed to >>>> > touch. >>>> >>>> Good point. >>>> >>>> > How else should this be enforced? >>>> >>>> Rely on correct h/w design? You'll have to repeat this every time you >>>> want to do pass-thru of a device. >>>> >>>> What do you do if 64K mapping is not supported? Fallback to emulation >>>> of the CPU interface? >>> >>> Agree with Peter on these two points. >>> >>>> >>>> Are there other DTSs that need to be fixed? >>>> >>> Not sure really, AMD Seattle works with 64K pages IIRC. >> >> Well, looks we have been inconsistent here: >> >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 >> 0xe1110000 0 0x1000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe112f000 0 0x2000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe1140000 0 0x10000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe1160000 0 0x10000>; >> >> arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c010000 0 0x1000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; >> >> If we are going to use 64K sizes, can we have some consistency here >> please. Which ranges really need 64KB sizes? It should only be the >> VCPU interface. right? Why does XGene need 128K? If XGene is doing >> address swizzling, then the CPU and VCPU base addresses are wrong. >> Seattle is also wrong for the VCPU, but no one has noticed because we >> don't use the DIR register IIRC. >> >> XGene should also add an "arm,gic-400" compatible string or something >> XGene specific if in fact it is not GIC-400. > > X-Gene has gic-400 as an interrupt controller. > Only thing is GIC pages are mapped at 64K boundary (with 64K page size) > Hence CPU, VCPU interfaces has a size of 128K (2GIC pages) > Regarding GICC_DIR, yes there is a problem which needs to be solved > since the first page size is 64K. > In XEN we already have a small fix to access GICC_DIR with 64K page > offset instead of standard 4K. Right, and in order for this to work, you should use the last 4K alias for the cpu interface(s). This is why other platforms use xxxf000 as their cpu interface base. It is of course possible that xgene does not properly do the address swizzling and therefore you have to use 64K aligned addresses. But in that case you need a unique compatible string. > I remember a small discussion in this regard in past > (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html) > which was deferred at that time. > Once this patch is accepted we can post RFC patch to address GICC_DIR > and discuss further. No, let's get this right now and not keep changing the dts. Rob > >> >> I think perhaps we need a specific compatible property to indicate a >> GIC-400 with address swizzling. While we could get away with using the >> aliased addresses, that seems to be hard to get right and we may >> regret not doing it in the long term. It would indicate at least it is >> 64K page safe for example. >> >> Rob > > Thanks, > Pranav -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-24 14:30 ` Rob Herring 0 siblings, 0 replies; 44+ messages in thread From: Rob Herring @ 2015-02-24 14:30 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 24, 2015 at 12:34 AM, Pranavkumar Sawargaonkar <psawargaonkar@apm.com> wrote: > Hi Rob, > > On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring <robherring2@gmail.com> wrote: >> On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall >> <christoffer.dall@linaro.org> wrote: >>> On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >>>> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >>>> <christoffer.dall@linaro.org> wrote: >>>> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >>>> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >>>> >> <psawargaonkar@apm.com> wrote: >>>> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>> >> > size due to size alignment checking in vgic driver for VCPU Control and >>>> >> > VCPU register. >>>> >> > >>>> >> > This patch corrects the sizes to be inline with the hardware spec. >>>> >> >>>> >> This does not make sense. The GIC regions are still only 4 or 8KB and >>>> >> the h/w description should reflect that. For implementations using >>>> >> gic-400 and the addressing decode trick, the rest of the register >>>> >> range is also not safe to access given it is multiple mapped. Also, >>>> >> this wastes virtual space, but I guess we don't care on 64-bit. >>>> >> >>>> >> KVM should be fixed to only check base address alignment. Size >>>> >> alignment does not matter (if it does, then you need to fix all >>>> >> register blocks). >>>> >> >>>> > It matters if you want to ensure that the 64K page you are assigning to >>>> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU >>>> > mappings, and not other random stuff that the guest is not allowed to >>>> > touch. >>>> >>>> Good point. >>>> >>>> > How else should this be enforced? >>>> >>>> Rely on correct h/w design? You'll have to repeat this every time you >>>> want to do pass-thru of a device. >>>> >>>> What do you do if 64K mapping is not supported? Fallback to emulation >>>> of the CPU interface? >>> >>> Agree with Peter on these two points. >>> >>>> >>>> Are there other DTSs that need to be fixed? >>>> >>> Not sure really, AMD Seattle works with 64K pages IIRC. >> >> Well, looks we have been inconsistent here: >> >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 >> 0xe1110000 0 0x1000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe112f000 0 0x2000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe1140000 0 0x10000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe1160000 0 0x10000>; >> >> arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c010000 0 0x1000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; >> >> If we are going to use 64K sizes, can we have some consistency here >> please. Which ranges really need 64KB sizes? It should only be the >> VCPU interface. right? Why does XGene need 128K? If XGene is doing >> address swizzling, then the CPU and VCPU base addresses are wrong. >> Seattle is also wrong for the VCPU, but no one has noticed because we >> don't use the DIR register IIRC. >> >> XGene should also add an "arm,gic-400" compatible string or something >> XGene specific if in fact it is not GIC-400. > > X-Gene has gic-400 as an interrupt controller. > Only thing is GIC pages are mapped at 64K boundary (with 64K page size) > Hence CPU, VCPU interfaces has a size of 128K (2GIC pages) > Regarding GICC_DIR, yes there is a problem which needs to be solved > since the first page size is 64K. > In XEN we already have a small fix to access GICC_DIR with 64K page > offset instead of standard 4K. Right, and in order for this to work, you should use the last 4K alias for the cpu interface(s). This is why other platforms use xxxf000 as their cpu interface base. It is of course possible that xgene does not properly do the address swizzling and therefore you have to use 64K aligned addresses. But in that case you need a unique compatible string. > I remember a small discussion in this regard in past > (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html) > which was deferred at that time. > Once this patch is accepted we can post RFC patch to address GICC_DIR > and discuss further. No, let's get this right now and not keep changing the dts. Rob > >> >> I think perhaps we need a specific compatible property to indicate a >> GIC-400 with address swizzling. While we could get away with using the >> aliased addresses, that seems to be hard to get right and we may >> regret not doing it in the long term. It would indicate at least it is >> 64K page safe for example. >> >> Rob > > Thanks, > Pranav ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <CAL_JsqLs4HdT6N=Vb4s--x3ugXKbWYQ5R2WGbiWFhhnYxnK-xw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-02-24 14:30 ` Rob Herring @ 2015-02-27 3:57 ` Pranavkumar Sawargaonkar -1 siblings, 0 replies; 44+ messages in thread From: Pranavkumar Sawargaonkar @ 2015-02-27 3:57 UTC (permalink / raw) To: Rob Herring Cc: Christoffer Dall, devicetree-u79uwXL29TY76Z2rM5mHXA, Feng Kan, Arnd Bergmann, Marc Zyngier, jcm-H+wXaHxf7aLQT0dZR+AlfA, patches-qTEPVZfXA3Y, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, Tushar Jagad, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Will Deacon Hi Rob, On Tue, Feb 24, 2015 at 8:00 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > On Tue, Feb 24, 2015 at 12:34 AM, Pranavkumar Sawargaonkar > <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> wrote: >> Hi Rob, >> >> On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>> On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall >>> <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>>> On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >>>>> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >>>>> <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>>>> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >>>>> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >>>>> >> <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> wrote: >>>>> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>>> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>>> >> > size due to size alignment checking in vgic driver for VCPU Control and >>>>> >> > VCPU register. >>>>> >> > >>>>> >> > This patch corrects the sizes to be inline with the hardware spec. >>>>> >> >>>>> >> This does not make sense. The GIC regions are still only 4 or 8KB and >>>>> >> the h/w description should reflect that. For implementations using >>>>> >> gic-400 and the addressing decode trick, the rest of the register >>>>> >> range is also not safe to access given it is multiple mapped. Also, >>>>> >> this wastes virtual space, but I guess we don't care on 64-bit. >>>>> >> >>>>> >> KVM should be fixed to only check base address alignment. Size >>>>> >> alignment does not matter (if it does, then you need to fix all >>>>> >> register blocks). >>>>> >> >>>>> > It matters if you want to ensure that the 64K page you are assigning to >>>>> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU >>>>> > mappings, and not other random stuff that the guest is not allowed to >>>>> > touch. >>>>> >>>>> Good point. >>>>> >>>>> > How else should this be enforced? >>>>> >>>>> Rely on correct h/w design? You'll have to repeat this every time you >>>>> want to do pass-thru of a device. >>>>> >>>>> What do you do if 64K mapping is not supported? Fallback to emulation >>>>> of the CPU interface? >>>> >>>> Agree with Peter on these two points. >>>> >>>>> >>>>> Are there other DTSs that need to be fixed? >>>>> >>>> Not sure really, AMD Seattle works with 64K pages IIRC. >>> >>> Well, looks we have been inconsistent here: >>> >>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 >>> 0xe1110000 0 0x1000>, >>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >>> 0xe112f000 0 0x2000>, >>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >>> 0xe1140000 0 0x10000>, >>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >>> 0xe1160000 0 0x10000>; >>> >>> arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c010000 0 0x1000>, >>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, >>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, >>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; >>> >>> If we are going to use 64K sizes, can we have some consistency here >>> please. Which ranges really need 64KB sizes? It should only be the >>> VCPU interface. right? Why does XGene need 128K? If XGene is doing >>> address swizzling, then the CPU and VCPU base addresses are wrong. >>> Seattle is also wrong for the VCPU, but no one has noticed because we >>> don't use the DIR register IIRC. >>> >>> XGene should also add an "arm,gic-400" compatible string or something >>> XGene specific if in fact it is not GIC-400. >> >> X-Gene has gic-400 as an interrupt controller. >> Only thing is GIC pages are mapped at 64K boundary (with 64K page size) >> Hence CPU, VCPU interfaces has a size of 128K (2GIC pages) >> Regarding GICC_DIR, yes there is a problem which needs to be solved >> since the first page size is 64K. >> In XEN we already have a small fix to access GICC_DIR with 64K page >> offset instead of standard 4K. > > Right, and in order for this to work, you should use the last 4K alias > for the cpu interface(s). This is why other platforms use xxxf000 as > their cpu interface base. > > It is of course possible that xgene does not properly do the address > swizzling and therefore you have to use 64K aligned addresses. But in > that case you need a unique compatible string. > >> I remember a small discussion in this regard in past >> (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html) >> which was deferred at that time. >> Once this patch is accepted we can post RFC patch to address GICC_DIR >> and discuss further. > > No, let's get this right now and not keep changing the dts. > So should we add some string specific to apm/xgnene (something like apm,cortex-a15-gic) or specific to 64K GIC page size (arm,cortex-a15-gic-64Kpg) ? Also till 3.19, I am not sure if any code is accessing GICC_DIR so for now only thing which seems to be needed is a new dt string for 64K gic pages. Thanks, Pranav > Rob > >> >>> >>> I think perhaps we need a specific compatible property to indicate a >>> GIC-400 with address swizzling. While we could get away with using the >>> aliased addresses, that seems to be hard to get right and we may >>> regret not doing it in the long term. It would indicate at least it is >>> 64K page safe for example. >>> >>> Rob >> >> Thanks, >> Pranav -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-02-27 3:57 ` Pranavkumar Sawargaonkar 0 siblings, 0 replies; 44+ messages in thread From: Pranavkumar Sawargaonkar @ 2015-02-27 3:57 UTC (permalink / raw) To: linux-arm-kernel Hi Rob, On Tue, Feb 24, 2015 at 8:00 PM, Rob Herring <robherring2@gmail.com> wrote: > On Tue, Feb 24, 2015 at 12:34 AM, Pranavkumar Sawargaonkar > <psawargaonkar@apm.com> wrote: >> Hi Rob, >> >> On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring <robherring2@gmail.com> wrote: >>> On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall >>> <christoffer.dall@linaro.org> wrote: >>>> On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >>>>> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >>>>> <christoffer.dall@linaro.org> wrote: >>>>> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >>>>> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >>>>> >> <psawargaonkar@apm.com> wrote: >>>>> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>>> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>>> >> > size due to size alignment checking in vgic driver for VCPU Control and >>>>> >> > VCPU register. >>>>> >> > >>>>> >> > This patch corrects the sizes to be inline with the hardware spec. >>>>> >> >>>>> >> This does not make sense. The GIC regions are still only 4 or 8KB and >>>>> >> the h/w description should reflect that. For implementations using >>>>> >> gic-400 and the addressing decode trick, the rest of the register >>>>> >> range is also not safe to access given it is multiple mapped. Also, >>>>> >> this wastes virtual space, but I guess we don't care on 64-bit. >>>>> >> >>>>> >> KVM should be fixed to only check base address alignment. Size >>>>> >> alignment does not matter (if it does, then you need to fix all >>>>> >> register blocks). >>>>> >> >>>>> > It matters if you want to ensure that the 64K page you are assigning to >>>>> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU >>>>> > mappings, and not other random stuff that the guest is not allowed to >>>>> > touch. >>>>> >>>>> Good point. >>>>> >>>>> > How else should this be enforced? >>>>> >>>>> Rely on correct h/w design? You'll have to repeat this every time you >>>>> want to do pass-thru of a device. >>>>> >>>>> What do you do if 64K mapping is not supported? Fallback to emulation >>>>> of the CPU interface? >>>> >>>> Agree with Peter on these two points. >>>> >>>>> >>>>> Are there other DTSs that need to be fixed? >>>>> >>>> Not sure really, AMD Seattle works with 64K pages IIRC. >>> >>> Well, looks we have been inconsistent here: >>> >>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 >>> 0xe1110000 0 0x1000>, >>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >>> 0xe112f000 0 0x2000>, >>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >>> 0xe1140000 0 0x10000>, >>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >>> 0xe1160000 0 0x10000>; >>> >>> arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c010000 0 0x1000>, >>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, >>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, >>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; >>> >>> If we are going to use 64K sizes, can we have some consistency here >>> please. Which ranges really need 64KB sizes? It should only be the >>> VCPU interface. right? Why does XGene need 128K? If XGene is doing >>> address swizzling, then the CPU and VCPU base addresses are wrong. >>> Seattle is also wrong for the VCPU, but no one has noticed because we >>> don't use the DIR register IIRC. >>> >>> XGene should also add an "arm,gic-400" compatible string or something >>> XGene specific if in fact it is not GIC-400. >> >> X-Gene has gic-400 as an interrupt controller. >> Only thing is GIC pages are mapped at 64K boundary (with 64K page size) >> Hence CPU, VCPU interfaces has a size of 128K (2GIC pages) >> Regarding GICC_DIR, yes there is a problem which needs to be solved >> since the first page size is 64K. >> In XEN we already have a small fix to access GICC_DIR with 64K page >> offset instead of standard 4K. > > Right, and in order for this to work, you should use the last 4K alias > for the cpu interface(s). This is why other platforms use xxxf000 as > their cpu interface base. > > It is of course possible that xgene does not properly do the address > swizzling and therefore you have to use 64K aligned addresses. But in > that case you need a unique compatible string. > >> I remember a small discussion in this regard in past >> (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html) >> which was deferred at that time. >> Once this patch is accepted we can post RFC patch to address GICC_DIR >> and discuss further. > > No, let's get this right now and not keep changing the dts. > So should we add some string specific to apm/xgnene (something like apm,cortex-a15-gic) or specific to 64K GIC page size (arm,cortex-a15-gic-64Kpg) ? Also till 3.19, I am not sure if any code is accessing GICC_DIR so for now only thing which seems to be needed is a new dt string for 64K gic pages. Thanks, Pranav > Rob > >> >>> >>> I think perhaps we need a specific compatible property to indicate a >>> GIC-400 with address swizzling. While we could get away with using the >>> aliased addresses, that seems to be hard to get right and we may >>> regret not doing it in the long term. It would indicate at least it is >>> 64K page safe for example. >>> >>> Rob >> >> Thanks, >> Pranav ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-02-24 6:34 ` Pranavkumar Sawargaonkar @ 2015-03-19 18:54 ` Marc Zyngier -1 siblings, 0 replies; 44+ messages in thread From: Marc Zyngier @ 2015-03-19 18:54 UTC (permalink / raw) To: Pranavkumar Sawargaonkar, Rob Herring Cc: Christoffer Dall, devicetree-u79uwXL29TY76Z2rM5mHXA, Feng Kan, Arnd Bergmann, jcm-H+wXaHxf7aLQT0dZR+AlfA, patches-qTEPVZfXA3Y, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, Tushar Jagad, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Will Deacon On 24/02/15 06:34, Pranavkumar Sawargaonkar wrote: > Hi Rob, > > On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall >> <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>> On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >>>> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >>>> <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>>>> On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >>>>>> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >>>>>> <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> wrote: >>>>>>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>>>>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>>>>> size due to size alignment checking in vgic driver for VCPU Control and >>>>>>> VCPU register. >>>>>>> >>>>>>> This patch corrects the sizes to be inline with the hardware spec. >>>>>> >>>>>> This does not make sense. The GIC regions are still only 4 or 8KB and >>>>>> the h/w description should reflect that. For implementations using >>>>>> gic-400 and the addressing decode trick, the rest of the register >>>>>> range is also not safe to access given it is multiple mapped. Also, >>>>>> this wastes virtual space, but I guess we don't care on 64-bit. >>>>>> >>>>>> KVM should be fixed to only check base address alignment. Size >>>>>> alignment does not matter (if it does, then you need to fix all >>>>>> register blocks). >>>>>> >>>>> It matters if you want to ensure that the 64K page you are assigning to >>>>> a guest for the GIC virtual CPU interface contains only GIC virtual CPU >>>>> mappings, and not other random stuff that the guest is not allowed to >>>>> touch. >>>> >>>> Good point. >>>> >>>>> How else should this be enforced? >>>> >>>> Rely on correct h/w design? You'll have to repeat this every time you >>>> want to do pass-thru of a device. >>>> >>>> What do you do if 64K mapping is not supported? Fallback to emulation >>>> of the CPU interface? >>> >>> Agree with Peter on these two points. >>> >>>> >>>> Are there other DTSs that need to be fixed? >>>> >>> Not sure really, AMD Seattle works with 64K pages IIRC. >> >> Well, looks we have been inconsistent here: >> >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 >> 0xe1110000 0 0x1000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe112f000 0 0x2000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe1140000 0 0x10000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe1160000 0 0x10000>; >> >> arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c010000 0 0x1000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; >> >> If we are going to use 64K sizes, can we have some consistency here >> please. Which ranges really need 64KB sizes? It should only be the >> VCPU interface. right? Why does XGene need 128K? If XGene is doing >> address swizzling, then the CPU and VCPU base addresses are wrong. >> Seattle is also wrong for the VCPU, but no one has noticed because we >> don't use the DIR register IIRC. >> >> XGene should also add an "arm,gic-400" compatible string or something >> XGene specific if in fact it is not GIC-400. > > X-Gene has gic-400 as an interrupt controller. > Only thing is GIC pages are mapped at 64K boundary (with 64K page size) > Hence CPU, VCPU interfaces has a size of 128K (2GIC pages) > Regarding GICC_DIR, yes there is a problem which needs to be solved > since the first page size is 64K. > In XEN we already have a small fix to access GICC_DIR with 64K page > offset instead of standard 4K. > I remember a small discussion in this regard in past > (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html) > which was deferred at that time. > Once this patch is accepted we can post RFC patch to address GICC_DIR > and discuss further. I've had a look at my X-Gene board, and noticed the following thing: Mustang# md.l 0x78020000 0x10 78020000: 000001e7 00000080 00000002 000003ff ................ 78020010: 00000000 000000ff 000003ff 00000003 ................ 78020020: 000003ff 00000000 000003ff 00000000 ................ 78020030: 00000000 00000000 00000000 00000000 ................ Mustang# md.l 0x7802f000 0x10 7802f000: 000001e7 00000080 00000002 000003ff ................ 7802f010: 00000000 000000ff 000003ff 00000003 ................ 7802f020: 000003ff 00000000 000003ff 00000000 ................ 7802f030: 00000000 00000000 00000000 00000000 ................ Notice a pattern? Yes, X-Gene is aliasing the GICC region over the 64k page, repeated 16 times, as it should. So either the DT is fixed to show GICC and GICV at offset 0xf000 (and we don't support 64k pages with it), or we extend the binding to present an offset inside the 128K region. My preference goes of course to the latter, because for once we seem to have something designed as expected. Rob, what do you think? M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-03-19 18:54 ` Marc Zyngier 0 siblings, 0 replies; 44+ messages in thread From: Marc Zyngier @ 2015-03-19 18:54 UTC (permalink / raw) To: linux-arm-kernel On 24/02/15 06:34, Pranavkumar Sawargaonkar wrote: > Hi Rob, > > On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring <robherring2@gmail.com> wrote: >> On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall >> <christoffer.dall@linaro.org> wrote: >>> On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >>>> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >>>> <christoffer.dall@linaro.org> wrote: >>>>> On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >>>>>> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >>>>>> <psawargaonkar@apm.com> wrote: >>>>>>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>>>>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>>>>> size due to size alignment checking in vgic driver for VCPU Control and >>>>>>> VCPU register. >>>>>>> >>>>>>> This patch corrects the sizes to be inline with the hardware spec. >>>>>> >>>>>> This does not make sense. The GIC regions are still only 4 or 8KB and >>>>>> the h/w description should reflect that. For implementations using >>>>>> gic-400 and the addressing decode trick, the rest of the register >>>>>> range is also not safe to access given it is multiple mapped. Also, >>>>>> this wastes virtual space, but I guess we don't care on 64-bit. >>>>>> >>>>>> KVM should be fixed to only check base address alignment. Size >>>>>> alignment does not matter (if it does, then you need to fix all >>>>>> register blocks). >>>>>> >>>>> It matters if you want to ensure that the 64K page you are assigning to >>>>> a guest for the GIC virtual CPU interface contains only GIC virtual CPU >>>>> mappings, and not other random stuff that the guest is not allowed to >>>>> touch. >>>> >>>> Good point. >>>> >>>>> How else should this be enforced? >>>> >>>> Rely on correct h/w design? You'll have to repeat this every time you >>>> want to do pass-thru of a device. >>>> >>>> What do you do if 64K mapping is not supported? Fallback to emulation >>>> of the CPU interface? >>> >>> Agree with Peter on these two points. >>> >>>> >>>> Are there other DTSs that need to be fixed? >>>> >>> Not sure really, AMD Seattle works with 64K pages IIRC. >> >> Well, looks we have been inconsistent here: >> >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 >> 0xe1110000 0 0x1000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe112f000 0 0x2000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe1140000 0 0x10000>, >> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 >> 0xe1160000 0 0x10000>; >> >> arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c010000 0 0x1000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, >> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; >> >> If we are going to use 64K sizes, can we have some consistency here >> please. Which ranges really need 64KB sizes? It should only be the >> VCPU interface. right? Why does XGene need 128K? If XGene is doing >> address swizzling, then the CPU and VCPU base addresses are wrong. >> Seattle is also wrong for the VCPU, but no one has noticed because we >> don't use the DIR register IIRC. >> >> XGene should also add an "arm,gic-400" compatible string or something >> XGene specific if in fact it is not GIC-400. > > X-Gene has gic-400 as an interrupt controller. > Only thing is GIC pages are mapped at 64K boundary (with 64K page size) > Hence CPU, VCPU interfaces has a size of 128K (2GIC pages) > Regarding GICC_DIR, yes there is a problem which needs to be solved > since the first page size is 64K. > In XEN we already have a small fix to access GICC_DIR with 64K page > offset instead of standard 4K. > I remember a small discussion in this regard in past > (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html) > which was deferred at that time. > Once this patch is accepted we can post RFC patch to address GICC_DIR > and discuss further. I've had a look at my X-Gene board, and noticed the following thing: Mustang# md.l 0x78020000 0x10 78020000: 000001e7 00000080 00000002 000003ff ................ 78020010: 00000000 000000ff 000003ff 00000003 ................ 78020020: 000003ff 00000000 000003ff 00000000 ................ 78020030: 00000000 00000000 00000000 00000000 ................ Mustang# md.l 0x7802f000 0x10 7802f000: 000001e7 00000080 00000002 000003ff ................ 7802f010: 00000000 000000ff 000003ff 00000003 ................ 7802f020: 000003ff 00000000 000003ff 00000000 ................ 7802f030: 00000000 00000000 00000000 00000000 ................ Notice a pattern? Yes, X-Gene is aliasing the GICC region over the 64k page, repeated 16 times, as it should. So either the DT is fixed to show GICC and GICV at offset 0xf000 (and we don't support 64k pages with it), or we extend the binding to present an offset inside the 128K region. My preference goes of course to the latter, because for once we seem to have something designed as expected. Rob, what do you think? M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-01-27 7:03 ` Pranavkumar Sawargaonkar @ 2015-03-11 14:53 ` Marc Zyngier -1 siblings, 0 replies; 44+ messages in thread From: Marc Zyngier @ 2015-03-11 14:53 UTC (permalink / raw) To: Pranavkumar Sawargaonkar, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: patches-qTEPVZfXA3Y, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, arnd-r2nGTMty4D4, christoffer.dall-QSEj5FYQhm4dnm+yROfE0A, jcm-H+wXaHxf7aLQT0dZR+AlfA, Tushar Jagad, Feng Kan On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > size due to size alignment checking in vgic driver for VCPU Control and > VCPU register. > > This patch corrects the sizes to be inline with the hardware spec. This patch may be correct, but it is useless. The firmware on my APM system (some version of u-boot) repaints the DT at boot time, negating the effect of this patch. Another system I can remove from my 64k-capable list. M. > CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > CC: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org > CC: arnd-r2nGTMty4D4@public.gmane.org > CC: marc.zyngier-5wv7dgnIgG8@public.gmane.org > CC: christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org > CC: jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org > Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> > Signed-off-by: Tushar Jagad <tjagad-qTEPVZfXA3Y@public.gmane.org> > Signed-off-by: Feng Kan <fkan-qTEPVZfXA3Y@public.gmane.org> > --- > arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi > index f1ad9c2..65f0e6d 100644 > --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi > +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi > @@ -81,10 +81,10 @@ > compatible = "arm,cortex-a15-gic"; > #interrupt-cells = <3>; > interrupt-controller; > - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ > - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ > - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ > - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ > + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ > + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ > + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ > + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ > interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ > }; > > -- > 1.7.9.5 > > -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-03-11 14:53 ` Marc Zyngier 0 siblings, 0 replies; 44+ messages in thread From: Marc Zyngier @ 2015-03-11 14:53 UTC (permalink / raw) To: linux-arm-kernel On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: > In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page > size due to size alignment checking in vgic driver for VCPU Control and > VCPU register. > > This patch corrects the sizes to be inline with the hardware spec. This patch may be correct, but it is useless. The firmware on my APM system (some version of u-boot) repaints the DT at boot time, negating the effect of this patch. Another system I can remove from my 64k-capable list. M. > CC: linux-arm-kernel at lists.infradead.org > CC: kvmarm at lists.cs.columbia.edu > CC: arnd at arndb.de > CC: marc.zyngier at arm.com > CC: christoffer.dall at linaro.org > CC: jcm at redhat.com > Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> > Signed-off-by: Tushar Jagad <tjagad@apm.com> > Signed-off-by: Feng Kan <fkan@apm.com> > --- > arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi > index f1ad9c2..65f0e6d 100644 > --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi > +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi > @@ -81,10 +81,10 @@ > compatible = "arm,cortex-a15-gic"; > #interrupt-cells = <3>; > interrupt-controller; > - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ > - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ > - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ > - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ > + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ > + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ > + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ > + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ > interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ > }; > > -- > 1.7.9.5 > > -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <550056FD.8060804-5wv7dgnIgG8@public.gmane.org>]
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-03-11 14:53 ` Marc Zyngier @ 2015-03-11 17:19 ` Feng Kan -1 siblings, 0 replies; 44+ messages in thread From: Feng Kan @ 2015-03-11 17:19 UTC (permalink / raw) To: Marc Zyngier Cc: Pranavkumar Sawargaonkar, devicetree-u79uwXL29TY76Z2rM5mHXA, patches-qTEPVZfXA3Y, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, arnd-r2nGTMty4D4, christoffer.dall-QSEj5FYQhm4dnm+yROfE0A, jcm-H+wXaHxf7aLQT0dZR+AlfA, Tushar Jagad On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: > On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >> size due to size alignment checking in vgic driver for VCPU Control and >> VCPU register. >> >> This patch corrects the sizes to be inline with the hardware spec. > > This patch may be correct, but it is useless. The firmware on my APM > system (some version of u-boot) repaints the DT at boot time, negating > the effect of this patch. We have updated u-boot to reflect this change. I can supply you with a updated image if you wish. > > Another system I can remove from my 64k-capable list. > > M. > >> CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org >> CC: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org >> CC: arnd-r2nGTMty4D4@public.gmane.org >> CC: marc.zyngier-5wv7dgnIgG8@public.gmane.org >> CC: christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org >> CC: jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org >> Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> >> Signed-off-by: Tushar Jagad <tjagad-qTEPVZfXA3Y@public.gmane.org> >> Signed-off-by: Feng Kan <fkan-qTEPVZfXA3Y@public.gmane.org> >> --- >> arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi >> index f1ad9c2..65f0e6d 100644 >> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi >> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi >> @@ -81,10 +81,10 @@ >> compatible = "arm,cortex-a15-gic"; >> #interrupt-cells = <3>; >> interrupt-controller; >> - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ >> - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ >> - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ >> - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ >> + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ >> + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ >> + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ >> + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ >> interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >> }; >> >> -- >> 1.7.9.5 >> >> > > > -- > Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-03-11 17:19 ` Feng Kan 0 siblings, 0 replies; 44+ messages in thread From: Feng Kan @ 2015-03-11 17:19 UTC (permalink / raw) To: linux-arm-kernel On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: > On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >> size due to size alignment checking in vgic driver for VCPU Control and >> VCPU register. >> >> This patch corrects the sizes to be inline with the hardware spec. > > This patch may be correct, but it is useless. The firmware on my APM > system (some version of u-boot) repaints the DT at boot time, negating > the effect of this patch. We have updated u-boot to reflect this change. I can supply you with a updated image if you wish. > > Another system I can remove from my 64k-capable list. > > M. > >> CC: linux-arm-kernel at lists.infradead.org >> CC: kvmarm at lists.cs.columbia.edu >> CC: arnd at arndb.de >> CC: marc.zyngier at arm.com >> CC: christoffer.dall at linaro.org >> CC: jcm at redhat.com >> Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> >> Signed-off-by: Tushar Jagad <tjagad@apm.com> >> Signed-off-by: Feng Kan <fkan@apm.com> >> --- >> arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi >> index f1ad9c2..65f0e6d 100644 >> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi >> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi >> @@ -81,10 +81,10 @@ >> compatible = "arm,cortex-a15-gic"; >> #interrupt-cells = <3>; >> interrupt-controller; >> - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ >> - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ >> - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ >> - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ >> + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ >> + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ >> + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ >> + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ >> interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >> }; >> >> -- >> 1.7.9.5 >> >> > > > -- > Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <CAL85gmCuB4LfNp+6B8cL9+emFqWPM6W9gevTzibyaAzL+7jVdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-03-11 17:19 ` Feng Kan @ 2015-03-11 17:31 ` Marc Zyngier -1 siblings, 0 replies; 44+ messages in thread From: Marc Zyngier @ 2015-03-11 17:31 UTC (permalink / raw) To: Feng Kan Cc: Pranavkumar Sawargaonkar, devicetree-u79uwXL29TY76Z2rM5mHXA, patches-qTEPVZfXA3Y, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, arnd-r2nGTMty4D4, christoffer.dall-QSEj5FYQhm4dnm+yROfE0A, jcm-H+wXaHxf7aLQT0dZR+AlfA, Tushar Jagad On 11/03/15 17:19, Feng Kan wrote: > On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: >> On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>> size due to size alignment checking in vgic driver for VCPU Control and >>> VCPU register. >>> >>> This patch corrects the sizes to be inline with the hardware spec. >> >> This patch may be correct, but it is useless. The firmware on my APM >> system (some version of u-boot) repaints the DT at boot time, negating >> the effect of this patch. > We have updated u-boot to reflect this change. I can supply you with a updated > image if you wish. That would be useful, thanks. But more importantly, why bother upstreaming your DT into the kernel tree if your firmware is going to overwrite whatever we provide? Either the firmware let the user provide its own DT (and doesn't touch it other than to change the CPU enable method, insert a /memreserve/ or similar things), or the firmware always provide its own DT, and doesn't let the user provide its own. Corrupting the user DT is a disaster, as we just found. Thanks, M. >> >> Another system I can remove from my 64k-capable list. >> >> M. >> >>> CC: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org >>> CC: kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org >>> CC: arnd-r2nGTMty4D4@public.gmane.org >>> CC: marc.zyngier-5wv7dgnIgG8@public.gmane.org >>> CC: christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org >>> CC: jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org >>> Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar-qTEPVZfXA3Y@public.gmane.org> >>> Signed-off-by: Tushar Jagad <tjagad-qTEPVZfXA3Y@public.gmane.org> >>> Signed-off-by: Feng Kan <fkan-qTEPVZfXA3Y@public.gmane.org> >>> --- >>> arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- >>> 1 file changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi >>> index f1ad9c2..65f0e6d 100644 >>> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi >>> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi >>> @@ -81,10 +81,10 @@ >>> compatible = "arm,cortex-a15-gic"; >>> #interrupt-cells = <3>; >>> interrupt-controller; >>> - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ >>> - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ >>> - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ >>> - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ >>> + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ >>> + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ >>> + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ >>> + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ >>> interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >>> }; >>> >>> -- >>> 1.7.9.5 >>> >>> >> >> >> -- >> Jazz is not dead. It just smells funny... > -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-03-11 17:31 ` Marc Zyngier 0 siblings, 0 replies; 44+ messages in thread From: Marc Zyngier @ 2015-03-11 17:31 UTC (permalink / raw) To: linux-arm-kernel On 11/03/15 17:19, Feng Kan wrote: > On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: >> On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>> size due to size alignment checking in vgic driver for VCPU Control and >>> VCPU register. >>> >>> This patch corrects the sizes to be inline with the hardware spec. >> >> This patch may be correct, but it is useless. The firmware on my APM >> system (some version of u-boot) repaints the DT at boot time, negating >> the effect of this patch. > We have updated u-boot to reflect this change. I can supply you with a updated > image if you wish. That would be useful, thanks. But more importantly, why bother upstreaming your DT into the kernel tree if your firmware is going to overwrite whatever we provide? Either the firmware let the user provide its own DT (and doesn't touch it other than to change the CPU enable method, insert a /memreserve/ or similar things), or the firmware always provide its own DT, and doesn't let the user provide its own. Corrupting the user DT is a disaster, as we just found. Thanks, M. >> >> Another system I can remove from my 64k-capable list. >> >> M. >> >>> CC: linux-arm-kernel at lists.infradead.org >>> CC: kvmarm at lists.cs.columbia.edu >>> CC: arnd at arndb.de >>> CC: marc.zyngier at arm.com >>> CC: christoffer.dall at linaro.org >>> CC: jcm at redhat.com >>> Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> >>> Signed-off-by: Tushar Jagad <tjagad@apm.com> >>> Signed-off-by: Feng Kan <fkan@apm.com> >>> --- >>> arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- >>> 1 file changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi >>> index f1ad9c2..65f0e6d 100644 >>> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi >>> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi >>> @@ -81,10 +81,10 @@ >>> compatible = "arm,cortex-a15-gic"; >>> #interrupt-cells = <3>; >>> interrupt-controller; >>> - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ >>> - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ >>> - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ >>> - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ >>> + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ >>> + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ >>> + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ >>> + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ >>> interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >>> }; >>> >>> -- >>> 1.7.9.5 >>> >>> >> >> >> -- >> Jazz is not dead. It just smells funny... > -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-03-11 17:31 ` Marc Zyngier @ 2015-03-11 17:57 ` Feng Kan -1 siblings, 0 replies; 44+ messages in thread From: Feng Kan @ 2015-03-11 17:57 UTC (permalink / raw) To: Marc Zyngier Cc: devicetree, arnd, jcm, patches, kvmarm, Tushar Jagad, Pranavkumar Sawargaonkar, linux-arm-kernel On Wed, Mar 11, 2015 at 10:31 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: > On 11/03/15 17:19, Feng Kan wrote: >> On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: >>> On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >>>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>> size due to size alignment checking in vgic driver for VCPU Control and >>>> VCPU register. >>>> >>>> This patch corrects the sizes to be inline with the hardware spec. >>> >>> This patch may be correct, but it is useless. The firmware on my APM >>> system (some version of u-boot) repaints the DT at boot time, negating >>> the effect of this patch. >> We have updated u-boot to reflect this change. I can supply you with a updated >> image if you wish. > > That would be useful, thanks. > > But more importantly, why bother upstreaming your DT into the kernel > tree if your firmware is going to overwrite whatever we provide? We did tried to submit a version upstream but was rejected. > > Either the firmware let the user provide its own DT (and doesn't touch > it other than to change the CPU enable method, insert a /memreserve/ or > similar things), or the firmware always provide its own DT, and doesn't > let the user provide its own. Corrupting the user DT is a disaster, as > we just found. Yes, the intent of the change is listed in the link below. It is not a justification by any means, just the effects of things appearing in layers. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288574.html > > Thanks, > > M. > >>> >>> Another system I can remove from my 64k-capable list. >>> >>> M. >>> >>>> CC: linux-arm-kernel@lists.infradead.org >>>> CC: kvmarm@lists.cs.columbia.edu >>>> CC: arnd@arndb.de >>>> CC: marc.zyngier@arm.com >>>> CC: christoffer.dall@linaro.org >>>> CC: jcm@redhat.com >>>> Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> >>>> Signed-off-by: Tushar Jagad <tjagad@apm.com> >>>> Signed-off-by: Feng Kan <fkan@apm.com> >>>> --- >>>> arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- >>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi >>>> index f1ad9c2..65f0e6d 100644 >>>> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi >>>> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi >>>> @@ -81,10 +81,10 @@ >>>> compatible = "arm,cortex-a15-gic"; >>>> #interrupt-cells = <3>; >>>> interrupt-controller; >>>> - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ >>>> - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ >>>> - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ >>>> - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ >>>> + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ >>>> + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ >>>> + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ >>>> + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ >>>> interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >>>> }; >>>> >>>> -- >>>> 1.7.9.5 >>>> >>>> >>> >>> >>> -- >>> Jazz is not dead. It just smells funny... >> > > > -- > Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-03-11 17:57 ` Feng Kan 0 siblings, 0 replies; 44+ messages in thread From: Feng Kan @ 2015-03-11 17:57 UTC (permalink / raw) To: linux-arm-kernel On Wed, Mar 11, 2015 at 10:31 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: > On 11/03/15 17:19, Feng Kan wrote: >> On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: >>> On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >>>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>> size due to size alignment checking in vgic driver for VCPU Control and >>>> VCPU register. >>>> >>>> This patch corrects the sizes to be inline with the hardware spec. >>> >>> This patch may be correct, but it is useless. The firmware on my APM >>> system (some version of u-boot) repaints the DT at boot time, negating >>> the effect of this patch. >> We have updated u-boot to reflect this change. I can supply you with a updated >> image if you wish. > > That would be useful, thanks. > > But more importantly, why bother upstreaming your DT into the kernel > tree if your firmware is going to overwrite whatever we provide? We did tried to submit a version upstream but was rejected. > > Either the firmware let the user provide its own DT (and doesn't touch > it other than to change the CPU enable method, insert a /memreserve/ or > similar things), or the firmware always provide its own DT, and doesn't > let the user provide its own. Corrupting the user DT is a disaster, as > we just found. Yes, the intent of the change is listed in the link below. It is not a justification by any means, just the effects of things appearing in layers. http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288574.html > > Thanks, > > M. > >>> >>> Another system I can remove from my 64k-capable list. >>> >>> M. >>> >>>> CC: linux-arm-kernel at lists.infradead.org >>>> CC: kvmarm at lists.cs.columbia.edu >>>> CC: arnd at arndb.de >>>> CC: marc.zyngier at arm.com >>>> CC: christoffer.dall at linaro.org >>>> CC: jcm at redhat.com >>>> Signed-off-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com> >>>> Signed-off-by: Tushar Jagad <tjagad@apm.com> >>>> Signed-off-by: Feng Kan <fkan@apm.com> >>>> --- >>>> arch/arm64/boot/dts/apm/apm-storm.dtsi | 8 ++++---- >>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi >>>> index f1ad9c2..65f0e6d 100644 >>>> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi >>>> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi >>>> @@ -81,10 +81,10 @@ >>>> compatible = "arm,cortex-a15-gic"; >>>> #interrupt-cells = <3>; >>>> interrupt-controller; >>>> - reg = <0x0 0x78010000 0x0 0x1000>, /* GIC Dist */ >>>> - <0x0 0x78020000 0x0 0x1000>, /* GIC CPU */ >>>> - <0x0 0x78040000 0x0 0x2000>, /* GIC VCPU Control */ >>>> - <0x0 0x78060000 0x0 0x2000>; /* GIC VCPU */ >>>> + reg = <0x0 0x78010000 0x0 0x10000>, /* GIC Dist */ >>>> + <0x0 0x78020000 0x0 0x20000>, /* GIC CPU */ >>>> + <0x0 0x78040000 0x0 0x10000>, /* GIC VCPU Control */ >>>> + <0x0 0x78060000 0x0 0x20000>; /* GIC VCPU */ >>>> interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >>>> }; >>>> >>>> -- >>>> 1.7.9.5 >>>> >>>> >>> >>> >>> -- >>> Jazz is not dead. It just smells funny... >> > > > -- > Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <CAL85gmDVfop1_roHyLTRzFY3BahzTWs7nwbpmZD7emFKcFHyLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-03-11 17:57 ` Feng Kan @ 2015-03-11 18:17 ` Marc Zyngier -1 siblings, 0 replies; 44+ messages in thread From: Marc Zyngier @ 2015-03-11 18:17 UTC (permalink / raw) To: Feng Kan Cc: Pranavkumar Sawargaonkar, devicetree-u79uwXL29TY76Z2rM5mHXA, patches-qTEPVZfXA3Y, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, arnd-r2nGTMty4D4, christoffer.dall-QSEj5FYQhm4dnm+yROfE0A, jcm-H+wXaHxf7aLQT0dZR+AlfA, Tushar Jagad On 11/03/15 17:57, Feng Kan wrote: > On Wed, Mar 11, 2015 at 10:31 AM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: >> On 11/03/15 17:19, Feng Kan wrote: >>> On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: >>>> On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >>>>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>>> size due to size alignment checking in vgic driver for VCPU Control and >>>>> VCPU register. >>>>> >>>>> This patch corrects the sizes to be inline with the hardware spec. >>>> >>>> This patch may be correct, but it is useless. The firmware on my APM >>>> system (some version of u-boot) repaints the DT at boot time, negating >>>> the effect of this patch. >>> We have updated u-boot to reflect this change. I can supply you with a updated >>> image if you wish. >> >> That would be useful, thanks. >> >> But more importantly, why bother upstreaming your DT into the kernel >> tree if your firmware is going to overwrite whatever we provide? > We did tried to submit a version upstream but was rejected. > >> >> Either the firmware let the user provide its own DT (and doesn't touch >> it other than to change the CPU enable method, insert a /memreserve/ or >> similar things), or the firmware always provide its own DT, and doesn't >> let the user provide its own. Corrupting the user DT is a disaster, as >> we just found. > Yes, the intent of the change is listed in the link below. It is not a > justification by any means, > just the effects of things appearing in layers. > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288574.html Yeah. This is as wrong as it can possibly be. Oh well... Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-03-11 18:17 ` Marc Zyngier 0 siblings, 0 replies; 44+ messages in thread From: Marc Zyngier @ 2015-03-11 18:17 UTC (permalink / raw) To: linux-arm-kernel On 11/03/15 17:57, Feng Kan wrote: > On Wed, Mar 11, 2015 at 10:31 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: >> On 11/03/15 17:19, Feng Kan wrote: >>> On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: >>>> On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >>>>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>>> size due to size alignment checking in vgic driver for VCPU Control and >>>>> VCPU register. >>>>> >>>>> This patch corrects the sizes to be inline with the hardware spec. >>>> >>>> This patch may be correct, but it is useless. The firmware on my APM >>>> system (some version of u-boot) repaints the DT at boot time, negating >>>> the effect of this patch. >>> We have updated u-boot to reflect this change. I can supply you with a updated >>> image if you wish. >> >> That would be useful, thanks. >> >> But more importantly, why bother upstreaming your DT into the kernel >> tree if your firmware is going to overwrite whatever we provide? > We did tried to submit a version upstream but was rejected. > >> >> Either the firmware let the user provide its own DT (and doesn't touch >> it other than to change the CPU enable method, insert a /memreserve/ or >> similar things), or the firmware always provide its own DT, and doesn't >> let the user provide its own. Corrupting the user DT is a disaster, as >> we just found. > Yes, the intent of the change is listed in the link below. It is not a > justification by any means, > just the effects of things appearing in layers. > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288574.html Yeah. This is as wrong as it can possibly be. Oh well... Thanks, M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <550086B9.4010001-5wv7dgnIgG8@public.gmane.org>]
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-03-11 18:17 ` Marc Zyngier @ 2015-03-12 3:52 ` Pranavkumar Sawargaonkar -1 siblings, 0 replies; 44+ messages in thread From: Pranavkumar Sawargaonkar @ 2015-03-12 3:52 UTC (permalink / raw) To: Marc Zyngier Cc: Feng Kan, devicetree-u79uwXL29TY76Z2rM5mHXA, patches-qTEPVZfXA3Y, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, arnd-r2nGTMty4D4, christoffer.dall-QSEj5FYQhm4dnm+yROfE0A, jcm-H+wXaHxf7aLQT0dZR+AlfA, Tushar Jagad Hi Marc, On Wed, Mar 11, 2015 at 11:47 PM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: > On 11/03/15 17:57, Feng Kan wrote: >> On Wed, Mar 11, 2015 at 10:31 AM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: >>> On 11/03/15 17:19, Feng Kan wrote: >>>> On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: >>>>> On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >>>>>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>>>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>>>> size due to size alignment checking in vgic driver for VCPU Control and >>>>>> VCPU register. >>>>>> >>>>>> This patch corrects the sizes to be inline with the hardware spec. >>>>> >>>>> This patch may be correct, but it is useless. The firmware on my APM >>>>> system (some version of u-boot) repaints the DT at boot time, negating >>>>> the effect of this patch. >>>> We have updated u-boot to reflect this change. I can supply you with a updated >>>> image if you wish. >>> >>> That would be useful, thanks. >>> >>> But more importantly, why bother upstreaming your DT into the kernel >>> tree if your firmware is going to overwrite whatever we provide? >> We did tried to submit a version upstream but was rejected. >> >>> >>> Either the firmware let the user provide its own DT (and doesn't touch >>> it other than to change the CPU enable method, insert a /memreserve/ or >>> similar things), or the firmware always provide its own DT, and doesn't >>> let the user provide its own. Corrupting the user DT is a disaster, as >>> we just found. >> Yes, the intent of the change is listed in the link below. It is not a >> justification by any means, >> just the effects of things appearing in layers. >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288574.html > > Yeah. This is as wrong as it can possibly be. Oh well... Yes there is an issue with u-boot patching the dt for end user who wants his DT to be used, for this we can (in fact we should) provide an option in u-boot (may be setting some environment variable) which will make sure end user's DT does not get modified (apart from standard things like patching mac-addresses) by u-boot. Another point I want to reopen here is the how to handle 64K GIC page size pointed out in this thread, what would be the best way to tackle this (adding a new DT string or any other way) ? Thanks, Pranav > > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-03-12 3:52 ` Pranavkumar Sawargaonkar 0 siblings, 0 replies; 44+ messages in thread From: Pranavkumar Sawargaonkar @ 2015-03-12 3:52 UTC (permalink / raw) To: linux-arm-kernel Hi Marc, On Wed, Mar 11, 2015 at 11:47 PM, Marc Zyngier <marc.zyngier@arm.com> wrote: > On 11/03/15 17:57, Feng Kan wrote: >> On Wed, Mar 11, 2015 at 10:31 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: >>> On 11/03/15 17:19, Feng Kan wrote: >>>> On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: >>>>> On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >>>>>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>>>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>>>> size due to size alignment checking in vgic driver for VCPU Control and >>>>>> VCPU register. >>>>>> >>>>>> This patch corrects the sizes to be inline with the hardware spec. >>>>> >>>>> This patch may be correct, but it is useless. The firmware on my APM >>>>> system (some version of u-boot) repaints the DT at boot time, negating >>>>> the effect of this patch. >>>> We have updated u-boot to reflect this change. I can supply you with a updated >>>> image if you wish. >>> >>> That would be useful, thanks. >>> >>> But more importantly, why bother upstreaming your DT into the kernel >>> tree if your firmware is going to overwrite whatever we provide? >> We did tried to submit a version upstream but was rejected. >> >>> >>> Either the firmware let the user provide its own DT (and doesn't touch >>> it other than to change the CPU enable method, insert a /memreserve/ or >>> similar things), or the firmware always provide its own DT, and doesn't >>> let the user provide its own. Corrupting the user DT is a disaster, as >>> we just found. >> Yes, the intent of the change is listed in the link below. It is not a >> justification by any means, >> just the effects of things appearing in layers. >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288574.html > > Yeah. This is as wrong as it can possibly be. Oh well... Yes there is an issue with u-boot patching the dt for end user who wants his DT to be used, for this we can (in fact we should) provide an option in u-boot (may be setting some environment variable) which will make sure end user's DT does not get modified (apart from standard things like patching mac-addresses) by u-boot. Another point I want to reopen here is the how to handle 64K GIC page size pointed out in this thread, what would be the best way to tackle this (adding a new DT string or any other way) ? Thanks, Pranav > > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <CANFfpkQ1QyWEGwwQx1g1By=uXvctJjF8AOO+uA5CFUgO4v9DFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene 2015-03-12 3:52 ` Pranavkumar Sawargaonkar @ 2015-03-12 9:25 ` Marc Zyngier -1 siblings, 0 replies; 44+ messages in thread From: Marc Zyngier @ 2015-03-12 9:25 UTC (permalink / raw) To: Pranavkumar Sawargaonkar Cc: Feng Kan, devicetree-u79uwXL29TY76Z2rM5mHXA, patches-qTEPVZfXA3Y, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg, arnd-r2nGTMty4D4, christoffer.dall-QSEj5FYQhm4dnm+yROfE0A, jcm-H+wXaHxf7aLQT0dZR+AlfA, Tushar Jagad, Rob Herring [adding RobH to the CC list, as he was commenting on the subject earlier] Hi Pranav, On 12/03/15 03:52, Pranavkumar Sawargaonkar wrote: > Hi Marc, > > On Wed, Mar 11, 2015 at 11:47 PM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: >> On 11/03/15 17:57, Feng Kan wrote: >>> On Wed, Mar 11, 2015 at 10:31 AM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: >>>> On 11/03/15 17:19, Feng Kan wrote: >>>>> On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote: >>>>>> On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >>>>>>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>>>>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>>>>> size due to size alignment checking in vgic driver for VCPU Control and >>>>>>> VCPU register. >>>>>>> >>>>>>> This patch corrects the sizes to be inline with the hardware spec. >>>>>> >>>>>> This patch may be correct, but it is useless. The firmware on my APM >>>>>> system (some version of u-boot) repaints the DT at boot time, negating >>>>>> the effect of this patch. >>>>> We have updated u-boot to reflect this change. I can supply you with a updated >>>>> image if you wish. >>>> >>>> That would be useful, thanks. >>>> >>>> But more importantly, why bother upstreaming your DT into the kernel >>>> tree if your firmware is going to overwrite whatever we provide? >>> We did tried to submit a version upstream but was rejected. >>> >>>> >>>> Either the firmware let the user provide its own DT (and doesn't touch >>>> it other than to change the CPU enable method, insert a /memreserve/ or >>>> similar things), or the firmware always provide its own DT, and doesn't >>>> let the user provide its own. Corrupting the user DT is a disaster, as >>>> we just found. >>> Yes, the intent of the change is listed in the link below. It is not a >>> justification by any means, >>> just the effects of things appearing in layers. >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288574.html >> >> Yeah. This is as wrong as it can possibly be. Oh well... > > Yes there is an issue with u-boot patching the dt for end user who > wants his DT to be used, for this we can (in fact we should) provide > an option in u-boot (may be setting some environment variable) which > will make sure end user's DT does not get modified (apart from > standard things like patching mac-addresses) by u-boot. Definitely. I would even argue that not overwriting the DT should be the default behaviour, and that you could have a compatibility mode that repaint ancient DTs if you want to. But at least having something would be good. At the moment, my X-Gene board is screwed, as I don't have any way to fix the bootloader (or even to download a binary). > Another point I want to reopen here is the how to handle 64K GIC page > size pointed out in this thread, what would be the best way to tackle > this (adding a new DT string or any other way) ? The main problem is that there is several flavours of brokenness: - GICC_CTLR@0, GICC_DIR@0x10000, size 128kB (X-Gene) - GICC_CTLR@0, GICC_DIR@0x1000, size 64kB (Seattle) - GICC_CTL@0xF000, GICC_DIR@0x10000, size 8kB (Juno) - GICC_CTL@0, GICC_DIR@0x1000, size 8kB (HiKey) Yes, they all have a GIC400, and yet they are all irritatingly non compliant with SBSA. As far as I can tell, nobody has correctly implemented the expected aliasing that would have made it work. So either we add new compatibility strings describing all the possible way people can break things, or we introduce something like dir-offset and ctlr-offset that would tell the driver where the two sub-regions are placed. The default values would be: - When size is < 8kB -> invalid configuration, this is not a GIC400. - When size is = 8kB -> ctlr-offset = 0, dir-offset = 0x1000 - When size is = 128kB -> ctlr-offset = 0xf000, dir-offset = 0x10000 For the two first braindead systems above: - ctlr-offset = 0, dir-offset = 0x10000 (X-Gene) - ctlr-offset = 0, dir-offset = 0x1000; (Seattle) and that's just enough to get bare metal going. When it comes to virtualization, this is hell: - We need an API to be able to expose these various offsets to userspace, so that QEMU/kvmtool can place the GICV region at the right location (offset within a page). - We will also miss the capability to trap GICV_DIR independently from the rest of the VCPU interface on systems like Seattle, which is rather bad. - Systems that look like Juno or HiKey cannot use virtualization with 64k pages, end of story. After writing this, I'm feeling slightly depressed... M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene @ 2015-03-12 9:25 ` Marc Zyngier 0 siblings, 0 replies; 44+ messages in thread From: Marc Zyngier @ 2015-03-12 9:25 UTC (permalink / raw) To: linux-arm-kernel [adding RobH to the CC list, as he was commenting on the subject earlier] Hi Pranav, On 12/03/15 03:52, Pranavkumar Sawargaonkar wrote: > Hi Marc, > > On Wed, Mar 11, 2015 at 11:47 PM, Marc Zyngier <marc.zyngier@arm.com> wrote: >> On 11/03/15 17:57, Feng Kan wrote: >>> On Wed, Mar 11, 2015 at 10:31 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: >>>> On 11/03/15 17:19, Feng Kan wrote: >>>>> On Wed, Mar 11, 2015 at 7:53 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: >>>>>> On 27/01/15 07:03, Pranavkumar Sawargaonkar wrote: >>>>>>> In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned >>>>>>> in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page >>>>>>> size due to size alignment checking in vgic driver for VCPU Control and >>>>>>> VCPU register. >>>>>>> >>>>>>> This patch corrects the sizes to be inline with the hardware spec. >>>>>> >>>>>> This patch may be correct, but it is useless. The firmware on my APM >>>>>> system (some version of u-boot) repaints the DT at boot time, negating >>>>>> the effect of this patch. >>>>> We have updated u-boot to reflect this change. I can supply you with a updated >>>>> image if you wish. >>>> >>>> That would be useful, thanks. >>>> >>>> But more importantly, why bother upstreaming your DT into the kernel >>>> tree if your firmware is going to overwrite whatever we provide? >>> We did tried to submit a version upstream but was rejected. >>> >>>> >>>> Either the firmware let the user provide its own DT (and doesn't touch >>>> it other than to change the CPU enable method, insert a /memreserve/ or >>>> similar things), or the firmware always provide its own DT, and doesn't >>>> let the user provide its own. Corrupting the user DT is a disaster, as >>>> we just found. >>> Yes, the intent of the change is listed in the link below. It is not a >>> justification by any means, >>> just the effects of things appearing in layers. >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288574.html >> >> Yeah. This is as wrong as it can possibly be. Oh well... > > Yes there is an issue with u-boot patching the dt for end user who > wants his DT to be used, for this we can (in fact we should) provide > an option in u-boot (may be setting some environment variable) which > will make sure end user's DT does not get modified (apart from > standard things like patching mac-addresses) by u-boot. Definitely. I would even argue that not overwriting the DT should be the default behaviour, and that you could have a compatibility mode that repaint ancient DTs if you want to. But at least having something would be good. At the moment, my X-Gene board is screwed, as I don't have any way to fix the bootloader (or even to download a binary). > Another point I want to reopen here is the how to handle 64K GIC page > size pointed out in this thread, what would be the best way to tackle > this (adding a new DT string or any other way) ? The main problem is that there is several flavours of brokenness: - GICC_CTLR at 0, GICC_DIR at 0x10000, size 128kB (X-Gene) - GICC_CTLR at 0, GICC_DIR at 0x1000, size 64kB (Seattle) - GICC_CTL at 0xF000, GICC_DIR at 0x10000, size 8kB (Juno) - GICC_CTL at 0, GICC_DIR at 0x1000, size 8kB (HiKey) Yes, they all have a GIC400, and yet they are all irritatingly non compliant with SBSA. As far as I can tell, nobody has correctly implemented the expected aliasing that would have made it work. So either we add new compatibility strings describing all the possible way people can break things, or we introduce something like dir-offset and ctlr-offset that would tell the driver where the two sub-regions are placed. The default values would be: - When size is < 8kB -> invalid configuration, this is not a GIC400. - When size is = 8kB -> ctlr-offset = 0, dir-offset = 0x1000 - When size is = 128kB -> ctlr-offset = 0xf000, dir-offset = 0x10000 For the two first braindead systems above: - ctlr-offset = 0, dir-offset = 0x10000 (X-Gene) - ctlr-offset = 0, dir-offset = 0x1000; (Seattle) and that's just enough to get bare metal going. When it comes to virtualization, this is hell: - We need an API to be able to expose these various offsets to userspace, so that QEMU/kvmtool can place the GICV region at the right location (offset within a page). - We will also miss the capability to trap GICV_DIR independently from the rest of the VCPU interface on systems like Seattle, which is rather bad. - Systems that look like Juno or HiKey cannot use virtualization with 64k pages, end of story. After writing this, I'm feeling slightly depressed... M. -- Jazz is not dead. It just smells funny... ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2015-03-19 18:54 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-27 7:03 [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene Pranavkumar Sawargaonkar 2015-01-27 7:03 ` Pranavkumar Sawargaonkar 2015-02-19 15:51 ` Christoffer Dall 2015-02-19 15:51 ` Christoffer Dall [not found] ` <1422342206-4750-1-git-send-email-psawargaonkar-qTEPVZfXA3Y@public.gmane.org> 2015-01-27 9:32 ` Jon Masters 2015-01-27 9:32 ` Jon Masters 2015-02-11 4:09 ` Pranavkumar Sawargaonkar 2015-02-11 4:09 ` Pranavkumar Sawargaonkar 2015-02-19 18:23 ` Rob Herring 2015-02-19 18:23 ` Rob Herring [not found] ` <CAL_JsqJQcuX2cp50oHod-QAbhdMg48TaRP+gLGEO2kbFnQ3B+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-02-19 19:03 ` Christoffer Dall 2015-02-19 19:03 ` Christoffer Dall 2015-02-21 21:56 ` Rob Herring 2015-02-21 21:56 ` Rob Herring [not found] ` <CAL_JsqLcBOC+AnVe7oATjg2g6Fz2vqwacu8QzS4tXMaxxOP_Xg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-02-21 23:58 ` Peter Maydell 2015-02-21 23:58 ` Peter Maydell 2015-02-23 12:07 ` Christoffer Dall 2015-02-23 12:07 ` Christoffer Dall 2015-02-23 12:24 ` Jon Masters 2015-02-23 12:24 ` Jon Masters 2015-02-23 16:39 ` Rob Herring 2015-02-23 16:39 ` Rob Herring 2015-02-24 6:34 ` Pranavkumar Sawargaonkar 2015-02-24 6:34 ` Pranavkumar Sawargaonkar [not found] ` <CANFfpkQF-8Kzq-UoP=xLpkTafGn6ScyiEb6oCs-Lxygb+ummLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-02-24 14:30 ` Rob Herring 2015-02-24 14:30 ` Rob Herring [not found] ` <CAL_JsqLs4HdT6N=Vb4s--x3ugXKbWYQ5R2WGbiWFhhnYxnK-xw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-02-27 3:57 ` Pranavkumar Sawargaonkar 2015-02-27 3:57 ` Pranavkumar Sawargaonkar 2015-03-19 18:54 ` Marc Zyngier 2015-03-19 18:54 ` Marc Zyngier 2015-03-11 14:53 ` Marc Zyngier 2015-03-11 14:53 ` Marc Zyngier [not found] ` <550056FD.8060804-5wv7dgnIgG8@public.gmane.org> 2015-03-11 17:19 ` Feng Kan 2015-03-11 17:19 ` Feng Kan [not found] ` <CAL85gmCuB4LfNp+6B8cL9+emFqWPM6W9gevTzibyaAzL+7jVdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-03-11 17:31 ` Marc Zyngier 2015-03-11 17:31 ` Marc Zyngier 2015-03-11 17:57 ` Feng Kan 2015-03-11 17:57 ` Feng Kan [not found] ` <CAL85gmDVfop1_roHyLTRzFY3BahzTWs7nwbpmZD7emFKcFHyLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-03-11 18:17 ` Marc Zyngier 2015-03-11 18:17 ` Marc Zyngier [not found] ` <550086B9.4010001-5wv7dgnIgG8@public.gmane.org> 2015-03-12 3:52 ` Pranavkumar Sawargaonkar 2015-03-12 3:52 ` Pranavkumar Sawargaonkar [not found] ` <CANFfpkQ1QyWEGwwQx1g1By=uXvctJjF8AOO+uA5CFUgO4v9DFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-03-12 9:25 ` Marc Zyngier 2015-03-12 9:25 ` Marc Zyngier
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.