linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: Akihiko Odaki <akihiko.odaki@gmail.com>,
	linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	James Morse <james.morse@arm.com>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	asahi@lists.linux.dev, Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Sven Peter <sven@svenpeter.dev>, Hector Martin <marcan@marcan.st>
Subject: Re: [PATCH 0/3] KVM: arm64: Handle CCSIDR associativity mismatches
Date: Sun, 11 Dec 2022 10:21:06 +0000	[thread overview]
Message-ID: <868rjeqm0d.wl-maz@kernel.org> (raw)
In-Reply-To: <88bdcca8-4df4-15ff-2e88-c53255b1fe30@daynix.com>

On Sun, 11 Dec 2022 05:25:31 +0000,
Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
> 
> On 2022/12/04 23:57, Marc Zyngier wrote:
> > On Fri, 02 Dec 2022 09:55:24 +0000,
> > Akihiko Odaki <akihiko.odaki@gmail.com> wrote:
> >> 
> >> On 2022/12/02 18:40, Marc Zyngier wrote:
> >>> On Fri, 02 Dec 2022 05:17:12 +0000,
> >>> Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
> >>>> 
> >>>>>> On M2 MacBook Air, I have seen no other difference in standard ID
> >>>>>> registers and CCSIDRs are exceptions. Perhaps Apple designed this way
> >>>>>> so that macOS's Hypervisor can freely migrate vCPU, but I can't assure
> >>>>>> that without more analysis. This is still enough to migrate vCPU
> >>>>>> running Linux at least.
> >>>>> 
> >>>>> I guess that MacOS hides more of the underlying HW than KVM does. And
> >>>>> KVM definitely doesn't hide the MIDR_EL1 registers, which *are*
> >>>>> different between the two clusters.
> >>>> 
> >>>> It seems KVM stores a MIDR value of a CPU and reuse it as "invariant"
> >>>> value for ioctls while it exposes the MIDR value each physical CPU
> >>>> owns to vCPU.
> >>> 
> >>> This only affects the VMM though, and not the guest which sees the
> >>> MIDR of the CPU it runs on. The problem is that at short of pinning
> >>> the vcpus, you don't know where they will run. So any value is fair
> >>> game.
> >> 
> >> Yes, my concern is that VMM can be confused if it sees something
> >> different from what the guest on the vCPU sees.
> > 
> > Well, this has been part of the ABI for about 10 years, since Rusty
> > introduced this notion of invariant, so userspace is already working
> > around it if that's an actual issue.
> 
> In that case, I think it is better to document that the interface is
> not working properly and deprecated.

This means nothing. Deprecating an API doesn't mean we don't support
it and doesn't solve any issue for existing userspace.

I'd rather not change anything, TBH. Existing userspace already knows
how to deal with this,

> 
> > 
> > This would be easily addressed though, and shouldn't result in any
> > issue. The following should do the trick (only lightly tested on an
> > M1).
> 
> This can be problematic when restoring vcpu state saved with the old
> kernel. A possible solution is to allow the userspace to overwrite
> MIDR_EL1 as proposed for CCSIDR_EL1.

That would break most guests for obvious reasons. At best what can be
done is to make the MIDR WI.

	M.

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

  reply	other threads:[~2022-12-11 10:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01 10:49 [PATCH 0/3] KVM: arm64: Handle CCSIDR associativity mismatches Akihiko Odaki
2022-12-01 10:49 ` [PATCH 1/3] KVM: arm64: Make CCSIDRs consistent Akihiko Odaki
2022-12-01 10:49 ` [PATCH 2/3] arm64: errata: Check for mismatched cache associativity Akihiko Odaki
2022-12-01 10:49 ` [PATCH 3/3] KVM: arm64: Handle CCSIDR associativity mismatches Akihiko Odaki
2022-12-01 11:06 ` [PATCH 0/3] " Marc Zyngier
2022-12-01 17:26   ` Akihiko Odaki
2022-12-01 23:13     ` Marc Zyngier
2022-12-02  5:17       ` Akihiko Odaki
2022-12-02  9:40         ` Marc Zyngier
2022-12-02  9:55           ` Akihiko Odaki
2022-12-04 14:57             ` Marc Zyngier
2022-12-11  5:25               ` Akihiko Odaki
2022-12-11 10:21                 ` Marc Zyngier [this message]
2022-12-11 10:44                   ` Akihiko Odaki
2022-12-01 18:29   ` Oliver Upton
2022-12-01 23:14     ` Marc Zyngier
2022-12-02 18:54       ` Oliver Upton

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=868rjeqm0d.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=akihiko.odaki@daynix.com \
    --cc=akihiko.odaki@gmail.com \
    --cc=alexandru.elisei@arm.com \
    --cc=alyssa@rosenzweig.io \
    --cc=asahi@lists.linux.dev \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=mathieu.poirier@linaro.org \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=sven@svenpeter.dev \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).