Re: arm64: Kexec: Warning: virt_to_phys used for non-linear address

From: Usama Arif <usamaarif642@gmail.com>
To: Will Deacon <will@kernel.org>, Breno Leitao <leitao@debian.org>,
	Mark Rutland <mark.rutland@arm.com>
Cc: Rob Herring <robh@kernel.org>,
	kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
	linux-mm@kvack.org, catalin.marinas@arm.com, rmikey@meta.com
Subject: Re: arm64: Kexec: Warning: virt_to_phys used for non-linear address
Date: Thu, 3 Oct 2024 12:51:32 +0100	[thread overview]
Message-ID: <1ea5538f-7e96-4034-9af9-e2d5fd72e069@gmail.com> (raw)
In-Reply-To: <20240823133842.GE32156@willie-the-truck>

On 23/08/2024 14:38, Will Deacon wrote:
> On Thu, Aug 22, 2024 at 02:28:03AM -0700, Breno Leitao wrote:
>> On Mon, Jun 24, 2024 at 12:36:14PM +0100, Will Deacon wrote:
>>> On Tue, Jun 18, 2024 at 12:36:03PM +0100, Mark Rutland wrote:
>>>> On Tue, Jun 18, 2024 at 01:49:22AM -0700, Breno Leitao wrote:
>>
>>>>> Since __pa() is a macro to __virt_to_phys():
>>>>>
>>>>> 	#define __pa(x)                 __virt_to_phys((unsigned long)(x))
>>>>>
>>>>> I am curious why this address is special that makes __virt_to_phys()
>>>>> unhappy.
>>>>
>>>> It's a fixmap address rather than a linear-map address. Confusingly
>>>> 'virt' generally means the linear map rather than any virtual address,
>>>> and usually virt_to_*() only work on linear map addresses.
>>>>
>>>> I'm not sure how to fix this; the major reason we fixmap the FDT is so
>>>> that it can be anywhere in memory (and e.g. may not be in the linear map
>>>> at all), so we can't always generate a linear map VA.
>>>>
>>>> We could stash the PA at boot time, and pass this as an argument to
>>>> of_kexec_alloc_and_setup_fdt().
>>>
>>> Yeah, if it was passed as an additional argument to early_init_dt_scan(),
>>> then the core could could track it. Alternatively, we'd need a helper
>>> macro to get the PA and have an arm64-variant for the fixmap (everybody
>>> else could use __pa()).
>>>
>>>> Rob, any thoughts? I couldn't see a neat way of doing this, but maybe we
>>>> could initialise an initial_boot_params_phys at setup time, with a bit
>>>> of churn to early_init_dt_verify() and friends?
>>>
>>> Rob?
>>
>> Hello, is there anything I can do or test to have this moving?
> 
> I've not seen anything from Rob, so the best bet is probably to see if
> you can hack up a patch to fix it yourself and then cc the rest of us
> when you post it.
> 
> Will
> 
Hi,

We are seeing this while doing kexec, so I sent a potential fix in [1].

I did print the values and they are different
initial_boot_params_pa 0x6937a00000
__pa(initial_boot_params) 0x8000125e0000

so I think a fix is necessary as we are deleting some random memory while doing
kexec which could lead to very difficult to debug crashes if its something critical.

I just stashed the physical address and used it later during kexec.
I dont see anything that could convert fixmap to phys, but maybe its there and 
I didn't find it? The other option is to write fix_to_phys which would look something
very similar to like kernel_page_present [2]? I do think the patch in [1] is much
simpler, but happy to try something like [2] or anything else that is recommended.

Thanks!
Usama

[1] https://lore.kernel.org/all/20241003113840.2972416-1-usamaarif642@gmail.com/
[2] https://elixir.bootlin.com/linux/v6.11.1/source/arch/arm64/mm/pageattr.c#L213

> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec