Re: [PATCH 2/2] armv7 initial device passthrough support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 24, 2013 at 10:08:08AM +0200, Mario Smarduch wrote:
> 
> 
> On 6/15/2013 5:47 PM, Paolo Bonzini wrote:
> > Il 13/06/2013 11:19, Mario Smarduch ha scritto:
> >> Updated Device Passthrough Patch.
> >> - optimized IRQ->CPU->vCPU binding, irq is installed once
> >> - added dynamic IRQ affinity on schedule in
> >> - added documentation and few other coding recommendations.
> >>
> >> Per earlier discussion VFIO is our target but we like
> >> something earlier to work with to tackle performance
> >> latency issue (some ARM related) for device passthrough 
> >> while we migrate towards VFIO.
> > 
> > I don't think this is acceptable upstream, unfortunately.  KVM device
> > assignment is deprecated and we should not add more users.
> That's fine we'll work our way towards dev-tree VFIO reusing what we can
> working with the community.
> 
> At this point we're more concerned with numbers and best practices as 
> opposed to mechanism this part will be time consuming. 
> VFIO will be more background for us.
> 
> > 
> > What are the latency issues you have?
> 
> Our focus now is on IRQ latency and throughput. Right now it appears lowest latency
> is 2x + exit/enter + IRQ injection overhead. We can't tolerate additional 
> IPIs or deferred IRQ injection approaches. We're looking for numbers closer
> to what IBMs ELI managed. Also high res timers which ARM Virt. Ext supports 
> very well. Exitless interrupts which ARM handles very well too. There are
> some future hw ARM interrupt enhancements coming up which may help a lot as well.
> 
> There are many other latency/perf. reqs for NFV related to RT,
> essentially Guest must run near native. In the end it may turn out this
> may need to be outside of main tree we'll see.
> 
It doesn't sound like this will be the end result.  Everything that you
try to do in your patch set can be accomplished using VFIO and a more
generic infrastructure for virtual IRQ integration with KVM and user
space.

We should avoid creating an environment with important functionality
outside of the main tree, if at all possible.

-Christoffer
--
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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux