| Message ID | 1416918215-21878-2-git-send-email-feng.wu@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 11/25/2014 01:23 PM, Feng Wu wrote: > This patch adds and documents a new attribute > KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE group. > This new attribute is used for VT-d Posted-Interrupts. > > When guest OS changes the interrupt configuration for an > assigned device, such as, MSI/MSIx data/address fields, > QEMU will use this IRQ attribute to tell KVM to update the > related IRTE according the VT-d Posted-Interrrupts Specification, > such as, the guest vector should be updated in the related IRTE. > > Signed-off-by: Feng Wu <feng.wu@intel.com> > --- > Documentation/virtual/kvm/devices/vfio.txt | 9 +++++++++ > include/uapi/linux/kvm.h | 10 ++++++++++ > 2 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/Documentation/virtual/kvm/devices/vfio.txt b/Documentation/virtual/kvm/devices/vfio.txt > index f7aff29..39dee86 100644 > --- a/Documentation/virtual/kvm/devices/vfio.txt > +++ b/Documentation/virtual/kvm/devices/vfio.txt > @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has been called to trigger the IRQ > or associate an eventfd to it. Unforwarding can only be called while the > signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this condition is > not satisfied, the command returns an -EBUSY. > + > + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups mechanism to post > + the IRQ to guests. > +For this attribute, kvm_device_attr.addr points to a kvm_posted_intr struct. > + > +When guest OS changes the interrupt configuration for an assigned device, > +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute > +to tell KVM to update the related IRTE according the VT-d Posted-Interrrupts > +Specification, such as, the guest vector should be updated in the related IRTE. > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index a269a42..e5f86ad 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -949,6 +949,7 @@ struct kvm_device_attr { > #define KVM_DEV_VFIO_DEVICE 2 > #define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1 > #define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ 2 > +#define KVM_DEV_VFIO_DEVICE_POSTING_IRQ 3 > > enum kvm_device_type { > KVM_DEV_TYPE_FSL_MPIC_20 = 1, > @@ -973,6 +974,15 @@ struct kvm_arch_forwarded_irq { > __u32 gsi; /* gsi, ie. virtual IRQ number */ > }; > > +struct kvm_posted_intr { > + __u32 argsz; > + __u32 fd; /* file descriptor of the VFIO device */ > + __u32 index; /* VFIO device IRQ index */ > + __u32 start; > + __u32 count; > + int virq[0]; /* gsi, ie. virtual IRQ number */ > +}; Hi Feng, This struct could be used by arm code too. If Alex agrees I could use that one instead. We just need to find a common sensible name Best Regards Eric > + > /* > * ioctls for VM fds > */ > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2014-11-25 at 16:01 +0100, Eric Auger wrote: > On 11/25/2014 01:23 PM, Feng Wu wrote: > > This patch adds and documents a new attribute > > KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE group. > > This new attribute is used for VT-d Posted-Interrupts. > > > > When guest OS changes the interrupt configuration for an > > assigned device, such as, MSI/MSIx data/address fields, > > QEMU will use this IRQ attribute to tell KVM to update the > > related IRTE according the VT-d Posted-Interrrupts Specification, > > such as, the guest vector should be updated in the related IRTE. > > > > Signed-off-by: Feng Wu <feng.wu@intel.com> > > --- > > Documentation/virtual/kvm/devices/vfio.txt | 9 +++++++++ > > include/uapi/linux/kvm.h | 10 ++++++++++ > > 2 files changed, 19 insertions(+), 0 deletions(-) > > > > diff --git a/Documentation/virtual/kvm/devices/vfio.txt b/Documentation/virtual/kvm/devices/vfio.txt > > index f7aff29..39dee86 100644 > > --- a/Documentation/virtual/kvm/devices/vfio.txt > > +++ b/Documentation/virtual/kvm/devices/vfio.txt > > @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has been called to trigger the IRQ > > or associate an eventfd to it. Unforwarding can only be called while the > > signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this condition is > > not satisfied, the command returns an -EBUSY. > > + > > + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups mechanism to post > > + the IRQ to guests. > > +For this attribute, kvm_device_attr.addr points to a kvm_posted_intr struct. > > + > > +When guest OS changes the interrupt configuration for an assigned device, > > +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute > > +to tell KVM to update the related IRTE according the VT-d Posted-Interrrupts > > +Specification, such as, the guest vector should be updated in the related IRTE. > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > > index a269a42..e5f86ad 100644 > > --- a/include/uapi/linux/kvm.h > > +++ b/include/uapi/linux/kvm.h > > @@ -949,6 +949,7 @@ struct kvm_device_attr { > > #define KVM_DEV_VFIO_DEVICE 2 > > #define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1 > > #define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ 2 > > +#define KVM_DEV_VFIO_DEVICE_POSTING_IRQ 3 > > > > enum kvm_device_type { > > KVM_DEV_TYPE_FSL_MPIC_20 = 1, > > @@ -973,6 +974,15 @@ struct kvm_arch_forwarded_irq { > > __u32 gsi; /* gsi, ie. virtual IRQ number */ > > }; > > > > +struct kvm_posted_intr { > > + __u32 argsz; > > + __u32 fd; /* file descriptor of the VFIO device */ > > + __u32 index; /* VFIO device IRQ index */ > > + __u32 start; > > + __u32 count; > > + int virq[0]; /* gsi, ie. virtual IRQ number */ > > +}; > Hi Feng, > > This struct could be used by arm code too. If Alex agrees I could use > that one instead. We just need to find a common sensible name Yep, the interface might as well support batch setup. The vfio code uses -1 for teardown if we want to avoid FORWARD vs UNFORWARD we could let the data in the structure define which operation to do. Ideally the code in virt/kvm/vfio.c would be almost entirely shared and just make different arch_foo() callouts. The PCI smarts in 2/2 here should probably be moved out to that same arch_ code. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleCBXaWxsaWFtc29u IFttYWlsdG86YWxleC53aWxsaWFtc29uQHJlZGhhdC5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwg Tm92ZW1iZXIgMjYsIDIwMTQgMTI6MTAgQU0NCj4gVG86IEVyaWMgQXVnZXINCj4gQ2M6IFd1LCBG ZW5nOyBwYm9uemluaUByZWRoYXQuY29tOyBnbGViQGtlcm5lbC5vcmc7IGt2bUB2Z2VyLmtlcm5l bC5vcmcNCj4gU3ViamVjdDogUmU6IFtSRkMgUEFUQ0ggdjIgMS8yXSBLVk06IGt2bS12ZmlvOiBV c2VyIEFQSSBmb3IgVlQtZA0KPiBQb3N0ZWQtSW50ZXJydXB0cw0KPiANCj4gT24gVHVlLCAyMDE0 LTExLTI1IGF0IDE2OjAxICswMTAwLCBFcmljIEF1Z2VyIHdyb3RlOg0KPiA+IE9uIDExLzI1LzIw MTQgMDE6MjMgUE0sIEZlbmcgV3Ugd3JvdGU6DQo+ID4gPiBUaGlzIHBhdGNoIGFkZHMgYW5kIGRv Y3VtZW50cyBhIG5ldyBhdHRyaWJ1dGUNCj4gPiA+IEtWTV9ERVZfVkZJT19ERVZJQ0VfUE9TVElO R19JUlEgaW4gS1ZNX0RFVl9WRklPX0RFVklDRSBncm91cC4NCj4gPiA+IFRoaXMgbmV3IGF0dHJp YnV0ZSBpcyB1c2VkIGZvciBWVC1kIFBvc3RlZC1JbnRlcnJ1cHRzLg0KPiA+ID4NCj4gPiA+IFdo ZW4gZ3Vlc3QgT1MgY2hhbmdlcyB0aGUgaW50ZXJydXB0IGNvbmZpZ3VyYXRpb24gZm9yIGFuDQo+ ID4gPiBhc3NpZ25lZCBkZXZpY2UsIHN1Y2ggYXMsIE1TSS9NU0l4IGRhdGEvYWRkcmVzcyBmaWVs ZHMsDQo+ID4gPiBRRU1VIHdpbGwgdXNlIHRoaXMgSVJRIGF0dHJpYnV0ZSB0byB0ZWxsIEtWTSB0 byB1cGRhdGUgdGhlDQo+ID4gPiByZWxhdGVkIElSVEUgYWNjb3JkaW5nIHRoZSBWVC1kIFBvc3Rl ZC1JbnRlcnJydXB0cyBTcGVjaWZpY2F0aW9uLA0KPiA+ID4gc3VjaCBhcywgdGhlIGd1ZXN0IHZl Y3RvciBzaG91bGQgYmUgdXBkYXRlZCBpbiB0aGUgcmVsYXRlZCBJUlRFLg0KPiA+ID4NCj4gPiA+ IFNpZ25lZC1vZmYtYnk6IEZlbmcgV3UgPGZlbmcud3VAaW50ZWwuY29tPg0KPiA+ID4gLS0tDQo+ ID4gPiAgRG9jdW1lbnRhdGlvbi92aXJ0dWFsL2t2bS9kZXZpY2VzL3ZmaW8udHh0IHwgICAgOSAr KysrKysrKysNCj4gPiA+ICBpbmNsdWRlL3VhcGkvbGludXgva3ZtLmggICAgICAgICAgICAgICAg ICAgfCAgIDEwICsrKysrKysrKysNCj4gPiA+ICAyIGZpbGVzIGNoYW5nZWQsIDE5IGluc2VydGlv bnMoKyksIDAgZGVsZXRpb25zKC0pDQo+ID4gPg0KPiA+ID4gZGlmZiAtLWdpdCBhL0RvY3VtZW50 YXRpb24vdmlydHVhbC9rdm0vZGV2aWNlcy92ZmlvLnR4dA0KPiBiL0RvY3VtZW50YXRpb24vdmly dHVhbC9rdm0vZGV2aWNlcy92ZmlvLnR4dA0KPiA+ID4gaW5kZXggZjdhZmYyOS4uMzlkZWU4NiAx MDA2NDQNCj4gPiA+IC0tLSBhL0RvY3VtZW50YXRpb24vdmlydHVhbC9rdm0vZGV2aWNlcy92Zmlv LnR4dA0KPiA+ID4gKysrIGIvRG9jdW1lbnRhdGlvbi92aXJ0dWFsL2t2bS9kZXZpY2VzL3ZmaW8u dHh0DQo+ID4gPiBAQCAtNDIsMyArNDIsMTIgQEAgYWN0aXZhdGVkIGJlZm9yZSBWRklPX0RFVklD RV9TRVRfSVJRUyBoYXMgYmVlbg0KPiBjYWxsZWQgdG8gdHJpZ2dlciB0aGUgSVJRDQo+ID4gPiAg b3IgYXNzb2NpYXRlIGFuIGV2ZW50ZmQgdG8gaXQuIFVuZm9yd2FyZGluZyBjYW4gb25seSBiZSBj YWxsZWQgd2hpbGUgdGhlDQo+ID4gPiAgc2lnbmFsaW5nIGhhcyBiZWVuIGRpc2FibGVkIHdpdGgg VkZJT19ERVZJQ0VfU0VUX0lSUVMuIElmIHRoaXMgY29uZGl0aW9uDQo+IGlzDQo+ID4gPiAgbm90 IHNhdGlzZmllZCwgdGhlIGNvbW1hbmQgcmV0dXJucyBhbiAtRUJVU1kuDQo+ID4gPiArDQo+ID4g PiArICBLVk1fREVWX1ZGSU9fREVWSUNFX1BPU1RJTkdfSVJROiBVc2UgcG9zdGVkIGludGVycnR1 cHMNCj4gbWVjaGFuaXNtIHRvIHBvc3QNCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHRoZSBJUlEgdG8gZ3Vlc3RzLg0KPiA+ID4gK0ZvciB0aGlzIGF0dHJpYnV0ZSwg a3ZtX2RldmljZV9hdHRyLmFkZHIgcG9pbnRzIHRvIGEga3ZtX3Bvc3RlZF9pbnRyDQo+IHN0cnVj dC4NCj4gPiA+ICsNCj4gPiA+ICtXaGVuIGd1ZXN0IE9TIGNoYW5nZXMgdGhlIGludGVycnVwdCBj b25maWd1cmF0aW9uIGZvciBhbiBhc3NpZ25lZCBkZXZpY2UsDQo+ID4gPiArc3VjaCBhcywgTVNJ L01TSXggZGF0YS9hZGRyZXNzIGZpZWxkcywgUUVNVSB3aWxsIHVzZSB0aGlzIElSUSBhdHRyaWJ1 dGUNCj4gPiA+ICt0byB0ZWxsIEtWTSB0byB1cGRhdGUgdGhlIHJlbGF0ZWQgSVJURSBhY2NvcmRp bmcgdGhlIFZULWQNCj4gUG9zdGVkLUludGVycnJ1cHRzDQo+ID4gPiArU3BlY2lmaWNhdGlvbiwg c3VjaCBhcywgdGhlIGd1ZXN0IHZlY3RvciBzaG91bGQgYmUgdXBkYXRlZCBpbiB0aGUgcmVsYXRl ZA0KPiBJUlRFLg0KPiA+ID4gZGlmZiAtLWdpdCBhL2luY2x1ZGUvdWFwaS9saW51eC9rdm0uaCBi L2luY2x1ZGUvdWFwaS9saW51eC9rdm0uaA0KPiA+ID4gaW5kZXggYTI2OWE0Mi4uZTVmODZhZCAx MDA2NDQNCj4gPiA+IC0tLSBhL2luY2x1ZGUvdWFwaS9saW51eC9rdm0uaA0KPiA+ID4gKysrIGIv aW5jbHVkZS91YXBpL2xpbnV4L2t2bS5oDQo+ID4gPiBAQCAtOTQ5LDYgKzk0OSw3IEBAIHN0cnVj dCBrdm1fZGV2aWNlX2F0dHIgew0KPiA+ID4gICNkZWZpbmUgIEtWTV9ERVZfVkZJT19ERVZJQ0UJ CQkyDQo+ID4gPiAgI2RlZmluZSAgIEtWTV9ERVZfVkZJT19ERVZJQ0VfRk9SV0FSRF9JUlEJCQkx DQo+ID4gPiAgI2RlZmluZSAgIEtWTV9ERVZfVkZJT19ERVZJQ0VfVU5GT1JXQVJEX0lSUQkJCTIN Cj4gPiA+ICsjZGVmaW5lICAgS1ZNX0RFVl9WRklPX0RFVklDRV9QT1NUSU5HX0lSUQkJCTMNCj4g PiA+DQo+ID4gPiAgZW51bSBrdm1fZGV2aWNlX3R5cGUgew0KPiA+ID4gIAlLVk1fREVWX1RZUEVf RlNMX01QSUNfMjAJPSAxLA0KPiA+ID4gQEAgLTk3Myw2ICs5NzQsMTUgQEAgc3RydWN0IGt2bV9h cmNoX2ZvcndhcmRlZF9pcnEgew0KPiA+ID4gIAlfX3UzMiBnc2k7IC8qIGdzaSwgaWUuIHZpcnR1 YWwgSVJRIG51bWJlciAqLw0KPiA+ID4gIH07DQo+ID4gPg0KPiA+ID4gK3N0cnVjdCBrdm1fcG9z dGVkX2ludHIgew0KPiA+ID4gKwlfX3UzMglhcmdzejsNCj4gPiA+ICsJX191MzIJZmQ7CQkvKiBm aWxlIGRlc2NyaXB0b3Igb2YgdGhlIFZGSU8gZGV2aWNlICovDQo+ID4gPiArCV9fdTMyCWluZGV4 OwkJLyogVkZJTyBkZXZpY2UgSVJRIGluZGV4ICovDQo+ID4gPiArCV9fdTMyCXN0YXJ0Ow0KPiA+ ID4gKwlfX3UzMgljb3VudDsNCj4gPiA+ICsJaW50CXZpcnFbMF07CS8qIGdzaSwgaWUuIHZpcnR1 YWwgSVJRIG51bWJlciAqLw0KPiA+ID4gK307DQo+ID4gSGkgRmVuZywNCj4gPg0KPiA+IFRoaXMg c3RydWN0IGNvdWxkIGJlIHVzZWQgYnkgYXJtIGNvZGUgdG9vLiBJZiBBbGV4IGFncmVlcyBJIGNv dWxkIHVzZQ0KPiA+IHRoYXQgb25lIGluc3RlYWQuIFdlIGp1c3QgbmVlZCB0byBmaW5kIGEgY29t bW9uIHNlbnNpYmxlIG5hbWUNCj4gDQo+IFllcCwgdGhlIGludGVyZmFjZSBtaWdodCBhcyB3ZWxs IHN1cHBvcnQgYmF0Y2ggc2V0dXAuICBUaGUgdmZpbyBjb2RlDQo+IHVzZXMgLTEgZm9yIHRlYXJk b3duIGlmIHdlIHdhbnQgdG8gYXZvaWQgRk9SV0FSRCB2cyBVTkZPUldBUkQgd2UgY291bGQNCj4g bGV0IHRoZSBkYXRhIGluIHRoZSBzdHJ1Y3R1cmUgZGVmaW5lIHdoaWNoIG9wZXJhdGlvbiB0byBk by4gIElkZWFsbHkgdGhlDQo+IGNvZGUgaW4gdmlydC9rdm0vdmZpby5jIHdvdWxkIGJlIGFsbW9z dCBlbnRpcmVseSBzaGFyZWQgYW5kIGp1c3QgbWFrZQ0KPiBkaWZmZXJlbnQgYXJjaF9mb28oKSBj YWxsb3V0cy4gIFRoZSBQQ0kgc21hcnRzIGluIDIvMiBoZXJlIHNob3VsZA0KPiBwcm9iYWJseSBi ZSBtb3ZlZCBvdXQgdG8gdGhhdCBzYW1lIGFyY2hfIGNvZGUuICBUaGFua3MsDQo+IA0KPiBBbGV4 DQoNClRoYXQgd291bGQgYmUgZ3JlYXQgaWYgd2Ugc2hhcmUgdGhlIHNhbWUgZGF0YSBzdHJ1Y3R1 cmUhDQoNClRoYW5rcywNCkZlbmcNCg0K -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/25/2014 05:10 PM, Alex Williamson wrote: > On Tue, 2014-11-25 at 16:01 +0100, Eric Auger wrote: >> On 11/25/2014 01:23 PM, Feng Wu wrote: >>> This patch adds and documents a new attribute >>> KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE group. >>> This new attribute is used for VT-d Posted-Interrupts. >>> >>> When guest OS changes the interrupt configuration for an >>> assigned device, such as, MSI/MSIx data/address fields, >>> QEMU will use this IRQ attribute to tell KVM to update the >>> related IRTE according the VT-d Posted-Interrrupts Specification, >>> such as, the guest vector should be updated in the related IRTE. >>> >>> Signed-off-by: Feng Wu <feng.wu@intel.com> >>> --- >>> Documentation/virtual/kvm/devices/vfio.txt | 9 +++++++++ >>> include/uapi/linux/kvm.h | 10 ++++++++++ >>> 2 files changed, 19 insertions(+), 0 deletions(-) >>> >>> diff --git a/Documentation/virtual/kvm/devices/vfio.txt b/Documentation/virtual/kvm/devices/vfio.txt >>> index f7aff29..39dee86 100644 >>> --- a/Documentation/virtual/kvm/devices/vfio.txt >>> +++ b/Documentation/virtual/kvm/devices/vfio.txt >>> @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has been called to trigger the IRQ >>> or associate an eventfd to it. Unforwarding can only be called while the >>> signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this condition is >>> not satisfied, the command returns an -EBUSY. >>> + >>> + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups mechanism to post >>> + the IRQ to guests. >>> +For this attribute, kvm_device_attr.addr points to a kvm_posted_intr struct. >>> + >>> +When guest OS changes the interrupt configuration for an assigned device, >>> +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute >>> +to tell KVM to update the related IRTE according the VT-d Posted-Interrrupts >>> +Specification, such as, the guest vector should be updated in the related IRTE. >>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >>> index a269a42..e5f86ad 100644 >>> --- a/include/uapi/linux/kvm.h >>> +++ b/include/uapi/linux/kvm.h >>> @@ -949,6 +949,7 @@ struct kvm_device_attr { >>> #define KVM_DEV_VFIO_DEVICE 2 >>> #define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1 >>> #define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ 2 >>> +#define KVM_DEV_VFIO_DEVICE_POSTING_IRQ 3 >>> >>> enum kvm_device_type { >>> KVM_DEV_TYPE_FSL_MPIC_20 = 1, >>> @@ -973,6 +974,15 @@ struct kvm_arch_forwarded_irq { >>> __u32 gsi; /* gsi, ie. virtual IRQ number */ >>> }; >>> Hi Feng, Alex, I am currently reworking my code to use something closer to this struct. Would you agree with following changes? >>> +struct kvm_posted_intr { kvm_posted_irq >>> + __u32 argsz; >>> + __u32 fd; /* file descriptor of the VFIO device */ >>> + __u32 index; /* VFIO device IRQ index */ >>> + __u32 start; >>> + __u32 count; >>> + int virq[0]; /* gsi, ie. virtual IRQ number */ __u32 gsi[]; >>> +}; >> Hi Feng, >> >> This struct could be used by arm code too. If Alex agrees I could use >> that one instead. We just need to find a common sensible name > > Yep, the interface might as well support batch setup. The vfio code > uses -1 for teardown if we want to avoid FORWARD vs UNFORWARD we could > let the data in the structure define which operation to do. In case we remove the unforward and use fd=1 to tear down, the virq=gsi must uniquely identify the struct. For ARM I think this is true, we cannot have several physical IRQ forwarded to the same GSI. I don't know about posted irqs or other archs. Best Regards Eric Ideally the > code in virt/kvm/vfio.c would be almost entirely shared and just make > different arch_foo() callouts. The PCI smarts in 2/2 here should > probably be moved out to that same arch_ code. Thanks, > > Alex > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Eric Auger [mailto:eric.auger@linaro.org] > Sent: Monday, December 01, 2014 6:10 PM > To: Alex Williamson > Cc: Wu, Feng; pbonzini@redhat.com; gleb@kernel.org; kvm@vger.kernel.org > Subject: Re: [RFC PATCH v2 1/2] KVM: kvm-vfio: User API for VT-d > Posted-Interrupts > > On 11/25/2014 05:10 PM, Alex Williamson wrote: > > On Tue, 2014-11-25 at 16:01 +0100, Eric Auger wrote: > >> On 11/25/2014 01:23 PM, Feng Wu wrote: > >>> This patch adds and documents a new attribute > >>> KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE > group. > >>> This new attribute is used for VT-d Posted-Interrupts. > >>> > >>> When guest OS changes the interrupt configuration for an > >>> assigned device, such as, MSI/MSIx data/address fields, > >>> QEMU will use this IRQ attribute to tell KVM to update the > >>> related IRTE according the VT-d Posted-Interrrupts Specification, > >>> such as, the guest vector should be updated in the related IRTE. > >>> > >>> Signed-off-by: Feng Wu <feng.wu@intel.com> > >>> --- > >>> Documentation/virtual/kvm/devices/vfio.txt | 9 +++++++++ > >>> include/uapi/linux/kvm.h | 10 ++++++++++ > >>> 2 files changed, 19 insertions(+), 0 deletions(-) > >>> > >>> diff --git a/Documentation/virtual/kvm/devices/vfio.txt > b/Documentation/virtual/kvm/devices/vfio.txt > >>> index f7aff29..39dee86 100644 > >>> --- a/Documentation/virtual/kvm/devices/vfio.txt > >>> +++ b/Documentation/virtual/kvm/devices/vfio.txt > >>> @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has been > called to trigger the IRQ > >>> or associate an eventfd to it. Unforwarding can only be called while the > >>> signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this > condition is > >>> not satisfied, the command returns an -EBUSY. > >>> + > >>> + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups > mechanism to post > >>> + the IRQ to guests. > >>> +For this attribute, kvm_device_attr.addr points to a kvm_posted_intr > struct. > >>> + > >>> +When guest OS changes the interrupt configuration for an assigned > device, > >>> +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute > >>> +to tell KVM to update the related IRTE according the VT-d > Posted-Interrrupts > >>> +Specification, such as, the guest vector should be updated in the related > IRTE. > >>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > >>> index a269a42..e5f86ad 100644 > >>> --- a/include/uapi/linux/kvm.h > >>> +++ b/include/uapi/linux/kvm.h > >>> @@ -949,6 +949,7 @@ struct kvm_device_attr { > >>> #define KVM_DEV_VFIO_DEVICE 2 > >>> #define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1 > >>> #define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ 2 > >>> +#define KVM_DEV_VFIO_DEVICE_POSTING_IRQ 3 > >>> > >>> enum kvm_device_type { > >>> KVM_DEV_TYPE_FSL_MPIC_20 = 1, > >>> @@ -973,6 +974,15 @@ struct kvm_arch_forwarded_irq { > >>> __u32 gsi; /* gsi, ie. virtual IRQ number */ > >>> }; > >>> > Hi Feng, Alex, > I am currently reworking my code to use something closer to this struct. > Would you agree with following changes? > >>> +struct kvm_posted_intr { > kvm_posted_irq Hi Alex, Do you mean changing the structure name to "kvm_posted_irq"? I am okay If you think this name is also suitable for ARM forwarded irq. Or we can find a more common name, such as "struct kvm_accel_irq", what is your opinion, Alex? > >>> + __u32 argsz; > >>> + __u32 fd; /* file descriptor of the VFIO device */ > >>> + __u32 index; /* VFIO device IRQ index */ > >>> + __u32 start; > >>> + __u32 count; > >>> + int virq[0]; /* gsi, ie. virtual IRQ number */ > __u32 gsi[]; I think this change is okay to me. If Alex also agree, I will follow this in the next post. Thanks, Feng > >>> +}; > >> Hi Feng, > >> > >> This struct could be used by arm code too. If Alex agrees I could use > >> that one instead. We just need to find a common sensible name > > > > Yep, the interface might as well support batch setup. The vfio code > > uses -1 for teardown if we want to avoid FORWARD vs UNFORWARD we could > > let the data in the structure define which operation to do. > > In case we remove the unforward and use fd=1 to tear down, the virq=gsi > must uniquely identify the struct. For ARM I think this is true, we > cannot have several physical IRQ forwarded to the same GSI. I don't know > about posted irqs or other archs. > > Best Regards > > Eric > Ideally the > > code in virt/kvm/vfio.c would be almost entirely shared and just make > > different arch_foo() callouts. The PCI smarts in 2/2 here should > > probably be moved out to that same arch_ code. Thanks, > > > > Alex > >
On Tue, 2014-12-02 at 02:08 +0000, Wu, Feng wrote: > > > -----Original Message----- > > From: Eric Auger [mailto:eric.auger@linaro.org] > > Sent: Monday, December 01, 2014 6:10 PM > > To: Alex Williamson > > Cc: Wu, Feng; pbonzini@redhat.com; gleb@kernel.org; kvm@vger.kernel.org > > Subject: Re: [RFC PATCH v2 1/2] KVM: kvm-vfio: User API for VT-d > > Posted-Interrupts > > > > On 11/25/2014 05:10 PM, Alex Williamson wrote: > > > On Tue, 2014-11-25 at 16:01 +0100, Eric Auger wrote: > > >> On 11/25/2014 01:23 PM, Feng Wu wrote: > > >>> This patch adds and documents a new attribute > > >>> KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE > > group. > > >>> This new attribute is used for VT-d Posted-Interrupts. > > >>> > > >>> When guest OS changes the interrupt configuration for an > > >>> assigned device, such as, MSI/MSIx data/address fields, > > >>> QEMU will use this IRQ attribute to tell KVM to update the > > >>> related IRTE according the VT-d Posted-Interrrupts Specification, > > >>> such as, the guest vector should be updated in the related IRTE. > > >>> > > >>> Signed-off-by: Feng Wu <feng.wu@intel.com> > > >>> --- > > >>> Documentation/virtual/kvm/devices/vfio.txt | 9 +++++++++ > > >>> include/uapi/linux/kvm.h | 10 ++++++++++ > > >>> 2 files changed, 19 insertions(+), 0 deletions(-) > > >>> > > >>> diff --git a/Documentation/virtual/kvm/devices/vfio.txt > > b/Documentation/virtual/kvm/devices/vfio.txt > > >>> index f7aff29..39dee86 100644 > > >>> --- a/Documentation/virtual/kvm/devices/vfio.txt > > >>> +++ b/Documentation/virtual/kvm/devices/vfio.txt > > >>> @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has been > > called to trigger the IRQ > > >>> or associate an eventfd to it. Unforwarding can only be called while the > > >>> signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this > > condition is > > >>> not satisfied, the command returns an -EBUSY. > > >>> + > > >>> + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups > > mechanism to post > > >>> + the IRQ to guests. > > >>> +For this attribute, kvm_device_attr.addr points to a kvm_posted_intr > > struct. > > >>> + > > >>> +When guest OS changes the interrupt configuration for an assigned > > device, > > >>> +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute > > >>> +to tell KVM to update the related IRTE according the VT-d > > Posted-Interrrupts > > >>> +Specification, such as, the guest vector should be updated in the related > > IRTE. > > >>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > > >>> index a269a42..e5f86ad 100644 > > >>> --- a/include/uapi/linux/kvm.h > > >>> +++ b/include/uapi/linux/kvm.h > > >>> @@ -949,6 +949,7 @@ struct kvm_device_attr { > > >>> #define KVM_DEV_VFIO_DEVICE 2 > > >>> #define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1 > > >>> #define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ 2 > > >>> +#define KVM_DEV_VFIO_DEVICE_POSTING_IRQ 3 > > >>> > > >>> enum kvm_device_type { > > >>> KVM_DEV_TYPE_FSL_MPIC_20 = 1, > > >>> @@ -973,6 +974,15 @@ struct kvm_arch_forwarded_irq { > > >>> __u32 gsi; /* gsi, ie. virtual IRQ number */ > > >>> }; > > >>> > > Hi Feng, Alex, > > I am currently reworking my code to use something closer to this struct. > > Would you agree with following changes? > > >>> +struct kvm_posted_intr { > > kvm_posted_irq > > Hi Alex, > > Do you mean changing the structure name to "kvm_posted_irq"? I am okay > If you think this name is also suitable for ARM forwarded irq. Or we can find > a more common name, such as "struct kvm_accel_irq", what is your opinion, Alex? I'd think something like struct kvm_vfio_dev_irq describes it fairly well. > > >>> + __u32 argsz; > > >>> + __u32 fd; /* file descriptor of the VFIO device */ > > >>> + __u32 index; /* VFIO device IRQ index */ > > >>> + __u32 start; > > >>> + __u32 count; > > >>> + int virq[0]; /* gsi, ie. virtual IRQ number */ > > __u32 gsi[]; > > I think this change is okay to me. If Alex also agree, I will follow this in the > next post. > > > >>> +}; > > >> Hi Feng, > > >> > > >> This struct could be used by arm code too. If Alex agrees I could use > > >> that one instead. We just need to find a common sensible name > > > > > > Yep, the interface might as well support batch setup. The vfio code > > > uses -1 for teardown if we want to avoid FORWARD vs UNFORWARD we could > > > let the data in the structure define which operation to do. > > > > In case we remove the unforward and use fd=1 to tear down, the virq=gsi > > must uniquely identify the struct. For ARM I think this is true, we > > cannot have several physical IRQ forwarded to the same GSI. I don't know > > about posted irqs or other archs. It makes more sense to me that fd is the real vfio_device fd that we uniquely match to existing forwarded/posted IRQs by {vfio_device,index,start[count]}. If gsi was then signed, passing -1 could be used to teardown that forward/posting. Passing fd=1, ie. stdout, is pretty non-intuitive to me. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Alex Williamson [mailto:alex.williamson@redhat.com] > Sent: Tuesday, December 02, 2014 12:48 PM > To: Wu, Feng > Cc: Eric Auger; pbonzini@redhat.com; gleb@kernel.org; kvm@vger.kernel.org > Subject: Re: [RFC PATCH v2 1/2] KVM: kvm-vfio: User API for VT-d > Posted-Interrupts > > On Tue, 2014-12-02 at 02:08 +0000, Wu, Feng wrote: > > > > > -----Original Message----- > > > From: Eric Auger [mailto:eric.auger@linaro.org] > > > Sent: Monday, December 01, 2014 6:10 PM > > > To: Alex Williamson > > > Cc: Wu, Feng; pbonzini@redhat.com; gleb@kernel.org; > kvm@vger.kernel.org > > > Subject: Re: [RFC PATCH v2 1/2] KVM: kvm-vfio: User API for VT-d > > > Posted-Interrupts > > > > > > On 11/25/2014 05:10 PM, Alex Williamson wrote: > > > > On Tue, 2014-11-25 at 16:01 +0100, Eric Auger wrote: > > > >> On 11/25/2014 01:23 PM, Feng Wu wrote: > > > >>> This patch adds and documents a new attribute > > > >>> KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE > > > group. > > > >>> This new attribute is used for VT-d Posted-Interrupts. > > > >>> > > > >>> When guest OS changes the interrupt configuration for an > > > >>> assigned device, such as, MSI/MSIx data/address fields, > > > >>> QEMU will use this IRQ attribute to tell KVM to update the > > > >>> related IRTE according the VT-d Posted-Interrrupts Specification, > > > >>> such as, the guest vector should be updated in the related IRTE. > > > >>> > > > >>> Signed-off-by: Feng Wu <feng.wu@intel.com> > > > >>> --- > > > >>> Documentation/virtual/kvm/devices/vfio.txt | 9 +++++++++ > > > >>> include/uapi/linux/kvm.h | 10 ++++++++++ > > > >>> 2 files changed, 19 insertions(+), 0 deletions(-) > > > >>> > > > >>> diff --git a/Documentation/virtual/kvm/devices/vfio.txt > > > b/Documentation/virtual/kvm/devices/vfio.txt > > > >>> index f7aff29..39dee86 100644 > > > >>> --- a/Documentation/virtual/kvm/devices/vfio.txt > > > >>> +++ b/Documentation/virtual/kvm/devices/vfio.txt > > > >>> @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has > been > > > called to trigger the IRQ > > > >>> or associate an eventfd to it. Unforwarding can only be called while > the > > > >>> signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this > > > condition is > > > >>> not satisfied, the command returns an -EBUSY. > > > >>> + > > > >>> + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups > > > mechanism to post > > > >>> + the IRQ to guests. > > > >>> +For this attribute, kvm_device_attr.addr points to a kvm_posted_intr > > > struct. > > > >>> + > > > >>> +When guest OS changes the interrupt configuration for an assigned > > > device, > > > >>> +such as, MSI/MSIx data/address fields, QEMU will use this IRQ > attribute > > > >>> +to tell KVM to update the related IRTE according the VT-d > > > Posted-Interrrupts > > > >>> +Specification, such as, the guest vector should be updated in the > related > > > IRTE. > > > >>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > > > >>> index a269a42..e5f86ad 100644 > > > >>> --- a/include/uapi/linux/kvm.h > > > >>> +++ b/include/uapi/linux/kvm.h > > > >>> @@ -949,6 +949,7 @@ struct kvm_device_attr { > > > >>> #define KVM_DEV_VFIO_DEVICE 2 > > > >>> #define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1 > > > >>> #define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ > 2 > > > >>> +#define KVM_DEV_VFIO_DEVICE_POSTING_IRQ 3 > > > >>> > > > >>> enum kvm_device_type { > > > >>> KVM_DEV_TYPE_FSL_MPIC_20 = 1, > > > >>> @@ -973,6 +974,15 @@ struct kvm_arch_forwarded_irq { > > > >>> __u32 gsi; /* gsi, ie. virtual IRQ number */ > > > >>> }; > > > >>> > > > Hi Feng, Alex, > > > I am currently reworking my code to use something closer to this struct. > > > Would you agree with following changes? > > > >>> +struct kvm_posted_intr { > > > kvm_posted_irq > > > > Hi Alex, > > > > Do you mean changing the structure name to "kvm_posted_irq"? I am okay > > If you think this name is also suitable for ARM forwarded irq. Or we can find > > a more common name, such as "struct kvm_accel_irq", what is your opinion, > Alex? > > I'd think something like struct kvm_vfio_dev_irq describes it fairly > well. No problem! I will follow this in the next post. > > > > >>> + __u32 argsz; > > > >>> + __u32 fd; /* file descriptor of the VFIO device */ > > > >>> + __u32 index; /* VFIO device IRQ index */ > > > >>> + __u32 start; > > > >>> + __u32 count; > > > >>> + int virq[0]; /* gsi, ie. virtual IRQ number */ > > > __u32 gsi[]; > > > > I think this change is okay to me. If Alex also agree, I will follow this in the > > next post. > > > > > >>> +}; > > > >> Hi Feng, > > > >> > > > >> This struct could be used by arm code too. If Alex agrees I could use > > > >> that one instead. We just need to find a common sensible name > > > > > > > > Yep, the interface might as well support batch setup. The vfio code > > > > uses -1 for teardown if we want to avoid FORWARD vs UNFORWARD we > could > > > > let the data in the structure define which operation to do. > > > > > > In case we remove the unforward and use fd=1 to tear down, the virq=gsi > > > must uniquely identify the struct. For ARM I think this is true, we > > > cannot have several physical IRQ forwarded to the same GSI. I don't know > > > about posted irqs or other archs. > > It makes more sense to me that fd is the real vfio_device fd that we > uniquely match to existing forwarded/posted IRQs by > {vfio_device,index,start[count]}. If gsi was then signed, passing -1 > could be used to teardown that forward/posting. Passing fd=1, ie. > stdout, is pretty non-intuitive to me. Thanks, So, do you mean we still need use "int gsi[]" in "struct kvm_vfio_dev_irq"? Thanks, Feng > > Alex >
On 12/02/2014 05:48 AM, Alex Williamson wrote: > On Tue, 2014-12-02 at 02:08 +0000, Wu, Feng wrote: >> >>> -----Original Message----- >>> From: Eric Auger [mailto:eric.auger@linaro.org] >>> Sent: Monday, December 01, 2014 6:10 PM >>> To: Alex Williamson >>> Cc: Wu, Feng; pbonzini@redhat.com; gleb@kernel.org; kvm@vger.kernel.org >>> Subject: Re: [RFC PATCH v2 1/2] KVM: kvm-vfio: User API for VT-d >>> Posted-Interrupts >>> >>> On 11/25/2014 05:10 PM, Alex Williamson wrote: >>>> On Tue, 2014-11-25 at 16:01 +0100, Eric Auger wrote: >>>>> On 11/25/2014 01:23 PM, Feng Wu wrote: >>>>>> This patch adds and documents a new attribute >>>>>> KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE >>> group. >>>>>> This new attribute is used for VT-d Posted-Interrupts. >>>>>> >>>>>> When guest OS changes the interrupt configuration for an >>>>>> assigned device, such as, MSI/MSIx data/address fields, >>>>>> QEMU will use this IRQ attribute to tell KVM to update the >>>>>> related IRTE according the VT-d Posted-Interrrupts Specification, >>>>>> such as, the guest vector should be updated in the related IRTE. >>>>>> >>>>>> Signed-off-by: Feng Wu <feng.wu@intel.com> >>>>>> --- >>>>>> Documentation/virtual/kvm/devices/vfio.txt | 9 +++++++++ >>>>>> include/uapi/linux/kvm.h | 10 ++++++++++ >>>>>> 2 files changed, 19 insertions(+), 0 deletions(-) >>>>>> >>>>>> diff --git a/Documentation/virtual/kvm/devices/vfio.txt >>> b/Documentation/virtual/kvm/devices/vfio.txt >>>>>> index f7aff29..39dee86 100644 >>>>>> --- a/Documentation/virtual/kvm/devices/vfio.txt >>>>>> +++ b/Documentation/virtual/kvm/devices/vfio.txt >>>>>> @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has been >>> called to trigger the IRQ >>>>>> or associate an eventfd to it. Unforwarding can only be called while the >>>>>> signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this >>> condition is >>>>>> not satisfied, the command returns an -EBUSY. >>>>>> + >>>>>> + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups >>> mechanism to post >>>>>> + the IRQ to guests. >>>>>> +For this attribute, kvm_device_attr.addr points to a kvm_posted_intr >>> struct. >>>>>> + >>>>>> +When guest OS changes the interrupt configuration for an assigned >>> device, >>>>>> +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute >>>>>> +to tell KVM to update the related IRTE according the VT-d >>> Posted-Interrrupts >>>>>> +Specification, such as, the guest vector should be updated in the related >>> IRTE. >>>>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >>>>>> index a269a42..e5f86ad 100644 >>>>>> --- a/include/uapi/linux/kvm.h >>>>>> +++ b/include/uapi/linux/kvm.h >>>>>> @@ -949,6 +949,7 @@ struct kvm_device_attr { >>>>>> #define KVM_DEV_VFIO_DEVICE 2 >>>>>> #define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1 >>>>>> #define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ 2 >>>>>> +#define KVM_DEV_VFIO_DEVICE_POSTING_IRQ 3 >>>>>> >>>>>> enum kvm_device_type { >>>>>> KVM_DEV_TYPE_FSL_MPIC_20 = 1, >>>>>> @@ -973,6 +974,15 @@ struct kvm_arch_forwarded_irq { >>>>>> __u32 gsi; /* gsi, ie. virtual IRQ number */ >>>>>> }; >>>>>> >>> Hi Feng, Alex, >>> I am currently reworking my code to use something closer to this struct. >>> Would you agree with following changes? >>>>>> +struct kvm_posted_intr { >>> kvm_posted_irq >> >> Hi Alex, >> >> Do you mean changing the structure name to "kvm_posted_irq"? I am okay >> If you think this name is also suitable for ARM forwarded irq. Or we can find >> a more common name, such as "struct kvm_accel_irq", what is your opinion, Alex? > > I'd think something like struct kvm_vfio_dev_irq describes it fairly > well. ok for that name > >>>>>> + __u32 argsz; >>>>>> + __u32 fd; /* file descriptor of the VFIO device */ >>>>>> + __u32 index; /* VFIO device IRQ index */ >>>>>> + __u32 start; >>>>>> + __u32 count; >>>>>> + int virq[0]; /* gsi, ie. virtual IRQ number */ >>> __u32 gsi[]; >> >> I think this change is okay to me. If Alex also agree, I will follow this in the >> next post. >> >>>>>> +}; >>>>> Hi Feng, >>>>> >>>>> This struct could be used by arm code too. If Alex agrees I could use >>>>> that one instead. We just need to find a common sensible name >>>> >>>> Yep, the interface might as well support batch setup. The vfio code >>>> uses -1 for teardown if we want to avoid FORWARD vs UNFORWARD we could >>>> let the data in the structure define which operation to do. >>> >>> In case we remove the unforward and use fd=1 to tear down, the virq=gsi >>> must uniquely identify the struct. For ARM I think this is true, we >>> cannot have several physical IRQ forwarded to the same GSI. I don't know >>> about posted irqs or other archs. > > It makes more sense to me that fd is the real vfio_device fd that we > uniquely match to existing forwarded/posted IRQs by > {vfio_device,index,start[count]}. If gsi was then signed, passing -1 > could be used to teardown that forward/posting. Passing fd=1, ie. > stdout, is pretty non-intuitive to me. Thanks, sorry meant fd = -1 (typo) as in the original VFIO API. Personally I think I would prefer keeping the UNFORWARD but I will follow your guidance. Eric > > Alex > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2014-12-02 at 08:52 +0100, Eric Auger wrote: > On 12/02/2014 05:48 AM, Alex Williamson wrote: > > On Tue, 2014-12-02 at 02:08 +0000, Wu, Feng wrote: > >> > >>> -----Original Message----- > >>> From: Eric Auger [mailto:eric.auger@linaro.org] > >>> Sent: Monday, December 01, 2014 6:10 PM > >>> To: Alex Williamson > >>> Cc: Wu, Feng; pbonzini@redhat.com; gleb@kernel.org; kvm@vger.kernel.org > >>> Subject: Re: [RFC PATCH v2 1/2] KVM: kvm-vfio: User API for VT-d > >>> Posted-Interrupts > >>> > >>> On 11/25/2014 05:10 PM, Alex Williamson wrote: > >>>> On Tue, 2014-11-25 at 16:01 +0100, Eric Auger wrote: > >>>>> On 11/25/2014 01:23 PM, Feng Wu wrote: > >>>>>> This patch adds and documents a new attribute > >>>>>> KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE > >>> group. > >>>>>> This new attribute is used for VT-d Posted-Interrupts. > >>>>>> > >>>>>> When guest OS changes the interrupt configuration for an > >>>>>> assigned device, such as, MSI/MSIx data/address fields, > >>>>>> QEMU will use this IRQ attribute to tell KVM to update the > >>>>>> related IRTE according the VT-d Posted-Interrrupts Specification, > >>>>>> such as, the guest vector should be updated in the related IRTE. > >>>>>> > >>>>>> Signed-off-by: Feng Wu <feng.wu@intel.com> > >>>>>> --- > >>>>>> Documentation/virtual/kvm/devices/vfio.txt | 9 +++++++++ > >>>>>> include/uapi/linux/kvm.h | 10 ++++++++++ > >>>>>> 2 files changed, 19 insertions(+), 0 deletions(-) > >>>>>> > >>>>>> diff --git a/Documentation/virtual/kvm/devices/vfio.txt > >>> b/Documentation/virtual/kvm/devices/vfio.txt > >>>>>> index f7aff29..39dee86 100644 > >>>>>> --- a/Documentation/virtual/kvm/devices/vfio.txt > >>>>>> +++ b/Documentation/virtual/kvm/devices/vfio.txt > >>>>>> @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has been > >>> called to trigger the IRQ > >>>>>> or associate an eventfd to it. Unforwarding can only be called while the > >>>>>> signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this > >>> condition is > >>>>>> not satisfied, the command returns an -EBUSY. > >>>>>> + > >>>>>> + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups > >>> mechanism to post > >>>>>> + the IRQ to guests. > >>>>>> +For this attribute, kvm_device_attr.addr points to a kvm_posted_intr > >>> struct. > >>>>>> + > >>>>>> +When guest OS changes the interrupt configuration for an assigned > >>> device, > >>>>>> +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute > >>>>>> +to tell KVM to update the related IRTE according the VT-d > >>> Posted-Interrrupts > >>>>>> +Specification, such as, the guest vector should be updated in the related > >>> IRTE. > >>>>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > >>>>>> index a269a42..e5f86ad 100644 > >>>>>> --- a/include/uapi/linux/kvm.h > >>>>>> +++ b/include/uapi/linux/kvm.h > >>>>>> @@ -949,6 +949,7 @@ struct kvm_device_attr { > >>>>>> #define KVM_DEV_VFIO_DEVICE 2 > >>>>>> #define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1 > >>>>>> #define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ 2 > >>>>>> +#define KVM_DEV_VFIO_DEVICE_POSTING_IRQ 3 > >>>>>> > >>>>>> enum kvm_device_type { > >>>>>> KVM_DEV_TYPE_FSL_MPIC_20 = 1, > >>>>>> @@ -973,6 +974,15 @@ struct kvm_arch_forwarded_irq { > >>>>>> __u32 gsi; /* gsi, ie. virtual IRQ number */ > >>>>>> }; > >>>>>> > >>> Hi Feng, Alex, > >>> I am currently reworking my code to use something closer to this struct. > >>> Would you agree with following changes? > >>>>>> +struct kvm_posted_intr { > >>> kvm_posted_irq > >> > >> Hi Alex, > >> > >> Do you mean changing the structure name to "kvm_posted_irq"? I am okay > >> If you think this name is also suitable for ARM forwarded irq. Or we can find > >> a more common name, such as "struct kvm_accel_irq", what is your opinion, Alex? > > > > I'd think something like struct kvm_vfio_dev_irq describes it fairly > > well. > ok for that name > > > >>>>>> + __u32 argsz; > >>>>>> + __u32 fd; /* file descriptor of the VFIO device */ > >>>>>> + __u32 index; /* VFIO device IRQ index */ > >>>>>> + __u32 start; > >>>>>> + __u32 count; > >>>>>> + int virq[0]; /* gsi, ie. virtual IRQ number */ > >>> __u32 gsi[]; > >> > >> I think this change is okay to me. If Alex also agree, I will follow this in the > >> next post. > >> > >>>>>> +}; > >>>>> Hi Feng, > >>>>> > >>>>> This struct could be used by arm code too. If Alex agrees I could use > >>>>> that one instead. We just need to find a common sensible name > >>>> > >>>> Yep, the interface might as well support batch setup. The vfio code > >>>> uses -1 for teardown if we want to avoid FORWARD vs UNFORWARD we could > >>>> let the data in the structure define which operation to do. > >>> > >>> In case we remove the unforward and use fd=1 to tear down, the virq=gsi > >>> must uniquely identify the struct. For ARM I think this is true, we > >>> cannot have several physical IRQ forwarded to the same GSI. I don't know > >>> about posted irqs or other archs. > > > > It makes more sense to me that fd is the real vfio_device fd that we > > uniquely match to existing forwarded/posted IRQs by > > {vfio_device,index,start[count]}. If gsi was then signed, passing -1 > > could be used to teardown that forward/posting. Passing fd=1, ie. > > stdout, is pretty non-intuitive to me. Thanks, > sorry meant fd = -1 (typo) as in the original VFIO API. Personally I > think I would prefer keeping the UNFORWARD but I will follow your guidance. If fd=-1 we can't uniquely identify the device and irq when there are multiple devices. I'm not necessarily opposed to an UNFORWARD, just show how it works better or more cleanly in the code. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/02/2014 05:02 PM, Alex Williamson wrote: > On Tue, 2014-12-02 at 08:52 +0100, Eric Auger wrote: >> On 12/02/2014 05:48 AM, Alex Williamson wrote: >>> On Tue, 2014-12-02 at 02:08 +0000, Wu, Feng wrote: >>>> >>>>> -----Original Message----- >>>>> From: Eric Auger [mailto:eric.auger@linaro.org] >>>>> Sent: Monday, December 01, 2014 6:10 PM >>>>> To: Alex Williamson >>>>> Cc: Wu, Feng; pbonzini@redhat.com; gleb@kernel.org; kvm@vger.kernel.org >>>>> Subject: Re: [RFC PATCH v2 1/2] KVM: kvm-vfio: User API for VT-d >>>>> Posted-Interrupts >>>>> >>>>> On 11/25/2014 05:10 PM, Alex Williamson wrote: >>>>>> On Tue, 2014-11-25 at 16:01 +0100, Eric Auger wrote: >>>>>>> On 11/25/2014 01:23 PM, Feng Wu wrote: >>>>>>>> This patch adds and documents a new attribute >>>>>>>> KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE >>>>> group. >>>>>>>> This new attribute is used for VT-d Posted-Interrupts. >>>>>>>> >>>>>>>> When guest OS changes the interrupt configuration for an >>>>>>>> assigned device, such as, MSI/MSIx data/address fields, >>>>>>>> QEMU will use this IRQ attribute to tell KVM to update the >>>>>>>> related IRTE according the VT-d Posted-Interrrupts Specification, >>>>>>>> such as, the guest vector should be updated in the related IRTE. >>>>>>>> >>>>>>>> Signed-off-by: Feng Wu <feng.wu@intel.com> >>>>>>>> --- >>>>>>>> Documentation/virtual/kvm/devices/vfio.txt | 9 +++++++++ >>>>>>>> include/uapi/linux/kvm.h | 10 ++++++++++ >>>>>>>> 2 files changed, 19 insertions(+), 0 deletions(-) >>>>>>>> >>>>>>>> diff --git a/Documentation/virtual/kvm/devices/vfio.txt >>>>> b/Documentation/virtual/kvm/devices/vfio.txt >>>>>>>> index f7aff29..39dee86 100644 >>>>>>>> --- a/Documentation/virtual/kvm/devices/vfio.txt >>>>>>>> +++ b/Documentation/virtual/kvm/devices/vfio.txt >>>>>>>> @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has been >>>>> called to trigger the IRQ >>>>>>>> or associate an eventfd to it. Unforwarding can only be called while the >>>>>>>> signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this >>>>> condition is >>>>>>>> not satisfied, the command returns an -EBUSY. >>>>>>>> + >>>>>>>> + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups >>>>> mechanism to post >>>>>>>> + the IRQ to guests. >>>>>>>> +For this attribute, kvm_device_attr.addr points to a kvm_posted_intr >>>>> struct. >>>>>>>> + >>>>>>>> +When guest OS changes the interrupt configuration for an assigned >>>>> device, >>>>>>>> +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute >>>>>>>> +to tell KVM to update the related IRTE according the VT-d >>>>> Posted-Interrrupts >>>>>>>> +Specification, such as, the guest vector should be updated in the related >>>>> IRTE. >>>>>>>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >>>>>>>> index a269a42..e5f86ad 100644 >>>>>>>> --- a/include/uapi/linux/kvm.h >>>>>>>> +++ b/include/uapi/linux/kvm.h >>>>>>>> @@ -949,6 +949,7 @@ struct kvm_device_attr { >>>>>>>> #define KVM_DEV_VFIO_DEVICE 2 >>>>>>>> #define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1 >>>>>>>> #define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ 2 >>>>>>>> +#define KVM_DEV_VFIO_DEVICE_POSTING_IRQ 3 >>>>>>>> >>>>>>>> enum kvm_device_type { >>>>>>>> KVM_DEV_TYPE_FSL_MPIC_20 = 1, >>>>>>>> @@ -973,6 +974,15 @@ struct kvm_arch_forwarded_irq { >>>>>>>> __u32 gsi; /* gsi, ie. virtual IRQ number */ >>>>>>>> }; >>>>>>>> >>>>> Hi Feng, Alex, >>>>> I am currently reworking my code to use something closer to this struct. >>>>> Would you agree with following changes? >>>>>>>> +struct kvm_posted_intr { >>>>> kvm_posted_irq >>>> >>>> Hi Alex, >>>> >>>> Do you mean changing the structure name to "kvm_posted_irq"? I am okay >>>> If you think this name is also suitable for ARM forwarded irq. Or we can find >>>> a more common name, such as "struct kvm_accel_irq", what is your opinion, Alex? >>> >>> I'd think something like struct kvm_vfio_dev_irq describes it fairly >>> well. >> ok for that name >>> >>>>>>>> + __u32 argsz; >>>>>>>> + __u32 fd; /* file descriptor of the VFIO device */ >>>>>>>> + __u32 index; /* VFIO device IRQ index */ >>>>>>>> + __u32 start; >>>>>>>> + __u32 count; >>>>>>>> + int virq[0]; /* gsi, ie. virtual IRQ number */ >>>>> __u32 gsi[]; >>>> >>>> I think this change is okay to me. If Alex also agree, I will follow this in the >>>> next post. >>>> >>>>>>>> +}; >>>>>>> Hi Feng, >>>>>>> >>>>>>> This struct could be used by arm code too. If Alex agrees I could use >>>>>>> that one instead. We just need to find a common sensible name >>>>>> >>>>>> Yep, the interface might as well support batch setup. The vfio code >>>>>> uses -1 for teardown if we want to avoid FORWARD vs UNFORWARD we could >>>>>> let the data in the structure define which operation to do. >>>>> >>>>> In case we remove the unforward and use fd=1 to tear down, the virq=gsi >>>>> must uniquely identify the struct. For ARM I think this is true, we >>>>> cannot have several physical IRQ forwarded to the same GSI. I don't know >>>>> about posted irqs or other archs. >>> >>> It makes more sense to me that fd is the real vfio_device fd that we >>> uniquely match to existing forwarded/posted IRQs by >>> {vfio_device,index,start[count]}. If gsi was then signed, passing -1 >>> could be used to teardown that forward/posting. Passing fd=1, ie. >>> stdout, is pretty non-intuitive to me. Thanks, >> sorry meant fd = -1 (typo) as in the original VFIO API. Personally I >> think I would prefer keeping the UNFORWARD but I will follow your guidance. > > If fd=-1 we can't uniquely identify the device and irq when there are > multiple devices. I'm not necessarily opposed to an UNFORWARD, just > show how it works better or more cleanly in the code. Thanks, OK thanks. Eric > > Alex > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/virtual/kvm/devices/vfio.txt b/Documentation/virtual/kvm/devices/vfio.txt index f7aff29..39dee86 100644 --- a/Documentation/virtual/kvm/devices/vfio.txt +++ b/Documentation/virtual/kvm/devices/vfio.txt @@ -42,3 +42,12 @@ activated before VFIO_DEVICE_SET_IRQS has been called to trigger the IRQ or associate an eventfd to it. Unforwarding can only be called while the signaling has been disabled with VFIO_DEVICE_SET_IRQS. If this condition is not satisfied, the command returns an -EBUSY. + + KVM_DEV_VFIO_DEVICE_POSTING_IRQ: Use posted interrtups mechanism to post + the IRQ to guests. +For this attribute, kvm_device_attr.addr points to a kvm_posted_intr struct. + +When guest OS changes the interrupt configuration for an assigned device, +such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute +to tell KVM to update the related IRTE according the VT-d Posted-Interrrupts +Specification, such as, the guest vector should be updated in the related IRTE. diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index a269a42..e5f86ad 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -949,6 +949,7 @@ struct kvm_device_attr { #define KVM_DEV_VFIO_DEVICE 2 #define KVM_DEV_VFIO_DEVICE_FORWARD_IRQ 1 #define KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ 2 +#define KVM_DEV_VFIO_DEVICE_POSTING_IRQ 3 enum kvm_device_type { KVM_DEV_TYPE_FSL_MPIC_20 = 1, @@ -973,6 +974,15 @@ struct kvm_arch_forwarded_irq { __u32 gsi; /* gsi, ie. virtual IRQ number */ }; +struct kvm_posted_intr { + __u32 argsz; + __u32 fd; /* file descriptor of the VFIO device */ + __u32 index; /* VFIO device IRQ index */ + __u32 start; + __u32 count; + int virq[0]; /* gsi, ie. virtual IRQ number */ +}; + /* * ioctls for VM fds */
This patch adds and documents a new attribute KVM_DEV_VFIO_DEVICE_POSTING_IRQ in KVM_DEV_VFIO_DEVICE group. This new attribute is used for VT-d Posted-Interrupts. When guest OS changes the interrupt configuration for an assigned device, such as, MSI/MSIx data/address fields, QEMU will use this IRQ attribute to tell KVM to update the related IRTE according the VT-d Posted-Interrrupts Specification, such as, the guest vector should be updated in the related IRTE. Signed-off-by: Feng Wu <feng.wu@intel.com> --- Documentation/virtual/kvm/devices/vfio.txt | 9 +++++++++ include/uapi/linux/kvm.h | 10 ++++++++++ 2 files changed, 19 insertions(+), 0 deletions(-)