Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1163136 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding Feng Wu <feng.wu@intel.com> - 2015-06-11 13:10 +0200
    RE: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding "Wu, Feng" <feng.wu@intel.com> - 2015-06-12 02:30 +0200
    RE: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding "Wu, Feng" <feng.wu@intel.com> - 2015-06-12 02:30 +0200
      RE: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding "Wu, Feng" <feng.wu@intel.com> - 2015-06-15 08:50 +0200
      Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding Alex Williamson <alex.williamson@redhat.com> - 2015-06-18 22:10 +0200

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

From: Eric Auger <eric.auger@linaro.org>

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.

Signed-off-by: Eric Auger <eric.auger@linaro.org>
---
 Documentation/virtual/kvm/devices/vfio.txt | 34 ++++++++++++++++++++++++------
 include/uapi/linux/kvm.h                   | 12 +++++++++++
 2 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/Documentation/virtual/kvm/devices/vfio.txt b/Documentation/virtual/kvm/devices/vfio.txt
index ef51740..6186e6d 100644
--- a/Documentation/virtual/kvm/devices/vfio.txt
+++ b/Documentation/virtual/kvm/devices/vfio.txt
@@ -4,15 +4,20 @@ VFIO virtual device
 Device types supported:
   KVM_DEV_TYPE_VFIO
 
-Only one VFIO instance may be created per VM.  The created device
-tracks VFIO groups in use by the VM and features of those groups
-important to the correctness and acceleration of the VM.  As groups
-are enabled and disabled for use by the VM, KVM should be updated
-about their presence.  When registered with KVM, a reference to the
-VFIO-group is held by KVM.
+Only one VFIO instance may be created per VM.
+
+The created device tracks VFIO groups in use by the VM and features
+of those groups important to the correctness and acceleration of
+the VM.  As groups are enabled and disabled for use by the VM, KVM
+should be updated about their presence.  When registered with KVM,
+a reference to the VFIO-group is held by KVM.
+
+The device also enables to control some IRQ settings of VFIO devices:
+forwarding/posting.
 
 Groups:
   KVM_DEV_VFIO_GROUP
+  KVM_DEV_VFIO_DEVICE
 
 KVM_DEV_VFIO_GROUP attributes:
   KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
@@ -20,3 +25,20 @@ KVM_DEV_VFIO_GROUP attributes:
 
 For each, kvm_device_attr.addr points to an int32_t file descriptor
 for the VFIO group.
