From: Jan Kiszka Subject: Re: Device assignment, shared IRQs, uio_pci_generic Date: Sun, 31 Oct 2010 16:05:27 +0100 Message-ID: <4CCD85B7.1030904@web.de> References: <4CCC40A6.7080008@web.de> <1288458364.2893.16.camel@x201> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7E2C66F46F154654A767FA8C" Cc: "Michael S. Tsirkin" , kvm To: Alex Williamson Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:50752 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755137Ab0JaPFj (ORCPT ); Sun, 31 Oct 2010 11:05:39 -0400 In-Reply-To: <1288458364.2893.16.camel@x201> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7E2C66F46F154654A767FA8C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 30.10.2010 19:06, Alex Williamson wrote: > On Sat, 2010-10-30 at 17:58 +0200, Jan Kiszka wrote: >> Hi all, >> >> trying to pass some host device to a KVM guest (for driver hacking), I= >> ran into massive IRQ sharing issues on the host. Classic device >> assignment refuses to work in this case. I remembered uio_pci_generic,= >> which I thought was once designed to resolve this conflict. But it isn= 't >> used by KVM or qemu, is it? >=20 > Nope, VFIO started out being based on it, but has since branched off. > KVM has never made use of it. >=20 >> So I crossed fingers and hacked IRQF_SHARED into >> assigned_device_enable_host_intx. Effect as expected: assignment work,= >> host gets massive hick-ups (the graphic adapter is another user of thi= s >> line...). >> >> Are there already VFIO patches ready for testing that work with shared= >> IRQs as well? And/or would it make sense to integrate IRQ sharing via >> PCI-level IRQ masking to the KVM core until VFIO becomes standard? >=20 > There's a very old qemu VFIO patch floating around, but I plan to send > out a new one this week, thus all the pre-patches I've been sending out= =2E > Adding PCI 2.3 interrupt disable support to KVM should be very possible= , > and I suspect fairly easy. Oddly, I've just been adding support for > non-PCI 2.3 devices to VFIO so it can support all the old devices that > KVM does already. It wasn't that easy, and I'm still not 100% sure I did it all correctly: I just passed my SD card reader to a Linux guest which shares IRQ with five(!) other devices. That works well now (provided I disable SMIs - device pass-through appears to be another trigger for my SMI-related lockups under KVM, sigh). Still not working here are ehci, ath9k and e1000e when passed through. They receive IRQs, but somehow the Linux guest drivers are unhappy about the device states (the e1000e detects "Hardware Unit Hang" e.g.). This is independent of my patches. Anyone any ideas? Improper configurations of the BIOS? I stumbled over this in the kernel log: DMAR: BIOS has allocated no shadow GTT; disabling IOMMU for graphics There were a few flaws in the current device assignment code /wrt host IRQ type selection, both kernel and qemu-kvm are affected. Will try to sort all my stuff next to send out patches. Jan --------------enig7E2C66F46F154654A767FA8C 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.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkzNhcEACgkQitSsb3rl5xTgMgCgwDlHDwAPZnDEpdyBEkAvHUt4 uzsAn2KJIV3KngLJ+lKpeJHg6jtCzUSZ =USeb -----END PGP SIGNATURE----- --------------enig7E2C66F46F154654A767FA8C--