Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 30/01/17 07:41, Manish Jaggi wrote:
> Hello Julien,
>
> On 01/25/2017 08:55 PM, Julien Grall wrote:
> > Hello Manish,
> >
> > On 25/01/17 04:37, Manish Jaggi wrote:
> > > On 01/24/2017 11:13 PM, Julien Grall wrote:
> > > > On 19/01/17 05:09, Manish Jaggi wrote:
> > > > > I think, PCI passthrough and DOM0 w/ACPI enumerating devices on PCI are 
> > > > > separate features.
> > > > > Without Xen mapping PCI config space region in stage2 of dom0, ACPI dom0 wont 
> > > > > boot.
> > > > > Currently for dt xen does that.
> > > > >
> > > > > So can we have 2 design documents
> > > > > a) PCI passthrough
> > > > > b) ACPI dom0/domU support in Xen and Linux
> > > > > - this may include:
> > > > > b.1 Passing IORT to Dom0 without smmu
> > > > > b.2 Hypercall to map PCI config space in dom0
> > > > > b.3 <more>
> > > > >
> > > > > What do you think?
> > > > I don't think ACPI should be treated in a separate design document.
> > > As PCI passthrough support will take time to mature, why should we hold the 
> > > ACPI design ?
> > > If I can boot dom0/domU with ACPI as it works with dt today, it would be a good 
> > > milestone.
> > The way PCI is working on DT today is a hack.
> Can you please elaborate why it is a hack ?
I think I gave enough explanation in my previous e-mail to why I 
consider it as a hack.
> > There is no SMMU support
> SMMU support can be turned on and off by iommu=0 and also by not having an smmu 
> node in device tree.
> So not having an smmu support for dom0 is not a hack IMHO.
> domUs can continue with PV devices
>
> And if you term without smmu as a hack, if I may suggest lets use this as a 
> phase 0 for ACPI.
>
> > and the first version of GICv3 ITS support will contain hardcoded DeviceID (or 
> > very similar).
> I have a disagreement on this, why should it contain hardcoded device ID, what 
> prevents it today technically?
As you may know, PCI devices are not described in the firmware tables 
and discoverable via the host bridges. We don't have this support in Xen 
today.
You may argue can we could use the existing physdev hypercalls. However 
they are not enough to find the DeviceID associated to a specific 
devices. Indeed we are not able to find the host bridge DT node in order 
to translate the RID.
> Can you please elaborate.
> If you are ok to have a first limited version of GICV3 ITS why not have a 
> Phase0 for ACPI?
See my answer below.

> > The current hack will introduce problem on platform where a specific host 
> > controller is necessary to access the configuration space.
> The specific host controller can be accessed by dom0 with Xen mapping stage2, 
> then we dont need a driver? right?
> Can you please elaborate on the problem?
> > Indeed, at the beginning Xen may not have a driver available (this
> > will depend on the contribution), but we still need to be able to use PCI with 
> > Xen.
> ACPI dom0 boot can and should be done without smmu support.
>
> > We chose this way on DT because we didn't know when the PCI passthrough will be 
> > added in Xen.
> not a technical argument.
That's not a helpful comment... Some arguments are not necessarily 
technical but also based on a forward plan and bandwidth review.
What you are arguing is for is whether PCI support for ACPI should land 
in Xen two weeks earlier or not. We both want to get PCI support with 
ACPI as soon as possible in Xen, but for an open source perspective, 
there is little point to have a phase 0 for ACPI as it will likely land 
in the same release.
One way to get things going faster is providing reviews.

> > As mentioned in the introduction of the design document, I envision PCI 
> > passthrough implementation in 2 phases:
> >     - Phase 1: Register all PCI devices in Xen => will allow to use ITS and 
> > SMMU with PCI in Xen
> >     - Phase 2: Assign devices to guests
> I think 3 phases, Lets add phase 0.
> - Phase 0: Dom0 ACPI without SMMU, DomU with PV devices, ITS in Xen
>
> > This design document will cover both phases because they are tight together. 
> > But the implementation can be decoupled, it would be possible (and also my 
> > plan) to see the 2 phases upstreamed in
> > different Xen release.
> >
> > Phase 1, will cover anything necessary for Xen to discover and register PCI 
> > devices. This include the ACPI support (IORT,...).
> >
> > I see little point to have a temporary solution for ACPI that will require 
> > bandwidth review. It would be better to put this bandwidth focusing on getting 
> > a good design document.
> I disagree, it is not a temporary solution. There are several use cases where 
> PCI pass-through is not required but ACPI is.
Sometimes I am wondering if you read what I wrote. The phase 1: 
"Discovering PCI" is exactly what you are looking for.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel