I know Antonios very well. Yes our intent is definitely to use VFIO. - Mario On 6/11/2013 4:52 PM, Alex Williamson wrote: > 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 > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
