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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Jun 2024 11:07:21 +0100
From: Marc Zyngier <maz@...nel.org>
To: Oliver Upton <oliver.upton@...ux.dev>
Cc: Shaoqin Huang <shahuang@...hat.com>,
	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 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:

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

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