Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding

[Eric Auger]

Hi Alex, all,
On 06/12/2015 09:03 PM, Alex Williamson wrote:
> On Fri, 2015-06-12 at 21:48 +0300, Avi Kivity wrote:
>> On 06/12/2015 06:41 PM, Alex Williamson wrote:
>>> On Fri, 2015-06-12 at 00:23 +0000, Wu, Feng wrote:
>>>>> -----Original Message-----
>>>>> From: Avi Kivity [mailto:avi.kivity@xxxxxxxxx]
>>>>> Sent: Friday, June 12, 2015 3:59 AM
>>>>> To: Wu, Feng; kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
>>>>> Cc: pbonzini@xxxxxxxxxx; mtosatti@xxxxxxxxxx;
>>>>> alex.williamson@xxxxxxxxxx; eric.auger@xxxxxxxxxx
>>>>> Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding
>>>>>
>>>>> On 06/11/2015 01:51 PM, Feng Wu wrote:
>>>>>> From: Eric Auger <eric.auger@xxxxxxxxxx>
>>>>>>
>>>>>> This patch adds and documents a new KVM_DEV_VFIO_DEVICE group
>>>>>> and 2 device attributes: KVM_DEV_VFIO_DEVICE_FORWARD_IRQ,
>>>>>> KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ. The purpose is to be able
>>>>>> to set a VFIO device IRQ as forwarded or not forwarded.
>>>>>> the command takes as argument a handle to a new struct named
>>>>>> kvm_vfio_dev_irq.
>>>>> Is there no way to do this automatically?  After all, vfio knows that a
>>>>> device interrupt is forwarded to some eventfd, and kvm knows that some
>>>>> eventfd is forwarded to a guest interrupt.  If they compare notes
>>>>> through a central registry, they can figure out that the interrupt needs
>>>>> to be forwarded.
>>>> Oh, just like Eric mentioned in his reply, this description is out of context of
>>>> this series, I will remove them in the next version.
>>>
>>> I suspect Avi's question was more general.  While forward/unforward is
>>> out of context for this series, it's very similar in nature to
>>> enabling/disabling posted interrupts.  So I think the question remains
>>> whether we really need userspace to participate in creating this
>>> shortcut or if kvm and vfio can some how orchestrate figuring it out
>>> automatically.
>>>
>>> Personally I don't know how we could do it automatically.  We've always
>>> relied on userspace to independently setup vfio and kvm such that
>>> neither have any idea that the other is there and update each side
>>> independently when anything changes.  So it seems consistent to continue
>>> that here.  It doesn't seem like there's much to gain performance-wise
>>> either, updates should be a relatively rare event I'd expect.
>>>
>>> There's really no metadata associated with an eventfd, so "comparing
>>> notes" automatically might imply some central registration entity.  That
>>> immediately sounds like a much more complex solution, but maybe Avi has
>>> some ideas to manage it.  Thanks,
>>>
>>
>> The idea is to have a central registry maintained by a posted interrupts 
>> manager.  Both vfio and kvm pass the filp (along with extra information) 
>> to the posted interrupts manager, which, when it detects a filp match, 
>> tells each of them what to do.
>>
>> The advantages are:
>> - old userspace gains the optimization without change
>> - a userspace API is more expensive to maintain than internal kernel 
>> interfaces (CVEs, documentation, maintaining backwards compatibility)
>> - if you can do it without a new interface, this indicates that all the 
>> information in the new interface is redundant.  That means you have to 
>> check it for consistency with the existing information, so it's extra 
>> work (likely, it's exactly what the posted interrupt manager would be 
>> doing anyway).
> 
> Yep, those all sound like good things and I believe that's similar in
> design to the way we had originally discussed this interaction at
> LPC/KVM Forum several years ago.  I'd be in favor of that approach.

I guess this discussion also is relevant wrt "[RFC v6 00/16] KVM-VFIO
IRQ forward control" series? Or is that "central registry maintained by
a posted interrupts manager" something more specific to x86?

Thank you in advance

Best Regards

Eric

> Thanks,
> 
> Alex
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/