[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 10/11] xen/arm: Do not map PCI ECAM space to Domain-0's p2m

Hi Oleksandr,

On 10/09/2021 15:01, Oleksandr Andrushchenko wrote:

On 10.09.21 16:18, Julien Grall wrote:

On 10/09/2021 13:37, Oleksandr Andrushchenko wrote:
Hi, Julien!

Hi Oleksandr,

On 09.09.21 20:58, Julien Grall wrote:
On 03/09/2021 09:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>

Host bridge controller's ECAM space is mapped into Domain-0's p2m,
thus it is not possible to trap the same for vPCI via MMIO handlers.
For this to work we need to not map those while constructing the domain.

Note, that during Domain-0 creation there is no pci_dev yet allocated for
host bridges, thus we cannot match PCI host and its associated
bridge by SBDF. Use dt_device_node field for checks instead.

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
    xen/arch/arm/domain_build.c        |  3 +++
    xen/arch/arm/pci/ecam.c            | 17 +++++++++++++++++
    xen/arch/arm/pci/pci-host-common.c | 22 ++++++++++++++++++++++
    xen/include/asm-arm/pci.h          | 12 ++++++++++++
    4 files changed, 54 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index da427f399711..76f5b513280c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1257,6 +1257,9 @@ static int __init map_range_to_domain(const struct 
dt_device_node *dev,
    +    if ( need_mapping && (device_get_class(dev) == DEVICE_PCI) ) > 
+        need_mapping = pci_host_bridge_need_p2m_mapping(d, dev,
addr, len);

AFAICT, with device_get_class(dev), you know whether the hostbridge is used by 
Xen. Therefore, I would expect that we don't want to map all the regions of the 
hostbridges in dom0 (including the BARs).

Can you clarify it?
We only want to trap ECAM, not MMIOs and any other memory regions as the bridge 

initialized and used by Domain-0 completely.

What do you mean by "used by Domain-0 completely"? The hostbridge is owned by 
Xen so I don't think we can let dom0 access any MMIO regions by

Now it's my time to ask why do you think Xen owns the bridge?

All the bridges are passed to Domain-0, are fully visible to Domain-0, 
initialized in Domain-0.

Enumeration etc. is done in Domain-0. So how comes that Xen owns the bridge? In 
what way it does?

Xen just accesses the ECAM when it needs it, but that's it. Xen traps ECAM 
access - that is true.

But it in no way uses MMIOs etc. of the bridge - those under direct control of 

So I looked on the snipped of the design document you posted. I think you are instead referring to a different part:

" PCI-PCIe enumeration is a process of detecting devices connected to its host. It is the responsibility of the hardware domain or boot firmware to do the PCI enumeration and configure the BAR, PCI capabilities, and MSI/MSI-X configuration."

But I still don't see why it means we have to map the MMIOs right now. Dom0 should not need to access the MMIOs (aside the hostbridge registers) until the BARs are configured.

You can do the mapping when the BAR is accessed. In fact, AFAICT, there are code to do the identity mapping in the vPCI. So to me, the mappings for the MMIOs are rather pointless if not confusing.

In particular, we may want to hide a device from dom0 for security reasons. 
This is not going to be possible if you map by default everything to dom0.

Then the bridge most probably will become unusable as we do not have relevant 
drivers in Xen.

At best we may rely on the firmware doing the initialization for us, then yes, 
we can control an ECAM bridge in Xen.

But this is not the case now: we rely on Domain-0 to initialize and setup the 

Instead, the BARs should be mapped on demand when dom0 when we trap access to 
the configuration space.

For other regions, could you provide an example of what you are referring too?
Registers of the bridge for example, all what is listed in "reg" property

I was more after a real life example.


Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.