Re: [RFC] [PATCH] kvm: arm: Introduce error code KVM_EINVARIANT

[Marc Zyngier <marc.zyngier@arm.com>]

On Sat, 10 Nov 2018 22:18:47 +0000,
Manish Jaggi <mjaggi@caviumnetworks.com> wrote:
> 
> 
> CCing a larger audience.
> Please review.
> 
> On 10/23/2018 03:51 PM, Jaggi, Manish wrote:
> > From: Manish Jaggi <manish.jaggi@cavium.com>
> >
> > This patch introduces an error code KVM_EINVARIANT which is returned
> > by KVM when userland tries to set an invariant register.
> >
> > The need for this error code is in VM Migration for arm64.
> > ARM64 systems use mainly -machine virt -cpu host as parameter to qemu.
> > Migration requires both Source and destination machines to have same
> > physical cpu. There are cases where the overall architecture of CPU is
> > same but the next version of the chip with some bug fixes which have no
> > effect on qemu operation. In such cases invariant registers like MIDR
> > have a different value.
> > Currently Migration fails in such cases.
> >
> > Rather than sending a EINVAL, a specifc error code will help
> > userland program the guest invariant register by querying the migrated
> > host machines invariant registers.

But failing migration is a good thing, right? How do you expect that
the guest will be happy to see a new CPU revision right in the middle
of its execution? Do you also propose that QEMU starts doing that for
big-little systems? After all, if ignoring the differences in some
registers is harmless for migration, surely that should be the case in
a single system, right?

> >
> > Qemu will have a parameter -hostinvariant along with checking of this
> > error code. So it can be safely assumed that the feature is opt-in

You're changing the ABI without any buy in from userspace, which is
not acceptable.

As it stands, this patch creates a number of issues without solving
any. Things to think about:

- How does errata management works when migrating to a different
  system?
- big-little, as mentioned above
- Are all invariant registers equal? A different MIDR has the same
  effect as a different MMFR0?

Instead of papering over architectural constants i a system, how about
allowing the relevant ID registers to be overloaded when not
incompatible?

Thanks,

	M.

-- 
Jazz is not dead, it just smell funny.