[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface
On 31 October 2017 at 18:51, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote: > On Tue, 31 Oct 2017, Peter Maydell wrote: >> On 31 October 2017 at 17:01, Stefano Stabellini <sstabellini@xxxxxxxxxx> >> 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... > > What about something along the lines of > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c > index 9e18b41..0851071 100644 > --- a/hw/arm/virt.c > +++ b/hw/arm/virt.c > @@ -1401,6 +1400,10 @@ static void machvirt_init(MachineState *machine) > object_property_set_link(cpuobj, OBJECT(secure_sysmem), > "secure-memory", &error_abort); > } > + if (vms->gic_version == 3) { > + ARMCPU *cpu = ARM_CPU(cpuobj); > + cpu->id_aa64pfr0 |= 0x01000000; > + } > > object_property_set_bool(cpuobj, true, "realized", NULL); > object_unref(cpuobj); Definitely not -- the virt board should not be poking about inside the internals of the CPU object. The slightly cleaned up version of this idea is that you give the CPU an object property for "claim the GICv3 registers exist in the ID registers" and have virt.c set it. That feels like an ugly workaround for something we really ought not to have to tell the board about at all, though. thanks -- PMM _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |