Hi Julien, ________________________________ From: Julien Grall <julien.gr...@linaro.org> Sent: Thursday, December 29, 2016 10:33 PM To: Jaggi, Manish; xen-devel; Stefano Stabellini Cc: Edgar Iglesias (edgar.igles...@xilinx.com); Steve Capper; Punit Agrawal; Wei Chen; Campbell Sean; Shanker Donthineni; Jiandi An; Roger Pau Monné; alistair.fran...@xilinx.com; Kapoor, Prasun; Nair, Jayachandran Subject: Re: [early RFC] ARM PCI Passthrough design document
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
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
