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

[Marc Zyngier <maz@kernel.org>]

On Fri, 11 Oct 2024 11:57:10 +0100,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@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.

>  
> > - I don't think the "errata bitmap" works. That's a construct that is
> >   specific to Linux, and that cannot be supported for other OSs. It
> >   also limits the described issues to those the host knows, instead of
> >   the guest. The host doesn't have a clue what the guest really wants.
> >   Really, the guest should have enough information to decide what to
> >   do based on its own view of the ID registers and the list of CPUs it
> >   runs on.
> 
> Yes. "errata bitmap" is specific to Linux. So if we go with the above 
> hypercall-->VMM path and get the target CPU list, Guest can directly
> use that.

Indeed, and this is something that is much easier to standardise upon,
as I really want this to be a universal mechanism.

> > - To answer your question about CTR_EL0: KVM should (and does)
> >   sanitise that register by trapping it. This should be the default
> >   behaviour for things that need to be mitigated outside of
> >   MIDR/REVIDR.
> 
> Ok. Make sense and simplifies things.
> 
> Please let me know whether my understanding on hypercall<->VMM is 
> correct or not. I can take a look at that route.

Yes, I think we are aligned on it.

Thanks again,

	M.

-- 
Without deviation from the norm, progress is not possible.