On Mon, 07 Jul 2025 10:53:38 +0100,
Peter Maydell <peter.mayd...@linaro.org> wrote:
>
> On Mon, 7 Jul 2025 at 10:30, Eric Auger <eric.au...@redhat.com> wrote:
> >
> > Hi Peter, Marc,
> >
> > On 7/4/25 2:22 PM, Peter Maydell wrote:
> > > I suppose the system registers probably generally Just Work
> > > via the sysreg GET/SET_ONE_REG API, but won't the in-kernel
> > > GICv3 have extra state that we need to migrate in
> > > hw/intc/arm_gicv3_kvm.c ?
> > Do you see some specific registers/resources that would need attention?
>
> All the EL2-only-accessible GIC registers: ICH_AP*R<n>_EL2,
> ICH_EISR_EL2, ICH_ELRSR_EL2, ICH_HCR_EL2, ICH_LR<n>_EL2,
> etc etc.
It isn't obvious to me why we'd expose any of the status registers to
userspace. ICH_{EISR,ELRSR,MISR}_EL2 are entirely synthetic, and are
directly generated by the emulation from the rest of the state.
Save/restoring this state would make things pointlessly complicated,
unless I'm missing something obvious.
> These all need to be exposed via KVM_DEV_ARM_VGIC_GRP_CPU_SYSREG
> and hw/intc/arm_gicv3_kvm.c needs code to be able to save and
> restore them into the GIC data structures (and we need to make
> sure the kernel isn't accidentally exposing them as CPU registers
> via the GET/SET_ONE_REG API, I think, in whatever way we do
> that for the existing EL1 GIC cpuif registers).
>
> I don't see any of the EL2 sysregs listed in the kernel's
> gic_v3_icc_reg_descs[], which looks like it's what drives
> the handling of KVM_DEV_ARM_VGIC_GRP_CPU_SYSREG.
Hmmm... This is indeed pretty inconsistent. I'll have a look at it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
