From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Joey Gouly <joey.gouly@arm.com>,
Christoffer Dall <cdall@cs.columbia.edu>,
KVM <kvm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the kvm-arm tree
Date: Thu, 22 Feb 2024 18:58:39 +0000 [thread overview]
Message-ID: <ZdeZX34HpANzWKXj@linux.dev> (raw)
In-Reply-To: <87frxka7ud.wl-maz@kernel.org>
On Thu, Feb 22, 2024 at 02:31:38PM +0000, Marc Zyngier wrote:
> On Thu, 22 Feb 2024 13:11:59 +0000,
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> > On 2/22/24 12:40, Stephen Rothwell wrote:
> > >> This fails because https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=fdd867fe9b32
> > >> added new fields to that register (ID_AA64DFR1_EL1)
> > >>
> > >> and commit b80b701d5a6 ("KVM: arm64: Snapshot all non-zero RES0/RES1 sysreg fields for later checking")
> > >> took a snapshot of the fields, so the RES0 (reserved 0) bits don't match anymore.
> > >>
> > >> Not sure how to resolve it in the git branches though.
> > >
> > > Thanks. I will apply this patch to the merge of the kvm-arm tree from
> > > tomorrow (and at the end of today's tree).
> >
> > Marc, Oliver, can you get a topic branch from Catalin and friends for
> > this sysreg patch, and apply the fixup directly to the kvm-arm branch
> > in the merge commit?
> >
> > Not _necessary_, as I can always ask Linus to do the fixup, but
> > generally he prefers to have this sorted out by the maintainers if it
> > is detected by linux-next.
>
> I think that's not the correct thing to do at this time. I should have
> timed the introduction of these checks a bit later, after the merge
> window.
>
> But more to the point, the proposed patch is also not the best thing
> to merge, because it hides that there is a discrepancy between what
> the architecture describes, and what KVM knows. I really want to know
> about it, or it will be yet another bug that we wont detect easily.
> Specially for ID_AA64DFR*_EL1 which are a bloody mine-field.
>
> So I'd rather we make the check optional, and we'll play catch up for
> a bit longer. Something like the patch below.
>
> Oliver, do you mind queuing this ASAP (also pushed out to my dev
> branch)?
>
> Thanks,
>
> M.
>
> From 85d861a6ca055c7681c826c580e7c90d74c26ac5 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <maz@kernel.org>
> Date: Thu, 22 Feb 2024 14:12:09 +0000
> Subject: [PATCH] KVM: arm64: Make build-time check of RES0/RES1 bits optional
>
> In order to ease the transition towards a state of absolute
> paranoia where all RES0/RES1 bits gets checked against what
> KVM know of them, make the checks optional and garded by a
> config symbol (CONFIG_KVM_ARM64_RES_BITS_PARANOIA) default to n.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Applied as commit 99101dda29e3 ("KVM: arm64: Make build-time check of
RES0/RES1 bits optional") on the kvmarm/next branch.
--
Thanks,
Oliver
next prev parent reply other threads:[~2024-02-22 18:58 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 11:03 linux-next: build failure after merge of the kvm-arm tree Stephen Rothwell
2024-02-22 11:11 ` Joey Gouly
2024-02-22 11:40 ` Stephen Rothwell
2024-02-22 13:11 ` Paolo Bonzini
2024-02-22 13:11 ` Paolo Bonzini
2024-02-22 14:31 ` Marc Zyngier
2024-02-22 18:58 ` Oliver Upton [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-09-23 15:28 Mark Brown
2025-09-23 16:02 ` Will Deacon
2025-09-23 16:44 ` Will Deacon
2025-09-24 2:37 ` Anshuman Khandual
2025-09-24 7:45 ` Will Deacon
2025-07-29 4:22 Stephen Rothwell
2025-07-29 18:05 ` Oliver Upton
2025-03-20 9:32 Stephen Rothwell
2025-03-20 13:35 ` Oliver Upton
2025-03-06 5:46 Stephen Rothwell
2025-03-06 9:56 ` Shameerali Kolothum Thodi
2025-03-07 0:00 ` Marc Zyngier
2025-03-07 0:51 ` Oliver Upton
2023-10-05 1:31 Stephen Rothwell
2023-10-05 1:53 ` Oliver Upton
2022-05-05 10:10 Stephen Rothwell
2022-05-05 10:11 ` Stephen Rothwell
2022-05-05 11:27 ` Marc Zyngier
2016-09-23 3:31 Stephen Rothwell
2016-09-23 8:43 ` Marc Zyngier
2014-09-22 4:06 Stephen Rothwell
2014-09-22 5:07 ` Eric Auger
2014-09-22 5:31 ` Eric Auger
[not found] ` <CAEDV+g+qVgG+=1Q7gBCPs8oAjK8rpzpoQ2cPMF0hi5Q1M3Nckw@mail.gmail.com>
2014-09-22 21:26 ` Paolo Bonzini
2014-09-24 6:50 ` Stephen Rothwell
2014-09-24 7:06 ` Christoffer Dall
2014-09-24 10:05 ` Paolo Bonzini
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=ZdeZX34HpANzWKXj@linux.dev \
--to=oliver.upton@linux.dev \
--cc=cdall@cs.columbia.edu \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=maz@kernel.org \
--cc=pbonzini@redhat.com \
--cc=sfr@canb.auug.org.au \
/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).