Re: [PATCH v5 20/23] KVM: arm64: GICv4.1: Plumb SGI implementation selection in the distributor

[Zenghui Yu]

Hi Marc,

On 2020/3/23 16:25, Marc Zyngier wrote:
> Hi Zenghui,
>
> [...]
>
> > > And actually, maybe we can handle that pretty cheaply. If userspace
> > > tries to restore GICD_TYPER2 to a value that isn't what KVM can
> > > offer, we just return an error. Exactly like we do for GICD_IIDR.
> > > Hence the following patch:
> > >
> > > diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c 
> > > b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> > > index 28b639fd1abc..e72dcc454247 100644
> > > --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> > > +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> > > @@ -156,6 +156,7 @@ static int vgic_mmio_uaccess_write_v3_misc(struct 
> > > kvm_vcpu *vcpu,
> > > ÂÂÂÂÂ struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
> > >
> > > ÂÂÂÂÂ switch (addr & 0x0c) {
> > > +ÂÂÂ case GICD_TYPER2:
> > > ÂÂÂÂÂ case GICD_IIDR:
> > > ÂÂÂÂÂÂÂÂÂ if (val != vgic_mmio_read_v3_misc(vcpu, addr, len))
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂ return -EINVAL;
> > >
> > > Being a RO register, writing something that isn't compatible with the
> > > possible behaviour of the hypervisor will just return an error.
> >
> > This is really a nice point to address my concern! I'm happy to see
> > this in v6 now.
> >
> > > What do you think?
> >
> > I agreed with you, with a bit nervous though. Some old guests (which
> > have no knowledge about GICv4.1 vSGIs and don't care about nASSGIcap
> > at all) will also fail to migrate from A to B, just because now we
> > present two different (unused) GICD_TYPER2 registers to them.
> >
> > Is it a little unfair to them :-) ?
>
> I never pretended to be fair! ;-)
>
> I'm happy to prevent migrating from a v4.1 system (A) to a v4.0
> system (B). As soon as the guest has run, it isn't safe to do so
> (it may have read TYPER2, and now knows about vSGIs). We *could*
> track this and find ways to migrate this state as well, but it
> feels fragile.
>
> Migrating from B to A is more appealing. It should be possible to
> do so without much difficulty (just check that the nASSGIcap bit
> is either 0 or equal to KVM's view of the capability).
>
> But overall I seriously doubt we can easily migrate guests across
> very different HW. We've been talking about this for years, and
> we still don't have a good solution for it given the diversity
> of the ecosystem... :-/

Fair enough. Thanks for your detailed explanation!


Zenghui