From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH RFC] KVM: arm64: allow ID_MMFR4_EL1 to be writable
Date: Wed, 1 May 2024 20:51:15 +0100 [thread overview]
Message-ID: <ZjKdM935rsvd+S9/@shell.armlinux.org.uk> (raw)
In-Reply-To: <ZjKRBcAML5T6cm4q@linux.dev>
On Wed, May 01, 2024 at 06:59:17PM +0000, Oliver Upton wrote:
> On Wed, May 01, 2024 at 07:08:05PM +0100, Russell King (Oracle) wrote:
> > On Wed, May 01, 2024 at 05:57:20PM +0000, Oliver Upton wrote:
> > > Hi Russell,
> > >
> > > On Wed, May 01, 2024 at 06:06:51PM +0100, Russell King (Oracle) wrote:
> > > > Between 5.4 and 5.15, the guests view of HPDS, CnP, XNX and AC2
> > > > changed their value on the same Neoverse N1 r3p1 hardware which makes
> > > > migrating between these kernels on the host problematical.
> > >
> > > It'd be helpful to expand a bit more on how these fields changed, better
> > > yet if we can blame it back to a commit. I'm guessing the only direction
> > > of migration you care about is old -> new then?
> >
> > Yes. For MMFR4_EL1, we see 0 with our 5.4 based kernel, and 0x21110
> > with our 5.15 kernel. I've been looking at tracking down which commit
> > is responsible but I've come up with nothing that fits.
> >
> > The only change I can see is the FTR definition for MMFR4, but this
> > always included 4:7 (AC2) which changed 0 -> 1. So... no idea what
> > commit caused the change.
> >
> > There are a load of other registers that we need sorting, but this
> > is just a test forray into attempting to solve this.
>
> Got it, let me see if I can find it then. Do share that list of
> problematic registers when you have it, hopefully this isn't the tip of
> the iceberg...
There unfortunately is an iceberg, but hopefully it isn't big enough to
sink a ship!
Besides ID_MMFR4_EL1, here are the other differences we've identified.
Note that these are Oracle's UEK kernels, so based on stable kernel
branches.
Register Field 5.4.x 5.15.x
ID_PFR0_EL1 CSV2 0 1
ID_ISAR6_EL1 DP 0 1
ID_PFR2_EL1 SSBS 0 1
CSV3 0 1
ID_AA64DFR0_EL1 PMSVer 1 0
DebugVer 8 6
ID_AA64MMFR1_EL1 XNX 0 1
ID_AA64MMFR2_EL1 EVT 0 1
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2
0x12 0
I think some of these differences are due to Marc's removal of the
WA2 code in commit 29e8910a566a ("KVM: arm64: Simplify handling of
ARCH_WORKAROUND_2"). The WA2 register for example has changed from
avail/enabled to not_avail.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH RFC] KVM: arm64: allow ID_MMFR4_EL1 to be writable
Date: Wed, 1 May 2024 20:51:15 +0100 [thread overview]
Message-ID: <ZjKdM935rsvd+S9/@shell.armlinux.org.uk> (raw)
In-Reply-To: <ZjKRBcAML5T6cm4q@linux.dev>
On Wed, May 01, 2024 at 06:59:17PM +0000, Oliver Upton wrote:
> On Wed, May 01, 2024 at 07:08:05PM +0100, Russell King (Oracle) wrote:
> > On Wed, May 01, 2024 at 05:57:20PM +0000, Oliver Upton wrote:
> > > Hi Russell,
> > >
> > > On Wed, May 01, 2024 at 06:06:51PM +0100, Russell King (Oracle) wrote:
> > > > Between 5.4 and 5.15, the guests view of HPDS, CnP, XNX and AC2
> > > > changed their value on the same Neoverse N1 r3p1 hardware which makes
> > > > migrating between these kernels on the host problematical.
> > >
> > > It'd be helpful to expand a bit more on how these fields changed, better
> > > yet if we can blame it back to a commit. I'm guessing the only direction
> > > of migration you care about is old -> new then?
> >
> > Yes. For MMFR4_EL1, we see 0 with our 5.4 based kernel, and 0x21110
> > with our 5.15 kernel. I've been looking at tracking down which commit
> > is responsible but I've come up with nothing that fits.
> >
> > The only change I can see is the FTR definition for MMFR4, but this
> > always included 4:7 (AC2) which changed 0 -> 1. So... no idea what
> > commit caused the change.
> >
> > There are a load of other registers that we need sorting, but this
> > is just a test forray into attempting to solve this.
>
> Got it, let me see if I can find it then. Do share that list of
> problematic registers when you have it, hopefully this isn't the tip of
> the iceberg...
There unfortunately is an iceberg, but hopefully it isn't big enough to
sink a ship!
Besides ID_MMFR4_EL1, here are the other differences we've identified.
Note that these are Oracle's UEK kernels, so based on stable kernel
branches.
Register Field 5.4.x 5.15.x
ID_PFR0_EL1 CSV2 0 1
ID_ISAR6_EL1 DP 0 1
ID_PFR2_EL1 SSBS 0 1
CSV3 0 1
ID_AA64DFR0_EL1 PMSVer 1 0
DebugVer 8 6
ID_AA64MMFR1_EL1 XNX 0 1
ID_AA64MMFR2_EL1 EVT 0 1
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2
0x12 0
I think some of these differences are due to Marc's removal of the
WA2 code in commit 29e8910a566a ("KVM: arm64: Simplify handling of
ARCH_WORKAROUND_2"). The WA2 register for example has changed from
avail/enabled to not_avail.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-05-01 19:51 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 17:06 [PATCH RFC] KVM: arm64: allow ID_MMFR4_EL1 to be writable Russell King (Oracle)
2024-05-01 17:06 ` Russell King (Oracle)
2024-05-01 17:57 ` Oliver Upton
2024-05-01 17:57 ` Oliver Upton
2024-05-01 18:08 ` Russell King (Oracle)
2024-05-01 18:08 ` Russell King (Oracle)
2024-05-01 18:59 ` Oliver Upton
2024-05-01 18:59 ` Oliver Upton
2024-05-01 19:51 ` Russell King (Oracle) [this message]
2024-05-01 19:51 ` Russell King (Oracle)
2024-05-02 10:50 ` Russell King (Oracle)
2024-05-02 10:50 ` Russell King (Oracle)
2024-05-02 15:23 ` Marc Zyngier
2024-05-02 15:23 ` Marc Zyngier
2024-05-07 9:27 ` Russell King (Oracle)
2024-05-07 9:27 ` Russell King (Oracle)
2024-05-02 14:40 ` Russell King (Oracle)
2024-05-02 14:40 ` Russell King (Oracle)
2024-05-02 16:45 ` Oliver Upton
2024-05-02 16:45 ` Oliver Upton
2024-05-08 12:06 ` Cornelia Huck
2024-05-08 12:06 ` Cornelia Huck
2024-05-08 17:14 ` Oliver Upton
2024-05-08 17:14 ` Oliver Upton
2024-05-10 15:11 ` Cornelia Huck
2024-05-10 15:11 ` Cornelia Huck
2024-05-13 21:26 ` Oliver Upton
2024-05-13 21:26 ` Oliver Upton
2024-05-22 10:14 ` Cornelia Huck
2024-05-22 10:14 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZjKdM935rsvd+S9/@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.