[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 16:01, Oleksandr Andrushchenko wrote:

On 10.09.21 17:52, Julien Grall wrote:


On 10/09/2021 15:38, Oleksandr Andrushchenko wrote:
[snip]


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
default.

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

Because nothing in this series indicates either way. So I assumed this should 
be owned by Xen because it will drive it.

  From what you wrote below, it sounds like this is not the case. I think you 
want to have a design document sent along the series so we can easily know what's 
the expected design and validate that the code match the agreement.

There was already a design document sent a few months ago. So you may want to 
refresh it (if needed) and send it again with this series.

Please see [1] which is the design document we use to implement PCI passthrough 
on Arm.

Thank. Can you make sure to include at least in a link in your cover letter 
next time?
I will update the commit message to have more description on the design aspects


For your convenience:

"

# Problem statement:
[snip]

Only Dom0 and Xen will have access to the real PCI bus,​ guest will have a
direct access to the assigned device itself​. IOMEM memory will be mapped to
the guest ​and interrupt will be redirected to the guest. SMMU has to be
configured correctly to have DMA transaction."

"

# Discovering PCI Host Bridge in XEN:

In order to support the PCI passthrough XEN should be aware of all the PCI host
bridges available on the system and should be able to access the PCI
configuration space. ECAM configuration access is supported as of now. XEN
during boot will read the PCI device tree node “reg” property and will map the
ECAM space to the XEN memory using the “ioremap_nocache ()” function.

[snip]

When Dom0 tries to access the PCI config space of the device, XEN will find the
corresponding host bridge based on segment number and access the corresponding
config space assigned to that bridge.

Limitation:
* Only PCI ECAM configuration space access is supported.
* Device tree binding is supported as of now, ACPI is not supported.
* Need to port the PCI host bridge access code to XEN to access the
configuration space (generic one works but lots of platforms will required
some specific code or quirks).

"

Unfortunately the document had not been updated since then, but the question

being discussed has not changed in the design: Domain-0 has full access to the 
bridge,

Xen traps ECAM. (I am taking dom0less aside as that was not the target for the 
first phase)

Having an update design document is quite important. This will allow reviewer 
to comment easily on overall approach and speed up the review as we can match 
to the agreed approach.

So can this please be updated and sent along the work?

In addition to that, it feels to me that the commit message should contain a 
summary of what you just pasted as this helps understanding the goal and 
approach of this patch.

If we are on the same page now will you be able to review the patch

with respect to the design from RFC?

I believe this was already done as I covered both side in my review.

Cheers,

--
Julien Grall



 


Rackspace

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