All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.