[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.