Re: [PATCH v2] xen/arm: p2m don't fall over on FEAT_LPA enabled hw

From: "Alex Bennée" <alex.bennee@linaro.org>
To: Julien Grall <julien@xen.org>
Cc: xen-devel@lists.xenproject.org, stratos-dev@op-lists.linaro.org,
	Richard Henderson <richard.henderson@linaro.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>
Subject: Re: [PATCH v2] xen/arm: p2m don't fall over on FEAT_LPA enabled hw
Date: Tue, 10 May 2022 15:47:04 +0100	[thread overview]
Message-ID: <87y1z9sauw.fsf@linaro.org> (raw)
In-Reply-To: <191159cc-f26d-f161-3f44-431507a6c270@xen.org>

Julien Grall <julien@xen.org> writes:

> Hi Alex,
>
> On 10/05/2022 15:03, Alex Bennée wrote:
>> Julien Grall <julien@xen.org> writes:
>> 
>>> Hi Alex,
>>>
>>> On 28/04/2022 11:34, Alex Bennée wrote:
>>>> When we introduced FEAT_LPA to QEMU's -cpu max we discovered older
>>>> kernels had a bug where the physical address was copied directly from
>>>> ID_AA64MMFR0_EL1.PARange field. The early cpu_init code of Xen commits
>>>> the same error by blindly copying across the max supported range.
>>>> Unsurprisingly when the page tables aren't set up for these greater
>>>> ranges hilarity ensues and the hypervisor crashes fairly early on in
>>>> the boot-up sequence. This happens when we write to the control
>>>> register in enable_mmu().
>>>> Attempt to fix this the same way as the Linux kernel does by gating
>>>> PARange to the maximum the hypervisor can handle. I also had to fix up
>>>> code in p2m which panics when it sees an "invalid" entry in PARange.
>>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>>> Cc: Richard Henderson <richard.henderson@linaro.org>
>>>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>>>> Cc: Julien Grall <julien@xen.org>
>>>> Cc: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
>>>> Cc: Bertrand Marquis <bertrand.marquis@arm.com>
>>>
>>> Acked-by: Julien Grall <jgrall@amazon.com>
>> Will you pick this up via your tree or do I need to do something
>> else to
>> get it upstreamed? I guess it needs to go on master and last stable?
>
> We only have one tree in Xen where committers (such as Stefano and I)
> will commit patches regularly to staging. Osstest will then push to
> master once the testing passed.
>
> I have done that now. Interestingly, git am wasn't able to apply this
> patch. I had to do with:
>
> 42sh> git am --show-current-patch=diff | patch -p1
> patching file xen/arch/arm/arm64/head.S
> Hunk #1 succeeded at 474 (offset 1 line).
> patching file xen/arch/arm/p2m.c
> Hunk #1 succeeded at 32 with fuzz 2.
> Hunk #2 succeeded at 2023 (offset -7 lines).
> Hunk #3 succeeded at 2031 (offset -7 lines).
> Hunk #4 succeeded at 2062 (offset -7 lines).
>
> Which branch did you use for sending the patch?

0941d6cb23 from RELEASE-4.16.0

> Regarding stable, I will add the patch in my backport candidate list
> and send a list to Stefano when we prepare the backports.
>
> Cheers,

-- 
Alex Bennée