On Wed, 2014-11-12 at 10:14 +0100, Paolo Bonzini wrote: > > On 12/11/2014 04:42, Zhang, Yang Z wrote: > > Personally, I think this feature will be helpful to the legacy device > > assignment. Agree, vfio is the right solution for future feature > > enabling. But the old kvm without the good vfio supporting is still > > used largely today. The user really looking for this feature but they > > will not upgrade their kernel. It's easy for us to backport this > > feature to old kvm with the legacy device assignment, but it is > > impossible to backport the whole vfio. > > You can certainly backport these patches to distros that do not have > VFIO. But upstream we should work on VFIO first. VFIO has feature > parity with legacy device assignment, and adding a new feature that is > not in VFIO would be a bad idea.
Thanks Paolo, I agree. We should design the interfaces for VFIO since we expect legacy KVM assignment to be deprecated and eventually removed. I think that some of the platform device work for ARM's IRQ forwarding should probably be leveraged for this interface. IRQ forwarding effectively allows level triggered interrupts to be handled as edge, eliminating the mask/unmask overhead and EOI path entirely. To do this through VFIO they make use of the KVM-VFIO device to register the device and set attributes for the forwarded IRQ. This enables KVM to use the VFIO external user interfaces to acquire a VFIO device reference and access the struct device. From there it can do some IRQ manipulation on the device to reconfigure how the host handles the interrupt. Ideally we could use the same base KVM-VFIO device interface interface, perhaps with different attributes, and obviously with different architecture backing. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
