linux-kernel - Re: [PATCH v2 6/7] xen: allow mapping ACPI data using a different physical address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <607602c3-5199-4326-8676-d28a8b42b4b5@suse.com>
Date: Tue, 20 Aug 2024 11:56:18 +0200
From: Jan Beulich <jbeulich@...e.com>
To: Juergen Gross <jgross@...e.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>, "Rafael J. Wysocki" <rafael@...nel.org>,
 Len Brown <lenb@...nel.org>, Boris Ostrovsky <boris.ostrovsky@...cle.com>,
 xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
 x86@...nel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v2 6/7] xen: allow mapping ACPI data using a different
 physical address

On 20.08.2024 10:20, Juergen Gross wrote:
> @@ -838,6 +839,31 @@ void __init xen_do_remap_nonram(void)
>  	pr_info("Remapped %u non-RAM page(s)\n", remapped);
>  }
>  
> +/*
> + * Xen variant of acpi_os_ioremap() taking potentially remapped non-RAM
> + * regions into acount.
> + * Any attempt to map an area crossing a remap boundary will produce a
> + * WARN() splat.
> + */
> +static void __iomem *xen_acpi_os_ioremap(acpi_physical_address phys,
> +					 acpi_size size)
> +{
> +	unsigned int i;
> +	struct nonram_remap *remap = xen_nonram_remap;

const (also in one of the functions in patch 5)?

> +	for (i = 0; i < nr_nonram_remap; i++) {
> +		if (phys + size > remap->maddr &&
> +		    phys < remap->maddr + remap->size) {
> +			WARN_ON(phys < remap->maddr ||
> +				phys + size > remap->maddr + remap->size);
> +			phys = remap->paddr + phys - remap->maddr;
> +			break;
> +		}
> +	}
> +
> +	return x86_acpi_os_ioremap(phys, size);
> +}

At least this, perhaps also what patch 5 adds, likely wants to be limited
to the XEN_DOM0 case? Or else I wonder whether ...

> @@ -850,6 +876,10 @@ void __init xen_add_remap_nonram(phys_addr_t maddr, phys_addr_t paddr,
>  		BUG();
>  	}
>  
> +	/* Switch to the Xen acpi_os_ioremap() variant. */
> +	if (nr_nonram_remap == 0)
> +		acpi_os_ioremap = xen_acpi_os_ioremap;

... this would actually build when XEN_DOM0=n.

I'm actually surprised there's no Dom0-only code section in this file,
where the new code could then simply be inserted.

Jan