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




[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