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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
