Re: Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table

[Julien Grall <julien.grall@arm.com>]

Hi,

On 16/12/2016 15:49, Julien Grall wrote:
> On 14/12/16 08:00, Jiandi An wrote:
>> Xen currently doesn't map ECAM space specified in static ACPI table.
>> Seeking opinion on how this should be handled properly.
>> Each root complex ECAM region takes up 64K 4K pages (256MB).
>> For some platforms there might be multiple root complexes.
>> Is the plan to map all at once?Julien has mentioned support
>> for mapping ECAM may come when support for PCI passthrough is
>> added, is that right? What mechanism will it be? Will Xen or
>> dom0 be the one that parses the staic ACPI tables and map the ECAM space?
>
> For performance reason, each ECAM region would need to be mapped at
> once, so the stage-2 page table could take advantage of superpage (it
> will mostly be 2MB).
>
> Now, I don't think Xen should map the ECAM region in stage-2 before
> hand. All the regions may not be described in the MCFG and I would like
> to see a generic solution.
>
> Looking at the code (see pci_create_ecam_create in drivers/pci/ecam.c),
> ioremap is used. I believe the problem is the same for the 2 other
> threads you sent ( [1] and [2]).
>
> So it might be good to look at hooking up a call to
> XENMEM_add_to_physmap_range in ioremap.
>
> Any opinions?

I thought a bit more about it and I realized we need to be cautious on 
how to proceed here.

DOM0 will have a mix of real devices and emulated devices (e.g some part 
of the GIC). For the emulated devices, DOM0 should not call 
XENMEM_add_to_physmap_range. However, DOM0 is not aware what is emulated 
or not, so even the current approach (hooking up in platform device) 
seems fragile. We rely on Xen to say "this region cannot be mapped".

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel