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

[Julien Grall <julien@xxxxxxx>]

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