[RFC PATCH 0/6] KVM: arm64: Errata management for VM Live migration

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: Oliver Upton <oliver.upton at linux.dev>
> Sent: Friday, October 11, 2024 4:11 PM
> To: Marc Zyngier <maz at kernel.org>
> Cc: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi at huawei.com>; kvmarm at lists.linux.dev;
> catalin.marinas at arm.com; will at kernel.org; mark.rutland at arm.com;
> cohuck at redhat.com; eric.auger at redhat.com; yuzenghui
> <yuzenghui at huawei.com>; Wangzhou (B) <wangzhou1 at hisilicon.com>;
> jiangkunkun <jiangkunkun at huawei.com>; Jonathan Cameron
> <jonathan.cameron at huawei.com>; Anthony Jebson
> <anthony.jebson at huawei.com>; linux-arm-kernel at lists.infradead.org;
> Linuxarm <linuxarm at huawei.com>
> Subject: Re: [RFC PATCH 0/6] KVM: arm64: Errata management for VM Live
> migration
> 
> On Fri, Oct 11, 2024 at 12:43:28PM +0100, Marc Zyngier wrote:
> > On Fri, 11 Oct 2024 11:57:10 +0100, Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi at huawei.com> wrote:
> > > > >
> > > > > Please take a look and let me know your thoughts.
> > > >
> > > > Having eyeballed this very superficially, I think we can do something
> > > > simpler, and maybe more future-proof:
> > >
> > > Thanks Marc for taking a look and the quick feedback.
> >
> > No worries, that's the least I could do given that you put the effort
> > implementing my silly ideas! ;-)
> >
> > > > - I don't think KVM should be concerned about the description of the
> > > >   target CPUs. The hypercall you defined is the right thing to do,
> > > >   but the VMM should completely handle it. That's an implementation
> > > >   detail, but it would make things much simpler.
> > >
> > > Ok. So does that mean the hypercall will use some sort of shared
> memory
> > > to retrieve the list of target CPUs from VMM?
> >
> > Two possibilities:
> >
> > - either shared memory, in which case the hypercall would require the
> >   guest to give an IPA and size for the VMM to write its stuff into
> >   the guest memory,
> >
> > - or more simply return the data as an MIDR/REVIDR pair in registers,
> >   the guest requesting an index, and getting an error when out of
> >   range, leaving it with the freedom to organise the storage.
> >
> > The second option is a bit slower, but way simpler, and it only
> > happens once per guest boot, so it would probably be my preferred
> > option unless this is proved to be impractical.
> 
> Also worth noting there's existing UAPI [*] for allowing userspace to
> register range(s) of hypercalls that it services directly. It's a bit
> weird that we'd allow userspace to do stuff in KVM's own hypercall
> range, but I don't think it really matters at this point since this is
> all prototyping.
> 
> [*]: https://docs.kernel.org/virt/kvm/devices/vm.html#attribute-kvm-arm-
> vm-smccc-filter-w-o

Thanks. Yes and there are attempts to add that handling in Qemu[*] in the context
of vCPU hotplug support(PSCI related ones though).  Will take a look.

Thanks,
Shameer
[1] https://lore.kernel.org/qemu-devel/20241009033704.250287-1-salil.mehta@huawei.com/