+
+KVM_DEV_VFIO_DEVICE attributes:
+  KVM_DEV_VFIO_DEVICE_FORWARD_IRQ: set a VFIO device IRQ as forwarded
+  KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ: set a VFIO device IRQ as not forwarded
+
+For each, kvm_device_attr.addr points to a kvm_vfio_dev_irq struct.
+
+When forwarded, a physical IRQ is completed by the guest and not by the
+host. This requires HW support in the interrupt controller.
+
+Forwarding can only be set when the corresponding VFIO IRQ is not masked
+(would it be through VFIO_DEVICE_SET_IRQS command or as a consequence of this
+IRQ being currently handled) or active at interrupt controller level.
+In such a situation, -EAGAIN is returned. It is advised to to set the
+forwarding before the VFIO signaling is set up, this avoids trial and errors.
+
+Unforwarding can happen at any time.
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 4b60056..798f3e4 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -999,6 +999,9 @@ struct kvm_device_attr {
 #define  KVM_DEV_VFIO_GROUP			1
 #define   KVM_DEV_VFIO_GROUP_ADD			1
 #define   KVM_DEV_VFIO_GROUP_DEL			2
+#define  KVM_DEV_VFIO_DEVICE			2
+#define   KVM_DEV_VFIO_DEVICE_FORWARD_IRQ			1
+#define   KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ			2
 
 enum kvm_device_type {
 	KVM_DEV_TYPE_FSL_MPIC_20	= 1,
@@ -1018,6 +1021,15 @@ enum kvm_device_type {
 	KVM_DEV_TYPE_MAX,
 };
 
+struct kvm_vfio_dev_irq {
+	__u32	argsz;		/* structure length */
+	__u32	fd;		/* file descriptor of the VFIO device */
+	__u32	index;		/* VFIO device IRQ index */
+	__u32	start;		/* start of subindex range */
+	__u32	count;		/* size of subindex range */
+	__u32	gsi[];		/* gsi, ie. virtual IRQ number */
+};
+
 /*
  * ioctls for VM fds
  */
-- 
2.1.0

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

[toc] | [next] | [standalone]

#1163678

> -----Original Message-----
> From: Eric Auger [mailto:eric.auger@linaro.org]
> Sent: Thursday, June 11, 2015 9:38 PM
> To: Wu, Feng; kvm@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: pbonzini@redhat.com; mtosatti@redhat.com;
> alex.williamson@redhat.com
> Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding
> 
> Hi Feng,
> On 06/11/2015 12:51 PM, Feng Wu wrote:
> > From: Eric Auger <eric.auger@linaro.org>
> >
> > 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.
> >
> > Signed-off-by: Eric Auger <eric.auger@linaro.org>
> > ---
> >  Documentation/virtual/kvm/devices/vfio.txt | 34
> ++++++++++++++++++++++++------
> >  include/uapi/linux/kvm.h                   | 12 +++++++++++
> >  2 files changed, 40 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/virtual/kvm/devices/vfio.txt
> b/Documentation/virtual/kvm/devices/vfio.txt
> > index ef51740..6186e6d 100644
> > --- a/Documentation/virtual/kvm/devices/vfio.txt
> > +++ b/Documentation/virtual/kvm/devices/vfio.txt
> > @@ -4,15 +4,20 @@ VFIO virtual device
> >  Device types supported:
> >    KVM_DEV_TYPE_VFIO
> >
> > -Only one VFIO instance may be created per VM.  The created device
> > -tracks VFIO groups in use by the VM and features of those groups
> > -important to the correctness and acceleration of the VM.  As groups
> > -are enabled and disabled for use by the VM, KVM should be updated
> > -about their presence.  When registered with KVM, a reference to the
> > -VFIO-group is held by KVM.
> > +Only one VFIO instance may be created per VM.
> > +
> > +The created device tracks VFIO groups in use by the VM and features
> > +of those groups important to the correctness and acceleration of
> > +the VM.  As groups are enabled and disabled for use by the VM, KVM
> > +should be updated about their presence.  When registered with KVM,
> > +a reference to the VFIO-group is held by KVM.
> > +
> > +The device also enables to control some IRQ settings of VFIO devices:
> > +forwarding/posting.
> >
> >  Groups:
> >    KVM_DEV_VFIO_GROUP
> > +  KVM_DEV_VFIO_DEVICE
> >
> >  KVM_DEV_VFIO_GROUP attributes:
> >    KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device
> tracking
> > @@ -20,3 +25,20 @@ KVM_DEV_VFIO_GROUP attributes:
> >
> >  For each, kvm_device_attr.addr points to an int32_t file descriptor
> >  for the VFIO group.
> > +
> > +KVM_DEV_VFIO_DEVICE attributes:
> > +  KVM_DEV_VFIO_DEVICE_FORWARD_IRQ: set a VFIO device IRQ as
> forwarded
> > +  KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ: set a VFIO device IRQ as
> not forwarded
> > +
> > +For each, kvm_device_attr.addr points to a kvm_vfio_dev_irq struct.
> > +
> > +When forwarded, a physical IRQ is completed by the guest and not by the
> > +host. This requires HW support in the interrupt controller.
> > +
> > +Forwarding can only be set when the corresponding VFIO IRQ is not masked
> > +(would it be through VFIO_DEVICE_SET_IRQS command or as a consequence
> of this
> > +IRQ being currently handled) or active at interrupt controller level.
> > +In such a situation, -EAGAIN is returned. It is advised to to set the
> > +forwarding before the VFIO signaling is set up, this avoids trial and errors.
> > +
> > +Unforwarding can happen at any time.
> Unfortunately the above text is out of context of your series. If it
> simplifies things take the ownership of that patch file and remove my
> description of KVM_DEV_VFIO_DEVICE_FORWARD_IRQ.

Oh, I didn't notice that. It is a good suggestion, Eric!

Thanks,
Feng


> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index 4b60056..798f3e4 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -999,6 +999,9 @@ struct kvm_device_attr {
> >  #define  KVM_DEV_VFIO_GROUP			1
> >  #define   KVM_DEV_VFIO_GROUP_ADD			1
> >  #define   KVM_DEV_VFIO_GROUP_DEL			2
> > +#define  KVM_DEV_VFIO_DEVICE			2
> > +#define   KVM_DEV_VFIO_DEVICE_FORWARD_IRQ			1
> > +#define   KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ			2
> same here
> Best Regards
> 
> Eric
> >
> >  enum kvm_device_type {
> >  	KVM_DEV_TYPE_FSL_MPIC_20	= 1,
> > @@ -1018,6 +1021,15 @@ enum kvm_device_type {
> >  	KVM_DEV_TYPE_MAX,
> >  };
> >
> > +struct kvm_vfio_dev_irq {
> > +	__u32	argsz;		/* structure length */
> > +	__u32	fd;		/* file descriptor of the VFIO device */
> > +	__u32	index;		/* VFIO device IRQ index */
> > +	__u32	start;		/* start of subindex range */
> > +	__u32	count;		/* size of subindex range */
> > +	__u32	gsi[];		/* gsi, ie. virtual IRQ number */
> > +};
> > +
> >  /*
> >   * ioctls for VM fds
> >   */
> >

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

[toc] | [prev] | [next] | [standalone]

#1163679

> -----Original Message-----
> From: Avi Kivity [mailto:avi.kivity@gmail.com]
> Sent: Friday, June 12, 2015 3:59 AM
> To: Wu, Feng; kvm@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: pbonzini@redhat.com; mtosatti@redhat.com;
> alex.williamson@redhat.com; eric.auger@linaro.org
> 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@linaro.org>
> >
> > 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.

Thanks,
Feng

> 
> 
> > Signed-off-by: Eric Auger <eric.auger@linaro.org>
> > ---
> >   Documentation/virtual/kvm/devices/vfio.txt | 34
> ++++++++++++++++++++++++------
> >   include/uapi/linux/kvm.h                   | 12 +++++++++++
> >   2 files changed, 40 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/virtual/kvm/devices/vfio.txt
> b/Documentation/virtual/kvm/devices/vfio.txt
> > index ef51740..6186e6d 100644
> > --- a/Documentation/virtual/kvm/devices/vfio.txt
> > +++ b/Documentation/virtual/kvm/devices/vfio.txt
> > @@ -4,15 +4,20 @@ VFIO virtual device
> >   Device types supported:
> >     KVM_DEV_TYPE_VFIO
> >
> > -Only one VFIO instance may be created per VM.  The created device
> > -tracks VFIO groups in use by the VM and features of those groups
> > -important to the correctness and acceleration of the VM.  As groups
> > -are enabled and disabled for use by the VM, KVM should be updated
> > -about their presence.  When registered with KVM, a reference to the
> > -VFIO-group is held by KVM.
> > +Only one VFIO instance may be created per VM.
> > +
> > +The created device tracks VFIO groups in use by the VM and features
> > +of those groups important to the correctness and acceleration of
> > +the VM.  As groups are enabled and disabled for use by the VM, KVM
> > +should be updated about their presence.  When registered with KVM,
> > +a reference to the VFIO-group is held by KVM.
> > +
> > +The device also enables to control some IRQ settings of VFIO devices:
> > +forwarding/posting.
> >
> >   Groups:
> >     KVM_DEV_VFIO_GROUP
> > +  KVM_DEV_VFIO_DEVICE
> >
> >   KVM_DEV_VFIO_GROUP attributes:
> >     KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device
> tracking
> > @@ -20,3 +25,20 @@ KVM_DEV_VFIO_GROUP attributes:
> >
> >   For each, kvm_device_attr.addr points to an int32_t file descriptor
> >   for the VFIO group.
> > +
> > +KVM_DEV_VFIO_DEVICE attributes:
> > +  KVM_DEV_VFIO_DEVICE_FORWARD_IRQ: set a VFIO device IRQ as
> forwarded
> > +  KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ: set a VFIO device IRQ as
> not forwarded
> > +
> > +For each, kvm_device_attr.addr points to a kvm_vfio_dev_irq struct.
> > +
> > +When forwarded, a physical IRQ is completed by the guest and not by the
> > +host. This requires HW support in the interrupt controller.
> > +
> > +Forwarding can only be set when the corresponding VFIO IRQ is not masked
> > +(would it be through VFIO_DEVICE_SET_IRQS command or as a consequence
> of this
> > +IRQ being currently handled) or active at interrupt controller level.
> > +In such a situation, -EAGAIN is returned. It is advised to to set the
> > +forwarding before the VFIO signaling is set up, this avoids trial and errors.
> > +
> > +Unforwarding can happen at any time.
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index 4b60056..798f3e4 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -999,6 +999,9 @@ struct kvm_device_attr {
> >   #define  KVM_DEV_VFIO_GROUP			1
> >   #define   KVM_DEV_VFIO_GROUP_ADD			1
> >   #define   KVM_DEV_VFIO_GROUP_DEL			2
> > +#define  KVM_DEV_VFIO_DEVICE			2
> > +#define   KVM_DEV_VFIO_DEVICE_FORWARD_IRQ			1
> > +#define   KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ			2
> >
> >   enum kvm_device_type {
> >   	KVM_DEV_TYPE_FSL_MPIC_20	= 1,
> > @@ -1018,6 +1021,15 @@ enum kvm_device_type {
> >   	KVM_DEV_TYPE_MAX,
> >   };
> >
> > +struct kvm_vfio_dev_irq {
> > +	__u32	argsz;		/* structure length */
> > +	__u32	fd;		/* file descriptor of the VFIO device */
> > +	__u32	index;		/* VFIO device IRQ index */
> > +	__u32	start;		/* start of subindex range */
> > +	__u32	count;		/* size of subindex range */
> > +	__u32	gsi[];		/* gsi, ie. virtual IRQ number */
> > +};
> > +
> >   /*
> >    * ioctls for VM fds
> >    */

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

[toc] | [prev] | [next] | [standalone]

#1165049

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleCBXaWxsaWFtc29u
IFttYWlsdG86YWxleC53aWxsaWFtc29uQHJlZGhhdC5jb21dDQo+IFNlbnQ6IFNhdHVyZGF5LCBK
dW5lIDEzLCAyMDE1IDM6MDQgQU0NCj4gVG86IEF2aSBLaXZpdHkNCj4gQ2M6IFd1LCBGZW5nOyBr
dm1Admdlci5rZXJuZWwub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOw0KPiBwYm9u
emluaUByZWRoYXQuY29tOyBtdG9zYXR0aUByZWRoYXQuY29tOyBlcmljLmF1Z2VyQGxpbmFyby5v
cmcNCj4gU3ViamVjdDogUmU6IFt2NCAwOC8xNl0gS1ZNOiBrdm0tdmZpbzogVXNlciBBUEkgZm9y
IElSUSBmb3J3YXJkaW5nDQo+IA0KPiBPbiBGcmksIDIwMTUtMDYtMTIgYXQgMjE6NDggKzAzMDAs
IEF2aSBLaXZpdHkgd3JvdGU6DQo+ID4gT24gMDYvMTIvMjAxNSAwNjo0MSBQTSwgQWxleCBXaWxs
aWFtc29uIHdyb3RlOg0KPiA+ID4gT24gRnJpLCAyMDE1LTA2LTEyIGF0IDAwOjIzICswMDAwLCBX
dSwgRmVuZyB3cm90ZToNCj4gPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+
Pj4gRnJvbTogQXZpIEtpdml0eSBbbWFpbHRvOmF2aS5raXZpdHlAZ21haWwuY29tXQ0KPiA+ID4+
PiBTZW50OiBGcmlkYXksIEp1bmUgMTIsIDIwMTUgMzo1OSBBTQ0KPiA+ID4+PiBUbzogV3UsIEZl
bmc7IGt2bUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcNCj4g
PiA+Pj4gQ2M6IHBib256aW5pQHJlZGhhdC5jb207IG10b3NhdHRpQHJlZGhhdC5jb207DQo+ID4g
Pj4+IGFsZXgud2lsbGlhbXNvbkByZWRoYXQuY29tOyBlcmljLmF1Z2VyQGxpbmFyby5vcmcNCj4g
PiA+Pj4gU3ViamVjdDogUmU6IFt2NCAwOC8xNl0gS1ZNOiBrdm0tdmZpbzogVXNlciBBUEkgZm9y
IElSUSBmb3J3YXJkaW5nDQo+ID4gPj4+DQo+ID4gPj4+IE9uIDA2LzExLzIwMTUgMDE6NTEgUE0s
IEZlbmcgV3Ugd3JvdGU6DQo+ID4gPj4+PiBGcm9tOiBFcmljIEF1Z2VyIDxlcmljLmF1Z2VyQGxp
bmFyby5vcmc+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gVGhpcyBwYXRjaCBhZGRzIGFuZCBkb2N1bWVu
dHMgYSBuZXcgS1ZNX0RFVl9WRklPX0RFVklDRSBncm91cA0KPiA+ID4+Pj4gYW5kIDIgZGV2aWNl
IGF0dHJpYnV0ZXM6IEtWTV9ERVZfVkZJT19ERVZJQ0VfRk9SV0FSRF9JUlEsDQo+ID4gPj4+PiBL
Vk1fREVWX1ZGSU9fREVWSUNFX1VORk9SV0FSRF9JUlEuIFRoZSBwdXJwb3NlIGlzIHRvIGJlIGFi
bGUNCj4gPiA+Pj4+IHRvIHNldCBhIFZGSU8gZGV2aWNlIElSUSBhcyBmb3J3YXJkZWQgb3Igbm90
IGZvcndhcmRlZC4NCj4gPiA+Pj4+IHRoZSBjb21tYW5kIHRha2VzIGFzIGFyZ3VtZW50IGEgaGFu
ZGxlIHRvIGEgbmV3IHN0cnVjdCBuYW1lZA0KPiA+ID4+Pj4ga3ZtX3ZmaW9fZGV2X2lycS4NCj4g
PiA+Pj4gSXMgdGhlcmUgbm8gd2F5IHRvIGRvIHRoaXMgYXV0b21hdGljYWxseT8gIEFmdGVyIGFs
bCwgdmZpbyBrbm93cyB0aGF0IGENCj4gPiA+Pj4gZGV2aWNlIGludGVycnVwdCBpcyBmb3J3YXJk
ZWQgdG8gc29tZSBldmVudGZkLCBhbmQga3ZtIGtub3dzIHRoYXQgc29tZQ0KPiA+ID4+PiBldmVu
dGZkIGlzIGZvcndhcmRlZCB0byBhIGd1ZXN0IGludGVycnVwdC4gIElmIHRoZXkgY29tcGFyZSBu
b3Rlcw0KPiA+ID4+PiB0aHJvdWdoIGEgY2VudHJhbCByZWdpc3RyeSwgdGhleSBjYW4gZmlndXJl
IG91dCB0aGF0IHRoZSBpbnRlcnJ1cHQgbmVlZHMNCj4gPiA+Pj4gdG8gYmUgZm9yd2FyZGVkLg0K
PiA+ID4+IE9oLCBqdXN0IGxpa2UgRXJpYyBtZW50aW9uZWQgaW4gaGlzIHJlcGx5LCB0aGlzIGRl
c2NyaXB0aW9uIGlzIG91dCBvZiBjb250ZXh0IG9mDQo+ID4gPj4gdGhpcyBzZXJpZXMsIEkgd2ls
bCByZW1vdmUgdGhlbSBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KPiA+ID4NCj4gPiA+IEkgc3VzcGVj
dCBBdmkncyBxdWVzdGlvbiB3YXMgbW9yZSBnZW5lcmFsLiAgV2hpbGUgZm9yd2FyZC91bmZvcndh
cmQgaXMNCj4gPiA+IG91dCBvZiBjb250ZXh0IGZvciB0aGlzIHNlcmllcywgaXQncyB2ZXJ5IHNp
bWlsYXIgaW4gbmF0dXJlIHRvDQo+ID4gPiBlbmFibGluZy9kaXNhYmxpbmcgcG9zdGVkIGludGVy
cnVwdHMuICBTbyBJIHRoaW5rIHRoZSBxdWVzdGlvbiByZW1haW5zDQo+ID4gPiB3aGV0aGVyIHdl
IHJlYWxseSBuZWVkIHVzZXJzcGFjZSB0byBwYXJ0aWNpcGF0ZSBpbiBjcmVhdGluZyB0aGlzDQo+
ID4gPiBzaG9ydGN1dCBvciBpZiBrdm0gYW5kIHZmaW8gY2FuIHNvbWUgaG93IG9yY2hlc3RyYXRl
IGZpZ3VyaW5nIGl0IG91dA0KPiA+ID4gYXV0b21hdGljYWxseS4NCj4gPiA+DQo+ID4gPiBQZXJz
b25hbGx5IEkgZG9uJ3Qga25vdyBob3cgd2UgY291bGQgZG8gaXQgYXV0b21hdGljYWxseS4gIFdl
J3ZlIGFsd2F5cw0KPiA+ID4gcmVsaWVkIG9uIHVzZXJzcGFjZSB0byBpbmRlcGVuZGVudGx5IHNl
dHVwIHZmaW8gYW5kIGt2bSBzdWNoIHRoYXQNCj4gPiA+IG5laXRoZXIgaGF2ZSBhbnkgaWRlYSB0
aGF0IHRoZSBvdGhlciBpcyB0aGVyZSBhbmQgdXBkYXRlIGVhY2ggc2lkZQ0KPiA+ID4gaW5kZXBl
bmRlbnRseSB3aGVuIGFueXRoaW5nIGNoYW5nZXMuICBTbyBpdCBzZWVtcyBjb25zaXN0ZW50IHRv
IGNvbnRpbnVlDQo+ID4gPiB0aGF0IGhlcmUuICBJdCBkb2Vzbid0IHNlZW0gbGlrZSB0aGVyZSdz
IG11Y2ggdG8gZ2FpbiBwZXJmb3JtYW5jZS13aXNlDQo+ID4gPiBlaXRoZXIsIHVwZGF0ZXMgc2hv
dWxkIGJlIGEgcmVsYXRpdmVseSByYXJlIGV2ZW50IEknZCBleHBlY3QuDQo+ID4gPg0KPiA+ID4g
VGhlcmUncyByZWFsbHkgbm8gbWV0YWRhdGEgYXNzb2NpYXRlZCB3aXRoIGFuIGV2ZW50ZmQsIHNv
ICJjb21wYXJpbmcNCj4gPiA+IG5vdGVzIiBhdXRvbWF0aWNhbGx5IG1pZ2h0IGltcGx5IHNvbWUg
Y2VudHJhbCByZWdpc3RyYXRpb24gZW50aXR5LiAgVGhhdA0KPiA+ID4gaW1tZWRpYXRlbHkgc291
bmRzIGxpa2UgYSBtdWNoIG1vcmUgY29tcGxleCBzb2x1dGlvbiwgYnV0IG1heWJlIEF2aSBoYXMN
Cj4gPiA+IHNvbWUgaWRlYXMgdG8gbWFuYWdlIGl0LiAgVGhhbmtzLA0KPiA+ID4NCj4gPg0KPiA+
IFRoZSBpZGVhIGlzIHRvIGhhdmUgYSBjZW50cmFsIHJlZ2lzdHJ5IG1haW50YWluZWQgYnkgYSBw
b3N0ZWQgaW50ZXJydXB0cw0KPiA+IG1hbmFnZXIuICBCb3RoIHZmaW8gYW5kIGt2bSBwYXNzIHRo
ZSBmaWxwIChhbG9uZyB3aXRoIGV4dHJhIGluZm9ybWF0aW9uKQ0KPiA+IHRvIHRoZSBwb3N0ZWQg
aW50ZXJydXB0cyBtYW5hZ2VyLCB3aGljaCwgd2hlbiBpdCBkZXRlY3RzIGEgZmlscCBtYXRjaCwN
Cj4gPiB0ZWxscyBlYWNoIG9mIHRoZW0gd2hhdCB0byBkby4NCj4gPg0KPiA+IFRoZSBhZHZhbnRh
Z2VzIGFyZToNCj4gPiAtIG9sZCB1c2Vyc3BhY2UgZ2FpbnMgdGhlIG9wdGltaXphdGlvbiB3aXRo
b3V0IGNoYW5nZQ0KPiA+IC0gYSB1c2Vyc3BhY2UgQVBJIGlzIG1vcmUgZXhwZW5zaXZlIHRvIG1h
aW50YWluIHRoYW4gaW50ZXJuYWwga2VybmVsDQo+ID4gaW50ZXJmYWNlcyAoQ1ZFcywgZG9jdW1l
bnRhdGlvbiwgbWFpbnRhaW5pbmcgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkpDQo+ID4gLSBpZiB5
b3UgY2FuIGRvIGl0IHdpdGhvdXQgYSBuZXcgaW50ZXJmYWNlLCB0aGlzIGluZGljYXRlcyB0aGF0
IGFsbCB0aGUNCj4gPiBpbmZvcm1hdGlvbiBpbiB0aGUgbmV3IGludGVyZmFjZSBpcyByZWR1bmRh
bnQuICBUaGF0IG1lYW5zIHlvdSBoYXZlIHRvDQo+ID4gY2hlY2sgaXQgZm9yIGNvbnNpc3RlbmN5
IHdpdGggdGhlIGV4aXN0aW5nIGluZm9ybWF0aW9uLCBzbyBpdCdzIGV4dHJhDQo+ID4gd29yayAo
bGlrZWx5LCBpdCdzIGV4YWN0bHkgd2hhdCB0aGUgcG9zdGVkIGludGVycnVwdCBtYW5hZ2VyIHdv
dWxkIGJlDQo+ID4gZG9pbmcgYW55d2F5KS4NCj4gDQo+IFllcCwgdGhvc2UgYWxsIHNvdW5kIGxp
a2UgZ29vZCB0aGluZ3MgYW5kIEkgYmVsaWV2ZSB0aGF0J3Mgc2ltaWxhciBpbg0KPiBkZXNpZ24g
dG8gdGhlIHdheSB3ZSBoYWQgb3JpZ2luYWxseSBkaXNjdXNzZWQgdGhpcyBpbnRlcmFjdGlvbiBh
dA0KPiBMUEMvS1ZNIEZvcnVtIHNldmVyYWwgeWVhcnMgYWdvLiAgSSdkIGJlIGluIGZhdm9yIG9m
IHRoYXQgYXBwcm9hY2guDQo+IFRoYW5rcywNCg0KVGhpcyBzZWVtcyBhIGxpdHRsZSBjb21wbGV4
IGNvbXBhcmVkIHRvIHRoZSBjdXJyZW50IHNvbHV0aW9uLCBzaW5jZSBJIGFtDQpub3QgcXVpdGUg
ZmFtaWxpYXIgd2l0aCBWRklPLCBBbGV4LCBjYW4geW91IGhlbHAgb24gdGhpcyBpZiB3ZSBuZWVk
IHRvIGRvIHRoaXMNCnRoYXQgd2F5LCBlc3BlY2lhbGx5IGZvciB0aGUgVkZJTyBwYXJ0Pw0KDQpU
aGFua3MsDQpGZW5nDQoNCj4gDQo+IEFsZXgNCg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1168261

[Adding Joerg since he was part of this original idea]

On Thu, 2015-06-18 at 09:16 +0000, Wu, Feng wrote:
> 
> 
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Tuesday, June 16, 2015 12:45 AM
> > To: Eric Auger
> > Cc: Avi Kivity; Wu, Feng; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
> > pbonzini@redhat.com; mtosatti@redhat.com
> > Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding
> > 
> > On Mon, 2015-06-15 at 18:17 +0200, Eric Auger wrote:
> > > 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@gmail.com]
> > > >>>>> Sent: Friday, June 12, 2015 3:59 AM
> > > >>>>> To: Wu, Feng; kvm@vger.kernel.org; linux-kernel@vger.kernel.org
> > > >>>>> Cc: pbonzini@redhat.com; mtosatti@redhat.com;
> > > >>>>> alex.williamson@redhat.com; eric.auger@linaro.org
> > > >>>>> 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@linaro.org>
> > > >>>>>>
> > > >>>>>> 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?
> > 
> > I'd think we'd want it for any sort of offload and supporting both
> > posted-interrupts and irq-forwarding would be a good validation.  I
> > imagine there would be registration/de-registration callbacks separate
> > for interrupt producers vs interrupt consumers.  Each registration
> > function would likely provide a struct of callbacks, probably similar to
> > the get_symbol callbacks proposed for the kvm-vfio device on the IRQ
> > producer side.  The eventfd would be the token that the manager would
> > use to match producers and consumers.  The hard part is probably
> > figuring out what information to retrieve from the producer and provide
> > to the consumer in a generic way between pci and platform, but as an
> > internal interface, it's not a big deal if we screw it up a few times to
> > start.  Thanks,
> 
> On posted-interrupts side, the main purpose of the new APIs is to update
> the IRTE when guest changes vMSI/vMSIx configuration. Alex, do you have
> any detailed ideas for the new solution to achieve this purpose? It should
> be helpful if you can share some!


There are plenty of details to be filled in, but I think the basics
looks something like the code below.  The IRQ bypass manager just
defines a pair of structures, one for interrupt producers and one for
interrupt consumers.  I'm certain that we'll need more callbacks than
I've defined below, but figuring out what those should be for the best
abstraction is the hardest part of this idea.  The manager provides both
registration and de-registration interfaces for both types of objects
and keeps lists for each, protected by a lock.  The manager doesn't even
really need to know what the match token is, but I assume for our
purposes it will be an eventfd_ctx.

On the vfio side, the producer struct would be embedded in the
vfio_pci_irq_ctx struct.  KVM would probably embed the consumer struct
in _irqfd.  As I've coded below, the IRQ bypass manager calls the
consumer callbacks, so the producer struct would need fields or
callbacks to provide the consumer the info it needs.  AIUI the Posted
Interrupt model, VFIO only needs to provide data to the consumer.  For
IRQ Forwarding, I think the producer needs to be informed when bypass is
active to model the incoming interrupt as edge vs level.

I've prototyped the base IRQ bypass manager here as static, but I don't
see any reason it couldn't be a module that's loaded by dependency when
either vfio-pci or kvm-intel is loaded (or other producer/consumer
objects).

Is this a reasonable starting point to craft the additional fields and
callbacks and interaction of who calls who that we need to support
Posted Interrupts and IRQ Forwarding?  Is the AMD version of this still
alive?  Thanks,

Alex

diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 413a7bf..22f6fcb 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -61,6 +61,7 @@ config KVM_INTEL
 	depends on KVM
 	# for perf_guest_get_msrs():
 	depends on CPU_SUP_INTEL
+	select IRQ_BYPASS_MANAGER
 	---help---
 	  Provides support for KVM on Intel processors equipped with the VT
 	  extensions.
diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
index 579d83b..02912f1 100644
--- a/drivers/vfio/pci/Kconfig
+++ b/drivers/vfio/pci/Kconfig
@@ -2,6 +2,7 @@ config VFIO_PCI
 	tristate "VFIO support for PCI devices"
 	depends on VFIO && PCI && EVENTFD
 	select VFIO_VIRQFD
+	select IRQ_BYPASS_MANAGER
 	help
 	  Support for the PCI VFIO bus driver.  This is required to make
 	  use of PCI drivers using the VFIO framework.
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c
index 1f577b4..4e053be 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -181,6 +181,7 @@ static int vfio_intx_set_signal(struct vfio_pci_device *vdev, int fd)
 
 	if (vdev->ctx[0].trigger) {
 		free_irq(pdev->irq, vdev);
+		/* irq_bypass_unregister_producer(); */
 		kfree(vdev->ctx[0].name);
 		eventfd_ctx_put(vdev->ctx[0].trigger);
 		vdev->ctx[0].trigger = NULL;
@@ -214,6 +215,8 @@ static int vfio_intx_set_signal(struct vfio_pci_device *vdev, int fd)
 		return ret;
 	}
 
+	/* irq_bypass_register_producer(); */
+
 	/*
 	 * INTx disable will stick across the new irq setup,
 	 * disable_irq won't.
@@ -319,6 +322,7 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
 
 	if (vdev->ctx[vector].trigger) {
 		free_irq(irq, vdev->ctx[vector].trigger);
+		/* irq_bypass_unregister_producer(); */
 		kfree(vdev->ctx[vector].name);
 		eventfd_ctx_put(vdev->ctx[vector].trigger);
 		vdev->ctx[vector].trigger = NULL;
@@ -360,6 +364,8 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
 		return ret;
 	}
 
+	/* irq_bypass_register_producer(); */
+
 	vdev->ctx[vector].trigger = trigger;
 
 	return 0;
diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h
new file mode 100644
index 0000000..718508e
--- /dev/null
+++ b/include/linux/irqbypass.h
@@ -0,0 +1,23 @@
+#ifndef IRQBYPASS_H
+#define IRQBYPASS_H
+
+#include <linux/list.h>
+
+struct irq_bypass_producer {
+	struct list_head node;
+	void *token;
+	/* TBD */
+};
+
+struct irq_bypass_consumer {
+	struct list_head node;
+	void *token;
+	void (*add_producer)(struct irq_bypass_producer *);
+	void (*del_producer)(struct irq_bypass_producer *);
+};
+
+int irq_bypass_register_producer(struct irq_bypass_producer *);
+void irq_bypass_unregister_producer(struct irq_bypass_producer *);
+int irq_bypass_register_consumer(struct irq_bypass_consumer *);
+void irq_bypass_unregister_consumer(struct irq_bypass_consumer *);
+#endif /* IRQBYPASS_H */
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index 9a76e3b..4502cdc 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -100,4 +100,7 @@ config SPARSE_IRQ
 
 	  If you don't know what to do here, say N.
 
+config IRQ_BYPASS_MANAGER
+	bool
+
 endmenu
diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile
index d121235..a30ed77 100644
--- a/kernel/irq/Makefile
+++ b/kernel/irq/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PROC_FS) += proc.o
 obj-$(CONFIG_GENERIC_PENDING_IRQ) += migration.o
 obj-$(CONFIG_PM_SLEEP) += pm.o
 obj-$(CONFIG_GENERIC_MSI_IRQ) += msi.o
+obj-$(CONFIG_IRQ_BYPASS_MANAGER) += bypass.o
diff --git a/kernel/irq/bypass.c b/kernel/irq/bypass.c
new file mode 100644
index 0000000..5d0f92b
--- /dev/null
+++ b/kernel/irq/bypass.c
@@ -0,0 +1,116 @@
+/*
+ * IRQ offload/bypass manager
+ *
+ * Various virtualization hardware acceleration techniques allow bypassing
+ * or offloading interrupts receieved from devices around the host kernel.
+ * Posted Interrupts on Intel VT-d systems can allow interrupts to be
+ * recieved directly by a virtual machine.  ARM IRQ Forwarding can allow
+ * level triggered device interrupts to be de-asserted directly by the VM.
+ * This manager allows interrupt producers and consumers to find each other
+ * to enable this sort of bypass.
+ */
+
+#include <linux/irqbypass.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+
+static LIST_HEAD(producers);
+static LIST_HEAD(consumers);
+static DEFINE_MUTEX(lock);
+
+int irq_bypass_register_producer(struct irq_bypass_producer *producer)
+{
+	struct irq_bypass_producer *tmp;
+	struct irq_bypass_consumer *consumer;
+	int ret = 0;
+
+	mutex_lock(&lock);
+
+	list_for_each_entry(tmp, &producers, node) {
+		if (tmp->token == producer->token) {
+			ret = -EINVAL;
+			goto unlock;
+		}
+	}
+
+	list_add(&producer->node, &producers);
+
+	list_for_each_entry(consumer, &consumers, node) {
+		if (consumer->token == producer->token) {
+			consumer->add_producer(producer);
+			break;
+		}
+	}
+unlock:
+	mutex_unlock(&lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(irq_bypass_register_producer);
+
+void irq_bypass_unregister_producer(struct irq_bypass_producer *producer)
+{
+	struct irq_bypass_consumer *consumer;
+
+	mutex_lock(&lock);
+
+	list_for_each_entry(consumer, &consumers, node) {
+		if (consumer->token == producer->token) {
+			consumer->del_producer(producer);
+			break;
+		}
+	}
+
+	list_del(&producer->node);
+
+	mutex_unlock(&lock);
+}
+EXPORT_SYMBOL_GPL(irq_bypass_unregister_producer);
+
+int irq_bypass_register_consumer(struct irq_bypass_consumer *consumer)
+{
+	struct irq_bypass_consumer *tmp;
+	struct irq_bypass_producer *producer;
+	int ret = 0;
+
+	mutex_lock(&lock);
+
+	list_for_each_entry(tmp, &consumers, node) {
+		if (tmp->token == consumer->token) {
+			ret = -EINVAL;
+			goto unlock;
+		}
+	}
+
+	list_add(&consumer->node, &consumers);
+
+	list_for_each_entry(producer, &producers, node) {
+		if (producer->token == consumer->token) {
+			consumer->add_producer(producer);
+			break;
+		}
+	}
+unlock:
+	mutex_unlock(&lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(irq_bypass_register_consumer);
+
+void irq_bypass_unregister_consumer(struct irq_bypass_consumer *consumer)
+{
+	struct irq_bypass_producer *producer;
+
+	mutex_lock(&lock);
+
+	list_for_each_entry(producer, &producers, node) {
+		if (producer->token == consumer->token) {
+			consumer->del_producer(producer);
+			break;
+		}
+	}
+
+	list_del(&consumer->node);
+
+	mutex_unlock(&lock);
+}
+EXPORT_SYMBOL_GPL(irq_bypass_unregister_consumer);
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 9ff4193..f3da161 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -429,6 +429,8 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
 	 */
 	fdput(f);
 
+	/* irq_bypass_register_consumer(); */
+
 	return 0;
 
 fail:
@@ -528,6 +530,8 @@ kvm_irqfd_deassign(struct kvm *kvm, struct kvm_irqfd *args)
 	struct _irqfd *irqfd, *tmp;
 	struct eventfd_ctx *eventfd;
 
+	/* irq_bypass_unregister_consumer() */
+
 	eventfd = eventfd_ctx_fdget(args->fd);
 	if (IS_ERR(eventfd))
 		return PTR_ERR(eventfd);



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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web