From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Jinqian Yang <yangjinqian1@huawei.com>
Subject: Re: [PATCH 00/11] KVM: arm64: nv: Align feature limitations with current state of support
Date: Fri, 12 Sep 2025 14:48:23 -0700 [thread overview]
Message-ID: <aMSVJ_CYh82GuWYY@linux.dev> (raw)
In-Reply-To: <87ecsbz6s6.wl-maz@kernel.org>
On Fri, Sep 12, 2025 at 10:43:05PM +0100, Marc Zyngier wrote:
> > In so doing, I found a bug relating to FEAT_DoubleLock where we
> > accidentally claim support where we shouldn't as the 0 value implies
> > the feature is implemented.
>
> Meh. Don't you love negative features?
Just about as fun as negative polarity traps.
> > I've made each relaxation into its own patch to capture the rationale in
> > the changelog but I'm also fine squashing these based on the affected
> > register. Features that limit our MMU implementation are deliberately
> > left masked, e.g. FEAT_ETS* and FEAT_nTLBPA place constraints on the
> > behavior of our nested MMU. Although the latter is highly unlikely to
> > matter.
>
> Well, unlikely to matter for S2. For S1, this is a different story.
Indeed -- just my general impression is that we shouldn't constrain
ourselves in terms of future MMU / TLB behavior at this point.
> > Applies to 6.17-rc4. **NOTE** this depends on Jinqian's series to make
> > ID_AA64MMFR1_EL1.TWED writable [*], that should be applied before this
> > series.
>
> Thanks for that. I'll have a look shortly.
I'll also have a look at the series, need to revisit an open Q from the
last spin.
Thanks,
Oliver
next prev parent reply other threads:[~2025-09-12 21:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-12 21:22 [PATCH 00/11] KVM: arm64: nv: Align feature limitations with current state of support Oliver Upton
2025-09-12 21:22 ` [PATCH 01/11] KVM: arm64: nv: Convert masks to denylists in limit_nv_id_reg() Oliver Upton
2025-09-12 21:22 ` [PATCH 02/11] KVM: arm64: nv: Don't erroneously claim FEAT_DoubleLock for NV VMs Oliver Upton
2025-09-12 21:22 ` [PATCH 03/11] KVM: arm64: nv: Expose FEAT_DF2 to NV-enabled VMs Oliver Upton
2025-09-12 21:22 ` [PATCH 04/11] KVM: arm64: nv: Expose FEAT_RASv1p1 via RAS_frac Oliver Upton
2025-09-12 21:22 ` [PATCH 05/11] KVM: arm64: nv: Expose FEAT_ECBHB to NV-enabled VMs Oliver Upton
2025-09-12 21:22 ` [PATCH 06/11] KVM: arm64: nv: Expose FEAT_AFP " Oliver Upton
2025-09-12 21:22 ` [PATCH 07/11] KVM: arm64: nv: Exclude guest's TWED configuration when TWE isn't set Oliver Upton
2025-09-12 21:22 ` [PATCH 08/11] KVM: arm64: nv: Expose FEAT_TWED to NV-enabled VMs Oliver Upton
2025-09-12 21:22 ` [PATCH 09/11] KVM: arm64: nv: Advertise FEAT_SpecSEI " Oliver Upton
2025-09-12 21:22 ` [PATCH 10/11] KVM: arm64: nv: Advertise FEAT_TIDCP1 " Oliver Upton
2025-09-12 21:22 ` [PATCH 11/11] KVM: arm64: nv: Expose up to FEAT_Debugv8p8 " Oliver Upton
2025-09-12 21:43 ` [PATCH 00/11] KVM: arm64: nv: Align feature limitations with current state of support Marc Zyngier
2025-09-12 21:48 ` Oliver Upton [this message]
2025-09-19 13:15 ` 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=aMSVJ_CYh82GuWYY@linux.dev \
--to=oliver.upton@linux.dev \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=yangjinqian1@huawei.com \
--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.