From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: PATCH 1 of 2] Move IOMMU faults handling into softirq for VT-d. Date: Mon, 19 Dec 2011 19:51:55 +0100 Message-ID: <1324320715.2599.32.camel@Solace> References: <1324319661.2599.28.camel@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5204897851634191203==" Return-path: In-Reply-To: <1324319661.2599.28.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 --===============5204897851634191203== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-KOxJmKa6mImcn2Kq8wTn" --=-KOxJmKa6mImcn2Kq8wTn Content-Type: multipart/mixed; boundary="=-N6yQoollE8RdEVw5lITS" --=-N6yQoollE8RdEVw5lITS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dealing with interrupts from VT-d IOMMU 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 to 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 a4bffc85bb71 xen/drivers/passthrough/vtd/iommu.c --- a/xen/drivers/passthrough/vtd/iommu.c Mon Dec 19 09:37:52 2011 +0100 +++ b/xen/drivers/passthrough/vtd/iommu.c Mon Dec 19 16:46:14 2011 +0000 @@ -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,33 @@ 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 IOMMU) 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 +2171,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) --=-N6yQoollE8RdEVw5lITS Content-Disposition: attachment; filename="iommu-fault-tasklet_vtd.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="iommu-fault-tasklet_vtd.patch"; charset="UTF-8" IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGU1YjEyNDg4ZjA3ZWJiOTVlZWM2Y2FmNjE1 MGYwZWRmNTgxNTc0OTQNCg0KZGlmZiAtciBlNWIxMjQ4OGYwN2UgeGVuL2RyaXZlcnMvcGFzc3Ro cm91Z2gvdnRkL2lvbW11LmMNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3Z0ZC9pb21t dS5jCVR1ZSBEZWMgMTMgMTc6Mjk6MTIgMjAxMSArMDEwMA0KKysrIGIveGVuL2RyaXZlcnMvcGFz c3Rocm91Z2gvdnRkL2lvbW11LmMJV2VkIERlYyAxNCAxMDowODo0NSAyMDExICswMTAwDQpAQCAt OTE4LDEwICs5MTgsOSBAQCBzdGF0aWMgdm9pZCBpb21tdV9mYXVsdF9zdGF0dXModTMyIGZhdWx0 DQogfQ0KIA0KICNkZWZpbmUgUFJJTUFSWV9GQVVMVF9SRUdfTEVOICgxNikNCi1zdGF0aWMgdm9p ZCBpb21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCi0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3N0YXRpYyB2b2lk IGRvX2lvbW11X3BhZ2VfZmF1bHQodW5zaWduZWQgbG9uZyBpb21tdV9wdHIpDQogew0KLSAgICBz dHJ1Y3QgaW9tbXUgKmlvbW11ID0gZGV2X2lkOw0KKyAgICBzdHJ1Y3QgaW9tbXUgKmlvbW11ID0g KHN0cnVjdCBpb21tdSopIGlvbW11X3B0cjsNCiAgICAgaW50IHJlZywgZmF1bHRfaW5kZXg7DQog ICAgIHUzMiBmYXVsdF9zdGF0dXM7DQogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQpAQCAtOTk2 LDYgKzk5NSwxNCBAQCBjbGVhcl9vdmVyZmxvdzoNCiAgICAgfQ0KIH0NCiANCitzdGF0aWMgdm9p ZCBpb21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3sNCisgICAgc3Ry dWN0IGlvbW11ICppb21tdSA9IGRldl9pZDsNCisNCisgICAgdGFza2xldF9zY2hlZHVsZSgmaW9t bXUtPmZhdWx0X3Rhc2tsZXQpOw0KK30NCisNCiBzdGF0aWMgdm9pZCBkbWFfbXNpX3VubWFzayhz dHJ1Y3QgaXJxX2Rlc2MgKmRlc2MpDQogew0KICAgICBzdHJ1Y3QgaW9tbXUgKmlvbW11ID0gZGVz Yy0+YWN0aW9uLT5kZXZfaWQ7DQpAQCAtMjE0Miw2ICsyMTQ5LDkgQEAgaW50IF9faW5pdCBpbnRl bF92dGRfc2V0dXAodm9pZCkNCiAgICAgICAgICAgICBnb3RvIGVycm9yOw0KICAgICAgICAgfQ0K ICAgICAgICAgaW9tbXUtPmlycSA9IHJldDsNCisNCisgICAgICAgIHNvZnRpcnFfdGFza2xldF9p bml0KCZpb21tdS0+ZmF1bHRfdGFza2xldCwgZG9faW9tbXVfcGFnZV9mYXVsdCwNCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICh1bnNpZ25lZCBsb25nKSBkcmhkLT5pb21tdSk7DQogICAg IH0NCiANCiAgICAgaWYgKCAhaW9tbXVfcWludmFsICYmIGlvbW11X2ludHJlbWFwICkNCmRpZmYg LXIgZTViMTI0ODhmMDdlIHhlbi9pbmNsdWRlL3hlbi9pb21tdS5oDQotLS0gYS94ZW4vaW5jbHVk ZS94ZW4vaW9tbXUuaAlUdWUgRGVjIDEzIDE3OjI5OjEyIDIwMTEgKzAxMDANCisrKyBiL3hlbi9p bmNsdWRlL3hlbi9pb21tdS5oCVdlZCBEZWMgMTQgMTA6MDg6NDUgMjAxMSArMDEwMA0KQEAgLTYz LDYgKzYzLDcgQEAgc3RydWN0IGlvbW11IHsNCiAgICAgc3BpbmxvY2tfdCByZWdpc3Rlcl9sb2Nr OyAvKiBwcm90ZWN0IGlvbW11IHJlZ2lzdGVyIGhhbmRsaW5nICovDQogICAgIHU2NCByb290X21h ZGRyOyAvKiByb290IGVudHJ5IG1hY2hpbmUgYWRkcmVzcyAqLw0KICAgICBpbnQgaXJxOw0KKyAg ICBzdHJ1Y3QgdGFza2xldCBmYXVsdF90YXNrbGV0Ow0KICAgICBzdHJ1Y3QgaW50ZWxfaW9tbXUg KmludGVsOw0KICAgICB1bnNpZ25lZCBsb25nICpkb21pZF9iaXRtYXA7ICAvKiBkb21haW4gaWQg Yml0bWFwICovDQogICAgIHUxNiAqZG9taWRfbWFwOyAgICAgICAgICAgICAgIC8qIGRvbWFpbiBp ZCBtYXBwaW5nIGFycmF5ICovDQo= --=-N6yQoollE8RdEVw5lITS-- --=-KOxJmKa6mImcn2Kq8wTn 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) iEUEABECAAYFAk7vh8sACgkQk4XaBE3IOsS7IwCfbQkr19Bo/V9bGKdzR0ELBcBJ i/YAmKHrmsp/3BwsegSYwZ1S3yJGMZI= =tT6g -----END PGP SIGNATURE----- --=-KOxJmKa6mImcn2Kq8wTn-- --===============5204897851634191203== 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 --===============5204897851634191203==--