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

[Ryan Roberts]

On 26/10/2023 14:52, Catalin Marinas wrote:
> 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).
> 

OK that's a shame. I was hoping this would go in this cycle, then I could add
the KVM changes on top and smooth it all out for the cycle after. I guess we
will figure out how to land them both at the same time for 6.8.