Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Zhou Wang <wangzhou1@hisilicon.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
	Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	<linux-arm-kernel@lists.infradead.org>, <kvmarm@lists.linux.dev>,
	<tangnianyao@huawei.com>, <wangwudi@hisilicon.com>
Subject: Re: [PATCH] ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200803
Date: Tue, 08 Jul 2025 13:47:47 +0100	[thread overview]
Message-ID: <86sej6alxo.wl-maz@kernel.org> (raw)
In-Reply-To: <73ee91b8-ba15-2534-ab76-f64e59261b1e@hisilicon.com>

On Tue, 08 Jul 2025 13:05:24 +0100,
Zhou Wang <wangzhou1@hisilicon.com> wrote:
> 
> On 2025/7/3 18:44, Marc Zyngier wrote:
> > On Wed, 02 Jul 2025 10:57:13 +0100,
> > Zhou Wang <wangzhou1@hisilicon.com> wrote:
> >>
> >> However,migration between different KVMs will be broken :(
> >> I am not sure that should we consider this case as well?
> > 
> > This isn't optional. You cannot break migration on existing systems,
> > and the only case that *must* break is to restore a VM that hasn't
> > seen this limitation on a HW that enforces it.
> 
> So the whole story is that we should let GICD_TYPE.num_LPIs as a
> writable field, and set this field from VMM(e.g. QEMU). And it will
> be failed if doing migration between VMs with different num_LPI
> configurations.

Note that on a non-broken system, setting num_LPIs to any value should
always work.

> After above done, this errata could be added.

Which would be the only case where num_LPIs wouldn't be writable, and
set to a fixed value.

Note that an alternative would be to not have a kernel erratum, but to
force num_LPIs from userspace when running on your platform. But that
implies that: you have your own, non-upstream VMM, and that there is
no opportunity for userspace to adversely impact the system as a whole.

> Not sure my thought above is right? I will try to prepare a num_LPIs
> writable patch if the direction is right.

I think you got the gist of it.

Thanks,

	M.

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

  reply	other threads:[~2025-07-08 12:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-26 12:41 [PATCH] ARM64: errata: Add workaround for HIP10/HIP10C erratum 162200803 Zhou Wang
2025-06-26 13:27 ` Marc Zyngier
2025-06-27  6:36   ` Zhou Wang
2025-07-01  8:14     ` Marc Zyngier
2025-07-02  9:57       ` Zhou Wang
2025-07-03 10:44         ` Marc Zyngier
2025-07-08 12:05           ` Zhou Wang
2025-07-08 12:47             ` Marc Zyngier [this message]
2025-07-09  2:08               ` Zhou Wang

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=86sej6alxo.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=tangnianyao@huawei.com \
    --cc=wangwudi@hisilicon.com \
    --cc=wangzhou1@hisilicon.com \
    --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