On 29/12/2016 14:16, Jaggi, Manish wrote:
> Hi Julien,
Hello Manish,
>
> Wouldnt it be better if the design proposed by cavium be extended by
> discussions and comeup with an agreeable to all design.
As I mentioned in my mail, this design is a completely different
approach (emulation vs PV).
[manish] It would have been better if you had suggested in the design posted by me, that the following 1.2.3 points would change.
Since a design is already been posted, it makes sense to focus on that and reach a common understanding. And is a bit _rude_.
This is a distinct proposal because
emulation vs PV impact a lot the overall design.
[manish] There are 3 aspects
a. changes needed in Xen / Dom0 for
- registering of pci host controller driver in xen
- mapping between sdbf and streamid
- adding enumerated pci devices to xen dom0
- making devices use SMMU in dom0
b.1 How domU is assigned a PCI device.
b.2 How a domU PCI driver reads configuration space
I think only at this point PV vs emulation matters. As of now the frontend backend driver allow reading PCI space.
Adding an its node in domU device tree will make traps to xen for ITS emulation.
c. DT vs ACPI
I havent seen in your design how it is captured to support both dt and acpi together.
A good appraoch would be to extend Draft5 with ACPI.
> I didnt see any comments on the one I posted.
Whilst I haven't commented on your design document, I have read
carefully your last version of the design. But even after 5 version and
nearly 2 years of work this is still DT and ITS focused.
[manish] Two reasons for that
a) PCI driver in linux was evolving and only after msi-map we have a way to map sbdf with steamID
b) Market interest in Xen ARM64
No words about
interrupt legacy,
[Manish] At the time of Xen dev summit 2015 we agreed to keep legacy as a secondary item, so that we can get something in xen for PCI pt.
no words about ACPI... And as you can see in this
draft, ACPI will have an impact on the overall.
Some part of this design document is based on all the discussion we had
over last year on your design. However, most of the comments have not
been addressed despite the fact they have been repeated multiple time by
various reviewers. For example the bus number has not been added
PHYSDEVOP_pci_host_bridge_add as requested in one of the first version
of the design.
[manish] I disagree, since the same pci node is passed to dom0 and xen and it has a bus-nr property
there is no need for it.
Moreover this hypercall was suggested by Ian and the requirement was to only add segno so that xen and dom0 bind to a PCI RC.
> Putting an altogether new design without commenting on the one posted a
> month back, might not be a right approach
Speaking for myself, my bandwidth is limited and I am going to
prioritize review on series where my comments have been addressed.
[manish] All have limited bandwidth and priorities are loaded. Your comments are dully taken care of in the document, espcially sbdf-streamID mapping.
I would have appreciated that you could have sent a draft 6 with your additions so that a good design be produced.
Regards,
--
Julien Grall
