linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


  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