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

[Oliver Upton]

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,
Oliver