On Mon, Jun 24, 2013 at 3:01 PM, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > 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. Also, as we architect that generic infrastructure we need to keep in mind that there are important use cases for doing I/O in user space that are not KVM guests-- just normal applications that need direct device access. Stuart -- 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
