Received-SPF: pass (google.com: domain of linux-kernel+bounces-28403-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240112091128.3868059-1-foxywang@tencent.com>
 <ZaFor2Lvdm4O2NWa@google.com> <CAN35MuSkQf0XmBZ5ZXGhcpUCGD-kKoyTv9G7ya4QVD1xiqOxLg@mail.gmail.com>
 <72edaedc-50d7-415e-9c45-f17ffe0c1c23@linux.ibm.com> <Zaa1omCaDQOxxy2j@google.com>
In-Reply-To: <Zaa1omCaDQOxxy2j@google.com>
From: Yi Wang <up2wing@gmail.com>
Date: Wed, 17 Jan 2024 08:56:49 +0800
Message-ID: <CAN35MuRKMW+-qrf0Sv-tsiZ71_-C_DJAMhu=HhtP8RnTVW-PsA@mail.gmail.com>
Subject: Re: [PATCH] KVM: irqchip: synchronize srcu only if needed
To: Sean Christopherson <seanjc@google.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>, pbonzini@redhat.com, tglx@linutronix.de, 
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, 
	hpa@zytor.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, 
	wanpengli@tencent.com, Yi Wang <foxywang@tencent.com>, 
	Oliver Upton <oliver.upton@linux.dev>, Marc Zyngier <maz@kernel.org>, 
	Anup Patel <anup@brainfault.org>, Atish Patra <atishp@atishpatra.org>, 
	Janosch Frank <frankja@linux.ibm.com>, Claudio Imbrenda <imbrenda@linux.ibm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 17, 2024 at 12:58=E2=80=AFAM Sean Christopherson <seanjc@google=
com> wrote:
>
> On Tue, Jan 16, 2024, Christian Borntraeger wrote:
> >
> >

...

> >
> > I would be fine with wasted memory.
>
> +1.  If we really, really want to avoid the negligible memory overhead, w=
e could
> pre-configure a static global table and directly use that as the dummy ta=
ble (and
> exempt it from being freed by free_irq_routing_table()).

Thanks for the suggestion! Well, in my opinion it may be better to fix
the current issue
and I'm glad to send another patch to optimize this.

> > The only question is does it have a functional impact or can we simply =
ignore
> > the dummy routing.
>
> Given the lack of sanity checks on kvm->irq_routing, I'm pretty sure the =
only way
> for there to be functional impact is if there's a latent NULL pointer der=
ef hiding
> somewhere.


--=20
---
Best wishes
Yi Wang