From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] IOMMU: don't disable bus mastering on faults for devices used by Xen or Dom0 Date: Tue, 6 Nov 2012 13:06:25 +0100 Message-ID: <1352203585.505.5.camel@Solace> References: <5097FD2902000078000A66BF@nat28.tlf.novell.com> <5098E19D02000078000A697A@nat28.tlf.novell.com> <20121106094456.GA45690@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7679863783174260802==" Return-path: In-Reply-To: <20121106094456.GA45690@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: Keir Fraser , wei.huang2@amd.com, xen-devel , Jan Beulich , weiwang.dd@gmail.com, xiantao.zhang@intel.com List-Id: xen-devel@lists.xenproject.org --===============7679863783174260802== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EKNA1l+QEyhzJYFv4W33" --=-EKNA1l+QEyhzJYFv4W33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-11-06 at 09:44 +0000, Tim Deegan wrote: > > In the context of analyzing the situation described in > > "iommu=3Ddom0-passthrough behavior" > > (http://lists.xen.org/archives/html/xen-devel/2012-11/msg00140.html) > > I suppressed the IOMMU setup for some device in Dom0, and > > was quite puzzled to find that only a single fault would occur. >=20 > I think it would be better to allow some small number of faults per > device before disabling it rather than give dom0 carte blanche. >=20 > This check is really there to stop a mad device from hosing the system > rather than to contain a malicious OS, and a properly out-of-control > device needs to be stopped or it will livelock Xen with iommu faults. > In a uniprocessor system, dom0 might never get the chance to fix it. >=20 Right. But moving the fault handling code to softirq should have already helped solving/mitigating that, hasn't it? When implementing and testing that, I wasn't able to reproduce any livelock situation (although I can't exclude that to be at least partly due to my inexperience, especially at the time, with I/O virtualization)... Jan, have you (after killing the 'disable bus-mastering part' of course)? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-EKNA1l+QEyhzJYFv4W33 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.12 (GNU/Linux) iEYEABECAAYFAlCY/UEACgkQk4XaBE3IOsQ1pQCbBluNzWKjNzntGZ4CPCFLt4mR iC4AniTNi3OIBScljLAnzZH7ymkHRJRh =v2EJ -----END PGP SIGNATURE----- --=-EKNA1l+QEyhzJYFv4W33-- --===============7679863783174260802== 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.xen.org http://lists.xen.org/xen-devel --===============7679863783174260802==--