public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: alex.williamson@redhat.com (Alex Williamson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] add initial kvm dev passhtrough support
Date: Tue, 11 Jun 2013 08:52:06 -0600	[thread overview]
Message-ID: <1370962326.6598.10.camel@ul30vt.home> (raw)
In-Reply-To: <51B73095.3070408@huawei.com>

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

  reply	other threads:[~2013-06-11 14:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-11  7:43 [PATCH 2/2] add initial kvm dev passhtrough support Mario Smarduch
2013-06-11  8:28 ` Alexander Graf
2013-06-11 14:13   ` Mario Smarduch
2013-06-11 14:52     ` Alex Williamson [this message]
2013-06-11 15:28       ` Mario Smarduch
     [not found] ` <CAG8rG2zzasO--3y2HsKXBUpof6DXqNkvqxN1VZGQR4Q8f=iuUw@mail.gmail.com>
     [not found]   ` <2DDB038789B01B4B80B0D3F1FF7CBDC2214E9024@lhreml509-mbb.china.huawei.com>
2013-06-12  6:56     ` Mario Smarduch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1370962326.6598.10.camel@ul30vt.home \
    --to=alex.williamson@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox