From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: [PATCHv2 1 of 2] Move IOMMU faults handling into softirq for VT-d. Date: Thu, 05 Jan 2012 16:25:49 +0100 Message-ID: <1325777149.2728.9.camel@Solace> References: <1325776241.2728.5.camel@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9181086115744466247==" Return-path: In-Reply-To: <1325776241.2728.5.camel@Solace> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: Wei Wang2 , Tim Deegan , "allen.m.kay@intel.com" , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============9181086115744466247== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-gcfNY/9wlfpQGHGqP8uB" --=-gcfNY/9wlfpQGHGqP8uB Content-Type: multipart/mixed; boundary="=-xL9D24flhr5EjzYrrouw" --=-xL9D24flhr5EjzYrrouw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dealing with interrupts from VT-d IOMMU(s) is deferred to a softirq-tasklet= , raised by the actual IRQ handler. Since a new interrupt is not generated, even if further faults occur, until we cleared all the pending ones, there's no need of disabling IRQs, as the hardware does it by its own. Notice that this may cause the log to overflow, but none of the existing entry will be overwritten. Signed-off-by: Dario Faggioli diff -r efaa28639a71 xen/drivers/passthrough/vtd/iommu.c --- a/xen/drivers/passthrough/vtd/iommu.c Wed Jan 04 16:12:44 2012 +0000 +++ b/xen/drivers/passthrough/vtd/iommu.c Thu Jan 05 15:17:47 2012 +0100 @@ -53,6 +53,8 @@ bool_t __read_mostly untrusted_msi; =20 int nr_iommus; =20 +static struct tasklet vtd_fault_tasklet; + static void setup_dom0_device(struct pci_dev *); static void setup_dom0_rmrr(struct domain *d); =20 @@ -918,10 +920,8 @@ static void iommu_fault_status(u32 fault } =20 #define PRIMARY_FAULT_REG_LEN (16) -static void iommu_page_fault(int irq, void *dev_id, - struct cpu_user_regs *regs) +static void __do_iommu_page_fault(struct iommu *iommu) { - struct iommu *iommu =3D dev_id; int reg, fault_index; u32 fault_status; unsigned long flags; @@ -996,6 +996,37 @@ clear_overflow: } } =20 +static void do_iommu_page_fault(unsigned long data) +{ + struct acpi_drhd_unit *drhd; + + if ( list_empty(&acpi_drhd_units) ) + { + INTEL_IOMMU_DEBUG("no device found, something must be very wrong!\n= "); + return; + } + + /* + * No matter from whom the interrupt came from, check all the + * IOMMUs present in the system. This allows for having just one + * tasklet (instead of one per each IOMMUs) and should be more than + * fine, considering how rare the event of a fault should be. + */ + for_each_drhd_unit ( drhd ) + __do_iommu_page_fault(drhd->iommu); +} + +static void iommu_page_fault(int irq, void *dev_id, + struct cpu_user_regs *regs) +{ + /* + * Just flag the tasklet as runnable. This is fine, according to VT-d + * specs since a new interrupt won't be generated until we clear all + * the faults that caused this one to happen. + */ + tasklet_schedule(&vtd_fault_tasklet); +} + static void dma_msi_unmask(struct irq_desc *desc) { struct iommu *iommu =3D desc->action->dev_id; @@ -2144,6 +2175,8 @@ int __init intel_vtd_setup(void) iommu->irq =3D ret; } =20 + softirq_tasklet_init(&vtd_fault_tasklet, do_iommu_page_fault, 0); + if ( !iommu_qinval && iommu_intremap ) { iommu_intremap =3D 0; --=20 <> (Raistlin Majere) ------------------------------------------------------------------- Dario Faggioli, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy) --=-xL9D24flhr5EjzYrrouw Content-Disposition: attachment; filename="iommu-fault-tasklet_vtd.patch" Content-Type: text/x-patch; name="iommu-fault-tasklet_vtd.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGVmYWEyODYzOWE3MTUyNGE2OTNiYTUwMDYy NGY4NTEyZTU3OTVlMTgNCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm b3IgVlQtZC4NCg0KRGVhbGluZyB3aXRoIGludGVycnVwdHMgZnJvbSBWVC1kIElPTU1VKHMpIGlz IGRlZmVycmVkIHRvIGEgc29mdGlycS10YXNrbGV0LA0KcmFpc2VkIGJ5IHRoZSBhY3R1YWwgSVJR IGhhbmRsZXIuIFNpbmNlIGEgbmV3IGludGVycnVwdCBpcyBub3QgZ2VuZXJhdGVkLA0KZXZlbiBp ZiBmdXJ0aGVyIGZhdWx0cyBvY2N1ciwgdW50aWwgd2UgY2xlYXJlZCBhbGwgdGhlIHBlbmRpbmcg b25lcywNCnRoZXJlJ3Mgbm8gbmVlZCBvZiBkaXNhYmxpbmcgSVJRcywgYXMgdGhlIGhhcmR3YXJl IGRvZXMgaXQgYnkgaXRzIG93bi4NCk5vdGljZSB0aGF0IHRoaXMgbWF5IGNhdXNlIHRoZSBsb2cg dG8gb3ZlcmZsb3csIGJ1dCBub25lIG9mIHRoZSBleGlzdGluZw0KZW50cnkgd2lsbCBiZSBvdmVy d3JpdHRlbi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xp QGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgZWZhYTI4NjM5YTcxIHhlbi9kcml2ZXJzL3Bhc3N0aHJv dWdoL3Z0ZC9pb21tdS5jDQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC92dGQvaW9tbXUu YwlXZWQgSmFuIDA0IDE2OjEyOjQ0IDIwMTIgKzAwMDANCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0 aHJvdWdoL3Z0ZC9pb21tdS5jCVRodSBKYW4gMDUgMTU6MTc6NDcgMjAxMiArMDEwMA0KQEAgLTUz LDYgKzUzLDggQEAgYm9vbF90IF9fcmVhZF9tb3N0bHkgdW50cnVzdGVkX21zaTsNCiANCiBpbnQg bnJfaW9tbXVzOw0KIA0KK3N0YXRpYyBzdHJ1Y3QgdGFza2xldCB2dGRfZmF1bHRfdGFza2xldDsN CisNCiBzdGF0aWMgdm9pZCBzZXR1cF9kb20wX2RldmljZShzdHJ1Y3QgcGNpX2RldiAqKTsNCiBz dGF0aWMgdm9pZCBzZXR1cF9kb20wX3JtcnIoc3RydWN0IGRvbWFpbiAqZCk7DQogDQpAQCAtOTE4 LDEwICs5MjAsOCBAQCBzdGF0aWMgdm9pZCBpb21tdV9mYXVsdF9zdGF0dXModTMyIGZhdWx0DQog fQ0KIA0KICNkZWZpbmUgUFJJTUFSWV9GQVVMVF9SRUdfTEVOICgxNikNCi1zdGF0aWMgdm9pZCBp b21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCi0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3N0YXRpYyB2b2lkIF9f ZG9faW9tbXVfcGFnZV9mYXVsdChzdHJ1Y3QgaW9tbXUgKmlvbW11KQ0KIHsNCi0gICAgc3RydWN0 IGlvbW11ICppb21tdSA9IGRldl9pZDsNCiAgICAgaW50IHJlZywgZmF1bHRfaW5kZXg7DQogICAg IHUzMiBmYXVsdF9zdGF0dXM7DQogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQpAQCAtOTk2LDYg Kzk5NiwzNyBAQCBjbGVhcl9vdmVyZmxvdzoNCiAgICAgfQ0KIH0NCiANCitzdGF0aWMgdm9pZCBk b19pb21tdV9wYWdlX2ZhdWx0KHVuc2lnbmVkIGxvbmcgZGF0YSkNCit7DQorICAgIHN0cnVjdCBh Y3BpX2RyaGRfdW5pdCAqZHJoZDsNCisNCisgICAgaWYgKCBsaXN0X2VtcHR5KCZhY3BpX2RyaGRf dW5pdHMpICkNCisgICAgew0KKyAgICAgICBJTlRFTF9JT01NVV9ERUJVRygibm8gZGV2aWNlIGZv dW5kLCBzb21ldGhpbmcgbXVzdCBiZSB2ZXJ5IHdyb25nIVxuIik7DQorICAgICAgIHJldHVybjsN CisgICAgfQ0KKw0KKyAgICAvKg0KKyAgICAgKiBObyBtYXR0ZXIgZnJvbSB3aG9tIHRoZSBpbnRl cnJ1cHQgY2FtZSBmcm9tLCBjaGVjayBhbGwgdGhlDQorICAgICAqIElPTU1VcyBwcmVzZW50IGlu IHRoZSBzeXN0ZW0uIFRoaXMgYWxsb3dzIGZvciBoYXZpbmcganVzdCBvbmUNCisgICAgICogdGFz a2xldCAoaW5zdGVhZCBvZiBvbmUgcGVyIGVhY2ggSU9NTVVzKSBhbmQgc2hvdWxkIGJlIG1vcmUg dGhhbg0KKyAgICAgKiBmaW5lLCBjb25zaWRlcmluZyBob3cgcmFyZSB0aGUgZXZlbnQgb2YgYSBm YXVsdCBzaG91bGQgYmUuDQorICAgICAqLw0KKyAgICBmb3JfZWFjaF9kcmhkX3VuaXQgKCBkcmhk ICkNCisgICAgICAgIF9fZG9faW9tbXVfcGFnZV9mYXVsdChkcmhkLT5pb21tdSk7DQorfQ0KKw0K K3N0YXRpYyB2b2lkIGlvbW11X3BhZ2VfZmF1bHQoaW50IGlycSwgdm9pZCAqZGV2X2lkLA0KKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQor ew0KKyAgICAvKg0KKyAgICAgKiBKdXN0IGZsYWcgdGhlIHRhc2tsZXQgYXMgcnVubmFibGUuIFRo aXMgaXMgZmluZSwgYWNjb3JkaW5nIHRvIFZULWQNCisgICAgICogc3BlY3Mgc2luY2UgYSBuZXcg aW50ZXJydXB0IHdvbid0IGJlIGdlbmVyYXRlZCB1bnRpbCB3ZSBjbGVhciBhbGwNCisgICAgICog dGhlIGZhdWx0cyB0aGF0IGNhdXNlZCB0aGlzIG9uZSB0byBoYXBwZW4uDQorICAgICAqLw0KKyAg ICB0YXNrbGV0X3NjaGVkdWxlKCZ2dGRfZmF1bHRfdGFza2xldCk7DQorfQ0KKw0KIHN0YXRpYyB2 b2lkIGRtYV9tc2lfdW5tYXNrKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykNCiB7DQogICAgIHN0cnVj dCBpb21tdSAqaW9tbXUgPSBkZXNjLT5hY3Rpb24tPmRldl9pZDsNCkBAIC0yMTQ0LDYgKzIxNzUs OCBAQCBpbnQgX19pbml0IGludGVsX3Z0ZF9zZXR1cCh2b2lkKQ0KICAgICAgICAgaW9tbXUtPmly cSA9IHJldDsNCiAgICAgfQ0KIA0KKyAgICBzb2Z0aXJxX3Rhc2tsZXRfaW5pdCgmdnRkX2ZhdWx0 X3Rhc2tsZXQsIGRvX2lvbW11X3BhZ2VfZmF1bHQsIDApOw0KKw0KICAgICBpZiAoICFpb21tdV9x aW52YWwgJiYgaW9tbXVfaW50cmVtYXAgKQ0KICAgICB7DQogICAgICAgICBpb21tdV9pbnRyZW1h cCA9IDA7DQo= --=-xL9D24flhr5EjzYrrouw-- --=-gcfNY/9wlfpQGHGqP8uB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk8FwP0ACgkQk4XaBE3IOsTRVQCghCdZs4JXMr/QestWJluTBOZh ZwIAnjHKDto1HNMtVzLbQL5KHFfwHZPt =Qa6U -----END PGP SIGNATURE----- --=-gcfNY/9wlfpQGHGqP8uB-- --===============9181086115744466247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============9181086115744466247==--