[PATCH 2/2] add initial kvm dev passhtrough support
mario.smarduch at huawei.com
Tue Jun 11 11:28:24 EDT 2013
I know Antonios very well. Yes our intent is definitely to use VFIO.
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.
More information about the linux-arm-kernel