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?
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.
Cheers,
--
Julien Grall
