From: Will Deacon <will@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
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: Fri, 23 Aug 2024 14:38:42 +0100 [thread overview]
Message-ID: <20240823133842.GE32156@willie-the-truck> (raw)
In-Reply-To: <ZscEo8KJfn4xfm6X@gmail.com>
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
next prev parent reply other threads:[~2024-08-25 18:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 8:49 Breno Leitao
2024-06-18 11:36 ` Mark Rutland
2024-06-24 11:36 ` Will Deacon
2024-08-22 9:28 ` Breno Leitao
2024-08-23 13:38 ` Will Deacon [this message]
2024-10-03 11:51 ` Usama Arif
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240823133842.GE32156@willie-the-truck \
--to=will@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kexec@lists.infradead.org \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=rmikey@meta.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox