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