linux-kernel - Re: [PATCH v2 00/23] KVM: arm64: Improvements to LPI injection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 15 Feb 2024 15:37:45 +0000
From: Marc Zyngier <maz@...nel.org>
To: Oliver Upton <oliver.upton@...ux.dev>
Cc: kvmarm@...ts.linux.dev,
	kvm@...r.kernel.org,
	James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/23] KVM: arm64: Improvements to LPI injection

On Wed, 14 Feb 2024 18:40:27 +0000,
Oliver Upton <oliver.upton@...ux.dev> wrote:
> 
> On Wed, Feb 14, 2024 at 05:43:13PM +0000, Marc Zyngier wrote:
> > On Tue, 13 Feb 2024 09:32:37 +0000,
> > Oliver Upton <oliver.upton@...ux.dev> wrote:
> > > 
> > > For full details on the what/why, please see the cover letter in v1.
> > > 
> > > Apologies for the delay on v2, I wanted to spend some time to get a
> > > microbenchmark in place to slam the ITS code pretty hard, and based on
> > > the results I'm glad I did.
> > 
> > [...]
> > 
> > Buglets and potential improvements aside, I like the smell of this. At
> > least the first handful of patches could easily be taken as a separate
> > improvement series.
> > 
> > Let me know how you'd like to play this.
> 
> Yeah, I think there's 3 independent series here if we want to take the
> initial improvements:
> 
>  - Address contention around vgic_get_irq() / vgic_put_irq() with the
>    first 10 patches. Appears there is violent agreement these are good
>    to go.
> 
>  - Changing out the translation cache into a per-ITS xarray
> 
>  - A final series cleaning up a lot of the warts we have in LPI
>    management, like vgic_copy_lpi_list(). I believe we can get rid of
>    the lpi_list_lock as well, but this needs to be ordered after the
>    first 2.
> 
> I'd really like to de-risk the performance changes from the cleanups, as
> I'm convinced they're going to have their own respective piles of bugs.
> 
> How does that sound?

Yup, I'd be on board with that. If you can respin the first part with
bugs fixed and without the stats, that'd be great. We can further
bikeshed on the rest in the 6.10 time frame.

Also please Cc: Eric Auger, as he dealt with a lot of the ITS
save/restore stuff.

Thanks,

	M.

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