> -----Original Message----- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: Monday, September 07, 2015 1:05 PM > To: David Daney > Cc: Marc Zyngier; tirumalesh.chalama...@caviumnetworks.com; Richter, Robert; > Chintakuntla, Radha; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > io...@lists.linux-foundation.org; linux-arm- > ker...@lists.infradead.org; Will Deacon; Robin Murphy; Lorenzo Pieralisi; > a...@arndb.de; tred...@nvidia.com; > majun...@huawei.com; thunder.leiz...@huawei.com; > laurent.pinch...@ideasonboard.com; Yoder Stuart-B08248 > Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings > > On Fri, Sep 04, 2015 at 11:33:35PM +0100, David Daney wrote: > > Hi Mark, > > Hi David, > > > I now have a prototype implementation for irq-gic-v3-its.c that is using > > this binding on Cavium's ThunderX platform. > > > > Q: Have you guys had any more thoughts on this that might require > > changing the binding? > > Having discussed this with Stuart and others at Linux Plumbers, I think > that the binding is sufficient, and unlikely to change greatly unless > there is a strong objection (Stuart, please correct me if I am wrong). > > Per Marc's comments there are probably some edge cases and/or wording > details to sort out, but I think the common/simple case is sorted. I'll > send a v2 once those have been settled.
I think the binding as-is, is sufficient for the static description of RID to SID. I think the binding can be extended in a backwards compatible way to support dynamic RID->SID mappings if we need that in the future. The case that we (Freescale) are concerned with are where someone plugs an SRIOV card into an SoC and enables, say 64 VFs. It's like hot-plugging 64 new PCI devices at once. If all those devices that show up belong to the host they belong to one 'isolation context' and could share the same streamID, same SMMU mappings, and the same ITT in the GIC ITS. So a static mapping could work. But, as soon as I want to assign VF#5 to a virtual machine I need a new RID->SID mapping for VF#5. To require firmware to do that mapping ahead of time is a _real_ pain. I think longer term we need some mechanism to allow lazy, dynamic RID->SID mappings by Linux. We can start with the static approach, but we need to keep in the back of our minds that there may be cases in the near future where a static mapping is too inflexible. Thanks, Stuart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
