[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6bed58f8-016f-4390-be4c-128eebff6545@suse.com>
Date: Tue, 10 Sep 2024 14:34:58 +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 v3 6/7] xen: allow mapping ACPI data using a different
physical address
On 10.09.2024 12:39, Juergen Gross wrote:
> When running as a Xen PV dom0 the system needs to map ACPI data of the
> host using host physical addresses, while those addresses can conflict
> with the guest physical addresses of the loaded linux kernel. The same
> problem might apply in case a PV guest is configured to use the host
> memory map.
>
> This conflict can be solved by mapping the ACPI data to a different
> guest physical address, but mapping the data via acpi_os_ioremap()
> must still be possible using the host physical address, as this
> address might be generated by AML when referencing some of the ACPI
> data.
>
> When configured to support running as a Xen PV domain, have an
> implementation of acpi_os_ioremap() being aware of the possibility to
> need above mentioned translation of a host physical address to the
> guest physical address.
>
> This modification requires to fix some #include of asm/acpi.h in x86
> code to use linux/acpi.h instead.
>
> Signed-off-by: Juergen Gross <jgross@...e.com>
Reviewed-by: Jan Beulich <jbeulich@...e.com>
with a request to comment a tiny bit more:
> @@ -836,6 +837,33 @@ void __init xen_do_remap_nonram(void)
> pr_info("Remapped %u non-RAM page(s)\n", remapped);
> }
>
> +#ifdef CONFIG_ACPI
> +/*
> + * Xen variant of acpi_os_ioremap() taking potentially remapped non-RAM
> + * regions into acount.
(Nit: account)
> + * 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;
> + const struct nonram_remap *remap = xen_nonram_remap;
> +
> + 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;
This might be slightly easier / more logical to read as
phys += remap->paddr - remap->maddr;
Also because of "phys" not consistently expressing a physical address
(when you need convert it, the incoming value is a machine address) a
comment may help here. In fact at the first glance (and despite having
seen the code before) I thought the translation was done the wrong way
round, simply because of the name of the variable.
Jan
Powered by blists - more mailing lists