From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SDiXS-0000mb-FO for qemu-devel@nongnu.org; Fri, 30 Mar 2012 16:35:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SDiXQ-0008I0-Ff for qemu-devel@nongnu.org; Fri, 30 Mar 2012 16:35:14 -0400 Received: from fmmailgate07.web.de ([217.72.192.248]:50400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SDiXQ-0008H3-5j for qemu-devel@nongnu.org; Fri, 30 Mar 2012 16:35:12 -0400 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate07.web.de (Postfix) with ESMTP id 7CE05FE0FA7 for ; Fri, 30 Mar 2012 22:35:10 +0200 (CEST) Message-ID: <4F7618FC.7040807@web.de> Date: Fri, 30 Mar 2012 22:35:08 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <201203301918.q2UJI63c005908@int-mx02.intmail.prod.int.phx2.redhat.com> <4F760993.304@web.de> <20120330201313.GB2376@redhat.com> <4F761517.6010105@web.de> <20120330203140.GC2376@redhat.com> In-Reply-To: <20120330203140.GC2376@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig098EE37485B4514E5EB2582D" Subject: Re: [Qemu-devel] [PATCH] kvm: deassign irqs in reset path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Baron Cc: alex.williamson@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, mst@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig098EE37485B4514E5EB2582D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-03-30 22:31, Jason Baron wrote: > On Fri, Mar 30, 2012 at 10:18:31PM +0200, Jan Kiszka wrote: >>>>> The root cause of the problem is that the 'reset_assigned_device()'= code >>>>> first writes a 0 to the command register. Then, when qemu subsequen= tly does >>>>> a kvm_deassign_irq() (called by assign_irq(), in the system_reset p= ath), >>>>> the kernel ends up calling '__msix_mask_irq()', which performs a wr= ite to >>>>> the memory mapped msi vector space. Since, we've explicitly told th= e device >>>>> to disallow mmio access (via the 0 write to the command register), = we end >>>>> up with the above 'Unsupported Request'. >>>>> >>>>> The fix here is to first call kvm_deassign_irq(), before doing the = reset, >>>> >>>> s/fix/workaround/. This is a kernel bug if userspace can crash the >>>> system like this, no? Let's fix the kernel first and then look at wh= at >>>> needs to be changed here. >>>> >>>> Jan >>>> >>> >>> But don't I need special privalege to run the device assignment bits?= >> >> Yes, but even that might be moderated by a management component like >> libvirt. >> >>> For example, this crash is precipitated by a write of '0' to the pci >>> device config register from userspace. Surely, not every is allowed t= o >>> do that write. So it seems to me, that this patch is in keeping with = the >>> current model of how things work. >> >> No user should needlessly be able to crash the host by issuing valid >> commands in a special order. >> >> Jan >> >=20 > Right, but as I see device-assign.c, we are essentially programming the= > pci device directly from userspace. Put another way, the kernel could > crash the system if it programmed a pci device in the wrong order. So I= > don't see how this is different. But maybe I'm misunderstanding the > model here? The model is that the KVM device assignment subsystem in the kernel (or vfio in the future) + the IOMMU confine what userspace (not the qemu guest) can do with the device and prevent that any harm is caused to the system. There might be practical holes in this model, but this is still what we are striving for. Jan --------------enig098EE37485B4514E5EB2582D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk92GPwACgkQitSsb3rl5xQkWgCfXRhAREGcgFtdlMzQOkbXMRun N0UAoLclKjasGROLUEokzpj9tkBDsVN4 =k1jj -----END PGP SIGNATURE----- --------------enig098EE37485B4514E5EB2582D--