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@lists.xen.org
https://lists.xen.org/xen-devel