linux-kernel - Re: [RFC PATCH v1 0/2] KVM: arm64: Making BT Field in ID_AA64PFR1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZmqwCbxvBErCZ43v@linux.dev>
Date: Thu, 13 Jun 2024 01:38:33 -0700
From: Oliver Upton <oliver.upton@...ux.dev>
To: Shaoqin Huang <shahuang@...hat.com>
Cc: Marc Zyngier <maz@...nel.org>, kvmarm@...ts.linux.dev,
	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: [RFC PATCH v1 0/2] KVM: arm64: Making BT Field in
 ID_AA64PFR1_EL1 writable

On Thu, Jun 13, 2024 at 04:31:45PM +0800, Shaoqin Huang wrote:
> Hi Marc,
> 
> On 6/12/24 18:07, Marc Zyngier wrote:
> > On Wed, 12 Jun 2024 06:30:51 +0100,
> > Oliver Upton <oliver.upton@...ux.dev> wrote:
> > > 
> > > Hi Shaoqin,
> > > 
> > > On Tue, Jun 11, 2024 at 10:35:50PM -0400, Shaoqin Huang wrote:
> > > > Hi guys,
> > > > 
> > > > I'm trying to enable migration from MtCollins(Ampere Altra, ARMv8.2+) to
> > > > AmpereOne(AmpereOne, ARMv8.6+), the migration always fails when migration from
> > > > MtCollins to AmpereOne due to some register fields differing between the
> > > > two machines.
> > > > 
> > > > In this patch series, we try to make more register fields writable like
> > > > ID_AA64PFR1_EL1.BT. This is first step towards making the migration possible.
> > > > Some other hurdles need to be overcome. This is not sufficient to make the
> > > > migration successful from MtCollins to AmpereOne.
> > > 
> > > It isn't possible to transparently migrate between these systems. The
> > > former has a cntfrq of 25MHz, and the latter has a cntfrq of 1GHz. There
> > > isn't a mechanism for scaling the counter frequency, and I have zero
> > > appetite for a paravirt interface.
> > 
> > Note that there *is* an architectural workaround in the form of
> > FEAT_CNTSC. But of course:

Heh, I should've further specified a per-CPU mechanism :)

> > - it is optional (and likely not implemented)
> > - it is global (hence affecting all SW running on the machine)
> > - it invalidates the requirements of ARMv8.6 (who cares?)
> > - KVM has nothing to do with it (yay!)
> > 
> > So if the two systems (from the same manufacturer) were ever designed
> > to allow migration between the two, they would have at least baked
> > some of that in.
> > 
> > As for the paravirt interface, I agree that this is a non-starter
> > (been there, done that, dumped it in the bin).
> > 
> > The patch itself is interesting and may be of use once it has been put
> > to a compiler and not just dumped on the list without any testing.
> > 
> > 	M.
> 
> Thanks for putting your comments here.
> 
> If we don't care about the FEAT_CNTSC right now. Could I fix the compile
> issue and respin this again without the background of enabling migration
> between MtCollins and AmpereOne, and just keep the information of the
> different BT field between different machine?

I don't think cross-platform migration is relevant for the KVM UAPI
you're trying to augment. 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.

So if you could focus the changelog purely as an improvement upon the
existing controls we expose to the VMM then the patch is more obviously
justified.

Please do respin.

-- 
Thanks,
Oliver