On Tue, 2013-06-11 at 16:13 +0200, Mario Smarduch wrote: > On 6/11/2013 10:28 AM, Alexander Graf wrote: > > > > > Is there any particular reason you're not going down that path for your ARM implementation? > > We see this as a good starting point to build on, we need baseline numbers > for performance, latency, interrupt throughput on real hardware > ASAP to build competency for NFV, which has demanding Dev. Passthrough > requirements. Over time we plan contributing to SMMU and VFIO as well > (we're looking into this now). > > FYI NFV is an initiative wireless/fixed network operators are working > towards - to virtualize Core, likely Radia Access and even Home Network > equipment, this is a epic undertaking (i.e. Network Function Virtualization). > So far VMware has taken the lead (mostly x86). > > > > > On the embedded PPC side we've been discussing vfio and how it fits into a device tree, non-PCI world for a while. If you like, we can dive into more detail on that, either via email or via phone. > > I'll email you offline, I'd like to know more what you've done on this > and see where we can align/leverage the effort. Yes, please let's use VFIO rather than continue to use or invent new device assignment interfaces for KVM. Antonios Motakis (cc'd) already contacted me about VFIO for ARM. IIRC, his initial impression was that the IOMMU backend was almost entirely reusable for ARM (a couple PCI assumptions implicit in the IOMMU API to handle) and my hope was that ARM and PPC could work together on a common VFIO device tree backend. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
