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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 10.09.2024 10:15, Juergen Gross wrote:
> 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.

Oh, sure.

> Depending on how Xen tools will handle a PV-domain with "e820_host=1" this
> code might be important for domUs, too.

Right, if that's a possibility for PV (I thought that was a HVM-only thing,
yet maybe it really is precisely the other way around), then yes, DomU-s
may too need to cope with unexpected overlaps.

Jan