[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZstlXHnSvlfnia/D@shell.armlinux.org.uk>
Date: Sun, 25 Aug 2024 18:09:48 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Marc Zyngier <maz@...nel.org>
Cc: Shaoqin Huang <shahuang@...hat.com>,
Oliver Upton <oliver.upton@...ux.dev>, kvmarm@...ts.linux.dev,
Mark Brown <broonie@...nel.org>, Eric Auger <eauger@...hat.com>,
Sebastian Ott <sebott@...hat.com>,
Cornelia Huck <cohuck@...hat.com>,
Catalin Marinas <catalin.marinas@....com>,
James Morse <james.morse@....com>, kvm@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org,
Paolo Bonzini <pbonzini@...hat.com>, Shuah Khan <shuah@...nel.org>,
Suzuki K Poulose <suzuki.poulose@....com>,
Will Deacon <will@...nel.org>, Zenghui Yu <yuzenghui@...wei.com>
Subject: Re: [PATCH v5 0/4] Allow userspace to change ID_AA64PFR1_EL1
On Sun, Aug 25, 2024 at 05:46:36PM +0100, Marc Zyngier wrote:
> On Tue, 23 Jul 2024 08:19:59 +0100,
> Shaoqin Huang <shahuang@...hat.com> wrote:
> >
> > Hi guys,
> >
> > This is another try to allow userspace to change ID_AA64PFR1_EL1, and we want to
> > give userspace the ability to control the visible feature set for a VM, which
> > could be used by userspace in such a way to transparently migrate VMs.
>
>
> I think this looks OK now, thanks for going through the motions and
> doing the right thing.
>
> What is missing is similar handling for 32bit ID registers, but I'm
> not sure we keen on going down that road -- machines capable of
> running those are on their way out. This can be done later anyway,
> should anyone care.
The Aarch32 ID registers need doing - we've already established that
fact. Sadly, you decided you wouldn't respond to my patch addressing
one of the Aarch32 ID registers despite me sending follow-ups to nicely
ask you about this - you seemed to go utterly silent on it.
The Aarch32 ID registers have changed value between different kernel
versions, and given that QEMU saves and restores _all_ ID registers,
changes to these ID registers cause a regression if one attempts to
migrate VMs between one kernel version and the next. It doesn't even
have to be between two physical machines. Libvirt supports managed-
saving on reboot, where it saves an image of a VM at shutdown, and
restores it at the next reboot. These changes in ID registers render
effectively data loss in VMs that have been managed-saved - the
saved state of the VM has to either be destroyed, or the host kernel
reverted back and _never_ moved forward.
As you don't seem to be keen to address this (by ignoring my emails
on the topic, and now suggesting in your response above that you're
not keen to do anything with the Aarch32 ID registers, I guess this
just means that KVM on Aarch64 is going to forever suck.
I'm sure Oliver will recall my emails on this which you've decided to
ignore... he was supportive of my efforts to address this.
--
*** please note that I probably will only be occasionally responsive
*** for an unknown period of time due to recent eye surgery making
*** reading quite difficult.
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists