| Message ID | alpine.DEB.2.10.1710171708130.27209@sstabellini-ThinkPad-X260 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 18 October 2017 at 01:10, Stefano Stabellini <sstabellini@kernel.org> wrote: > Advertise the presence of the GIC system register interface (1<<24) > according to H9.248 of the ARM ARM. > > This patch allows Xen to boot on QEMU aarch64. > > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> > > diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c > index 670c07a..a451763 100644 > --- a/target/arm/cpu64.c > +++ b/target/arm/cpu64.c > @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj) > cpu->id_isar3 = 0x01112131; > cpu->id_isar4 = 0x00011142; > cpu->id_isar5 = 0x00011121; > - cpu->id_aa64pfr0 = 0x00002222; > + cpu->id_aa64pfr0 = 0x01002222; > cpu->id_aa64dfr0 = 0x10305106; > cpu->pmceid0 = 0x00000000; > cpu->pmceid1 = 0x00000000; > @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj) > cpu->id_isar3 = 0x01112131; > cpu->id_isar4 = 0x00011142; > cpu->id_isar5 = 0x00011121; > - cpu->id_aa64pfr0 = 0x00002222; > + cpu->id_aa64pfr0 = 0x01002222; > cpu->id_aa64dfr0 = 0x10305106; > cpu->id_aa64isar0 = 0x00011120; > cpu->id_aa64mmfr0 = 0x00001122; /* 40 bit physical addr */ Whoops -- we missed this when we added the GICv3 support, because Linux doesn't check it. Applied to target-arm.next, thanks. -- PMM
On 19 October 2017 at 15:46, Peter Maydell <peter.maydell@linaro.org> wrote: > On 18 October 2017 at 01:10, Stefano Stabellini <sstabellini@kernel.org> wrote: >> Advertise the presence of the GIC system register interface (1<<24) >> according to H9.248 of the ARM ARM. >> >> This patch allows Xen to boot on QEMU aarch64. >> >> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> >> >> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c >> index 670c07a..a451763 100644 >> --- a/target/arm/cpu64.c >> +++ b/target/arm/cpu64.c >> @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj) >> cpu->id_isar3 = 0x01112131; >> cpu->id_isar4 = 0x00011142; >> cpu->id_isar5 = 0x00011121; >> - cpu->id_aa64pfr0 = 0x00002222; >> + cpu->id_aa64pfr0 = 0x01002222; >> cpu->id_aa64dfr0 = 0x10305106; >> cpu->pmceid0 = 0x00000000; >> cpu->pmceid1 = 0x00000000; >> @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj) >> cpu->id_isar3 = 0x01112131; >> cpu->id_isar4 = 0x00011142; >> cpu->id_isar5 = 0x00011121; >> - cpu->id_aa64pfr0 = 0x00002222; >> + cpu->id_aa64pfr0 = 0x01002222; >> cpu->id_aa64dfr0 = 0x10305106; >> cpu->id_aa64isar0 = 0x00011120; >> cpu->id_aa64mmfr0 = 0x00001122; /* 40 bit physical addr */ > > Whoops -- we missed this when we added the GICv3 support, because > Linux doesn't check it. > > Applied to target-arm.next, thanks. Unfortunately I've just noticed that this breaks booting Linux in the "not using gicv3" case. This is because we don't actually define the GICv3 cpu interface registers unless the board instantiates a GICv3. We mustn't advertise the GICv3 sysregs in the ID register unless we actually have them. Not sure how best to fix this -- it's a consequence of the design decision we made to have the sysregs implementation be in the gicv3 code. There's no useful feature bit in the CPU to hang this off either, it's an effect of whether the board model happens to wire up a gicv3 or not. So we can only figure this out fairly late on (probably at CPU reset time), which is a bit tedious for getting ID reg values right. In the meantime I've dropped this patch from target-arm.next. thanks -- PMM
On Tue, 31 Oct 2017, Peter Maydell wrote: > On 19 October 2017 at 15:46, Peter Maydell <peter.maydell@linaro.org> wrote: > > On 18 October 2017 at 01:10, Stefano Stabellini <sstabellini@kernel.org> wrote: > >> Advertise the presence of the GIC system register interface (1<<24) > >> according to H9.248 of the ARM ARM. > >> > >> This patch allows Xen to boot on QEMU aarch64. > >> > >> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> > >> > >> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c > >> index 670c07a..a451763 100644 > >> --- a/target/arm/cpu64.c > >> +++ b/target/arm/cpu64.c > >> @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj) > >> cpu->id_isar3 = 0x01112131; > >> cpu->id_isar4 = 0x00011142; > >> cpu->id_isar5 = 0x00011121; > >> - cpu->id_aa64pfr0 = 0x00002222; > >> + cpu->id_aa64pfr0 = 0x01002222; > >> cpu->id_aa64dfr0 = 0x10305106; > >> cpu->pmceid0 = 0x00000000; > >> cpu->pmceid1 = 0x00000000; > >> @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj) > >> cpu->id_isar3 = 0x01112131; > >> cpu->id_isar4 = 0x00011142; > >> cpu->id_isar5 = 0x00011121; > >> - cpu->id_aa64pfr0 = 0x00002222; > >> + cpu->id_aa64pfr0 = 0x01002222; > >> cpu->id_aa64dfr0 = 0x10305106; > >> cpu->id_aa64isar0 = 0x00011120; > >> cpu->id_aa64mmfr0 = 0x00001122; /* 40 bit physical addr */ > > > > Whoops -- we missed this when we added the GICv3 support, because > > Linux doesn't check it. > > > > Applied to target-arm.next, thanks. > > Unfortunately I've just noticed that this breaks booting Linux > in the "not using gicv3" case. This is because we don't actually > define the GICv3 cpu interface registers unless the board > instantiates a GICv3. We mustn't advertise the GICv3 sysregs > in the ID register unless we actually have them. > > Not sure how best to fix this -- it's a consequence of the > design decision we made to have the sysregs implementation > be in the gicv3 code. There's no useful feature bit in the CPU > to hang this off either, it's an effect of whether the board > model happens to wire up a gicv3 or not. So we can only figure > this out fairly late on (probably at CPU reset time), which > is a bit tedious for getting ID reg values right. > > In the meantime I've dropped this patch from target-arm.next. Fixing QEMU is harder than I expected. Would it be possible to update id_aa64pfr0 at CPU reset time? Like cpu->id_aa64pfr0 |= 0x01000000; ?
On 31 October 2017 at 17:01, Stefano Stabellini <sstabellini@kernel.org> wrote: > Fixing QEMU is harder than I expected. Would it be possible to update > id_aa64pfr0 at CPU reset time? Like cpu->id_aa64pfr0 |= 0x01000000; ? At that point we've already called register_cp_regs_for_features(), which is where we read cpu->id_aa64pfr0 when we're creating the cpreg. So if you change it after that it's too late. But that function is called at CPU realize time, which is before we've created the GIC object... thanks -- PMM
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c index 670c07a..a451763 100644 --- a/target/arm/cpu64.c +++ b/target/arm/cpu64.c @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj) cpu->id_isar3 = 0x01112131; cpu->id_isar4 = 0x00011142; cpu->id_isar5 = 0x00011121; - cpu->id_aa64pfr0 = 0x00002222; + cpu->id_aa64pfr0 = 0x01002222; cpu->id_aa64dfr0 = 0x10305106; cpu->pmceid0 = 0x00000000; cpu->pmceid1 = 0x00000000; @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj) cpu->id_isar3 = 0x01112131; cpu->id_isar4 = 0x00011142; cpu->id_isar5 = 0x00011121; - cpu->id_aa64pfr0 = 0x00002222; + cpu->id_aa64pfr0 = 0x01002222; cpu->id_aa64dfr0 = 0x10305106; cpu->id_aa64isar0 = 0x00011120; cpu->id_aa64mmfr0 = 0x00001122; /* 40 bit physical addr */
Advertise the presence of the GIC system register interface (1<<24) according to H9.248 of the ARM ARM. This patch allows Xen to boot on QEMU aarch64. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>