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? > Cheers, > Thank you, Oleksandr
