linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	kvmarm@lists.linux.dev, oliver.upton@linux.dev, will@kernel.org,
	mark.rutland@arm.com, cohuck@redhat.com, eric.auger@redhat.com,
	sebott@redhat.com, yuzenghui@huawei.com, wangzhou1@hisilicon.com,
	jiangkunkun@huawei.com, jonathan.cameron@huawei.com,
	anthony.jebson@huawei.com, linux-arm-kernel@lists.infradead.org,
	linuxarm@huawei.com
Subject: Re: [PATCH v6 4/4] arm64: paravirt: Enable errata based on implementation CPUs
Date: Fri, 7 Feb 2025 18:10:08 +0000	[thread overview]
Message-ID: <Z6ZMgDyyA5oV99hu@arm.com> (raw)
In-Reply-To: <86h655u8r3.wl-maz@kernel.org>

On Fri, Feb 07, 2025 at 02:31:12PM +0000, Marc Zyngier wrote:
> On Fri, 07 Feb 2025 14:08:44 +0000,
> Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Wed, Feb 05, 2025 at 01:22:22PM +0000, Shameer Kolothum wrote:
> > >  static inline bool is_midr_in_range(struct midr_range const *range)
> > >  {
> > > -	return midr_is_cpu_model_range(read_cpuid_id(), range->model,
> > > -				       range->rv_min, range->rv_max);
> > > +	int i;
> > > +
> > > +	if (!target_impl_cpu_num)
> > > +		return midr_is_cpu_model_range(read_cpuid_id(), range->model,
> > > +					       range->rv_min, range->rv_max);
> > > +
> > > +	for (i = 0; i < target_impl_cpu_num; i++) {
> > > +		if (midr_is_cpu_model_range(target_impl_cpus[i].midr,
> > > +					    range->model,
> > > +					    range->rv_min, range->rv_max))
> > > +			return true;
> > > +	}
> > > +	return false;
> > >  }
> > 
> > It's a interesting approach but how does this work in practice if an
> > erratum requires a firmware counterpart? Do we expect firmwares on all
> > machines involved to have workarounds for the other machines? Or is KVM
> > going to intercept those SMCs and pretend the EL3 counterpart is there?
> 
> KVM already traps SMCs, and could do something on behalf of the guest
> (such as pretending that the mitigation has happened if not on the
> correct host) *IF* the mitigation is architected (à la WA{1,2,3}).

That's the main thing I had in mind. I don't think we have any other
errata that requires firmware run-time discovery and interaction, though
you never know when we'll add new one.

> If it is implementation specific, then we can immediately stop
> pretending that a guest running on those systems can be migrated.

Makes sense.

> The only thing it helps a bit is big-little.

It does help a bit or, at least, we have some code for handling these
variations that cab be extended. However, with this patchset, the host
only probes the availability of the workarounds on the SoC it booted. It
has no idea about the extra MIDRs the VMM picks and what the other
machines in the clouds support.

Anyway, let's hope the VMs only migrate between platforms that are
equally broken.

-- 
Catalin


  reply	other threads:[~2025-02-07 18:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05 13:22 [PATCH v6 0/4] KVM: arm64: Errata management for VM Live migration Shameer Kolothum
2025-02-05 13:22 ` [PATCH v6 1/4] arm64: Modify _midr_range() functions to read MIDR/REVIDR internally Shameer Kolothum
2025-02-05 13:22 ` [PATCH v6 2/4] KVM: arm64: Introduce hypercall support for retrieving target implementations Shameer Kolothum
2025-02-05 13:22 ` [PATCH v6 3/4] KVM: arm64: Report all the KVM/arm64-specific hypercalls Shameer Kolothum
2025-02-07 18:21   ` Oliver Upton
2025-02-07 18:24     ` Oliver Upton
2025-02-10 10:36       ` Shameerali Kolothum Thodi
2025-02-10 18:57         ` Oliver Upton
2025-02-05 13:22 ` [PATCH v6 4/4] arm64: paravirt: Enable errata based on implementation CPUs Shameer Kolothum
2025-02-07 14:08   ` Catalin Marinas
2025-02-07 14:31     ` Marc Zyngier
2025-02-07 18:10       ` Catalin Marinas [this message]
2025-02-07 18:17         ` Marc Zyngier

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=Z6ZMgDyyA5oV99hu@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=anthony.jebson@huawei.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=jiangkunkun@huawei.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=sebott@redhat.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=wangzhou1@hisilicon.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 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).