All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Fancellu <Luca.Fancellu@arm.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Alistair Francis" <alistair.francis@wdc.com>,
	"Connor Davis" <connojdavis@gmail.com>,
	"Oleksii Kurochko" <oleksii.kurochko@gmail.com>,
	"Bertrand Marquis" <Bertrand.Marquis@arm.com>,
	"Volodymyr Babchuk" <volodymyr_babchuk@epam.com>
Subject: Re: [PATCH v2 1/2] make ioremap_attr() common
Date: Thu, 9 Apr 2026 07:26:37 +0000	[thread overview]
Message-ID: <DF8F0F78-1DBA-41B9-8055-4CD3622F6929@arm.com> (raw)
In-Reply-To: <72526f3a-726a-4a1e-8d80-1a336175c1af@suse.com>

Hi Jan,

> On 8 Apr 2026, at 13:07, Jan Beulich <jbeulich@suse.com> wrote:
> 
> This core backing function is uniform; what varies across architectures
> are the attributes passed and hence the wrappers around it. Yet of course
> extra checking or special handling may be needed per arch, so introduce a
> suitable hook.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Declarations (or inline counterparts) aren't being moved around, to avoid
> the need to touch source files using the functions. Quite possibly they
> want to consistently go into xen/io.h and asm/io.h.
> 
> Of course ioremap.c could also go into lib/.
> 
> For RISC-V the wrappers likely should become inline functions?
> 
> PPC doesn't reference any of the functions just yet, so gets only a
> declaration.
> 
> For Arm, a TODO item is deliberately retained, yet seeing the use of
> ioremap_wc() in domain building (which by itself is questionable, see next
> patch) I wonder if that's even feasible as long as we don't have
> memremap() or alike.
> ---
> v2: Use conditional operator in ioremap_attr()'s final return. Re-base and
>    leverage that to simplify ioremap_attr() itself.
> 
> --- a/xen/arch/arm/include/asm/io.h
> +++ b/xen/arch/arm/include/asm/io.h
> @@ -1,6 +1,8 @@
> #ifndef _ASM_IO_H
> #define _ASM_IO_H
> 
> +#include <xen/mm-types.h>
> +
> #if defined(CONFIG_ARM_32)
> # include <asm/arm32/io.h>
> #elif defined(CONFIG_ARM_64)
> @@ -9,6 +11,16 @@
> # error "unknown ARM variant"
> #endif
> 
> +#ifdef CONFIG_MPU
> +void __iomem *mpu_ioremap_attr(paddr_t start, size_t len, pte_attr_t flags);
> +#define arch_ioremap_attr mpu_ioremap_attr
> +#else
> +/*
> + * ioremap_attr() should only be used to remap device address ranges.
> + * TODO: Add an arch hook to verify this assumption.
> + */
> +#endif

I find a bit strange to have an #else with only a comment, but to be fair I’m not sure where this
comment can be put otherwise.

For the Arm and common part, I’ve also tested on Arm64 MMU, Arm32 MMU, Arm64 MPU on virtual platforms:

Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> # arm, common
Tested-by: Luca Fancellu <luca.fancellu@arm.com> # arm, common

Cheers,
Luca


  reply	other threads:[~2026-04-09  7:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08 12:05 [PATCH v2] ioremap() et al Jan Beulich
2026-04-08 12:07 ` [PATCH v2 1/2] make ioremap_attr() common Jan Beulich
2026-04-09  7:26   ` Luca Fancellu [this message]
2026-04-09  7:54     ` Jan Beulich
2026-04-09  7:52   ` Roger Pau Monné
2026-04-09  7:58     ` Jan Beulich
2026-04-09  8:36   ` Oleksii Kurochko
2026-04-08 12:09 ` [PATCH v2 2/2] make ioremap_wc() x86 only (for the time being) Jan Beulich
2026-04-09  7:57   ` Luca Fancellu
     [not found]   ` <4291DA48-87D9-491B-83C6-51CCACC0FFE7@arm.com>
2026-04-09  8:01     ` Jan Beulich

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=DF8F0F78-1DBA-41B9-8055-4CD3622F6929@arm.com \
    --to=luca.fancellu@arm.com \
    --cc=Bertrand.Marquis@arm.com \
    --cc=alistair.francis@wdc.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=connojdavis@gmail.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=oleksii.kurochko@gmail.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=volodymyr_babchuk@epam.com \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.