[PATCH v4 00/61] arm64: Add support for LPA2 at stage1 and WXN

[Catalin Marinas]

On Thu, Oct 26, 2023 at 02:21:26PM +0100, Ryan Roberts wrote:
> On 12/09/2023 15:15, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb at kernel.org>
> > 
> > This is a followup to [0], which was sent out more than 6 months ago.
> > Thanks to Ryan and Mark for feedback and review. This series is
> > independent from Ryan's work on adding support for LPA2 to KVM - the
> > only potential source of conflict should be the patch "arm64: kvm: Limit
> > HYP VA and host S2 range to 48 bits when LPA2 is in effect", which could
> > simply be dropped in favour of the KVM changes to make it support LPA2.
> > 
> > Changes since v3:
> > - add some acks and incorporate some minor suggested tweaks, mostly
> >   related to coding style and comments
> > - rebase onto v6.6-rc1
> > - add patch to deal with references to PTE_MAYBE_NG from asm code
> > - add patch to move dummy 'nokaslr' parsing routine out of
> >   idreg-override.c
> > - rework ptdump address marker array population
> > 
> > NOTE: this series still does not address the TLBI changes needed for
> > LPA2 and 5 level paging. Ryan seems to have a good handle on those, and
> > this work is complementary with his KVM work to a fair extent anyway.
> 
> As per the above note, I think this series would be broken on a system that
> supports both LPA2 and TLB_RANGE. The issue is that the BADDR field is specified
> in 64K units when LPA2 is enabled, but in PAGE_SIZE units when LPA2 is disabled.
> I think this patch set will continue to set BADDR in PAGE_SIZE units when LPA2
> is enabled, causing the HW to invalidate the wrong range?
> 
> My patch at [1] solves this. I'm currently doing some benchmarking refactoring
> the patches into a differnet shape as requested by Mark.
> 
> Anyway, I wonder if this is a blocker for merging this series?
> 
> [1] https://lore.kernel.org/kvmarm/20231009185008.3803879-3-ryan.roberts@arm.com/

Thanks Ryan. I missed this part. While I could add your patch on top, we
are debugging some CI reports, so there's a good chance that I'll drop
the whole branch later today.

I was hoping I can keep part of the series but it probably makes more
sense to merge the first 15-20 patches after -rc1 (no new feature added)
and keep them in next for a while. We don't have time before the merging
window to test what other CIs report (and we haven't managed to
reproduce the errors either).

-- 
Catalin