qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] [PATCH] kvm: arm: Introduce error code KVM_EINVAR


From: Marc Zyngier
Subject: Re: [Qemu-devel] [RFC] [PATCH] kvm: arm: Introduce error code KVM_EINVARIANT
Date: Sun, 11 Nov 2018 11:36:44 +0000
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO)

On Sat, 10 Nov 2018 22:18:47 +0000,
Manish Jaggi <address@hidden> wrote:
> 
> 
> CCing a larger audience.
> Please review.
> 
> On 10/23/2018 03:51 PM, Jaggi, Manish wrote:
> > From: Manish Jaggi <address@hidden>
> >
> > 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]