On 20.08.24 11:56, Jan Beulich wrote:
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)?
Yes.
+ 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.
I'd rather make this conditional on CONFIG_ACPI. Depending on how Xen tools will handle a PV-domain with "e820_host=1" this code might be important for domUs, too. Juergen
Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature