From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v2 4/4] KVM: Allow host IRQ sharing for passed-through PCI 2.3 devices Date: Tue, 02 Nov 2010 20:56:21 +0100 Message-ID: <4CD06CE5.8000001@web.de> References: <70406157f1f29ade425369f82310a3963f0d0e97.1288712958.git.jan.kiszka@siemens.com> <20101102174149.GC1304@redhat.com> <4CD050BE.5010703@siemens.com> <20101102182401.GB1939@redhat.com> <4CD05B2E.1050005@siemens.com> <20101102185250.GC2341@redhat.com> <4CD06263.7080307@siemens.com> <20101102191430.GC2744@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8AF2463241C8466EEF17A4C6" Cc: Avi Kivity , Marcelo Tosatti , kvm , Alex Williamson To: "Michael S. Tsirkin" Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:50047 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750752Ab0KBT4b (ORCPT ); Tue, 2 Nov 2010 15:56:31 -0400 In-Reply-To: <20101102191430.GC2744@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8AF2463241C8466EEF17A4C6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 02.11.2010 20:14, Michael S. Tsirkin wrote: >>> BTW block userspace access uses a global spinlock which will likely h= urt >>> us on multi-CPU. Switching that to something more SMP friendly, e.g. = a >>> per-device spinlock, might be a good idea: I don't see why that lock = and >>> queue are global. >> >> Been through that code recently, hairy stuff. pci_lock also protects t= he >> bus operation which can be overloaded (e.g. for error injection - if >> that is not the only use case). So we need a per-bus lock, but that ca= n >> still cause contentions if devices on the same bus are handled on >> different cpus. >=20 > Right. So this lock got reused for blocking userspace, I do not suggest= > we rip it all out, just make userspace blocking use > a finer-grained lock. >=20 >> I think the whole PCI config interface is simply not designed for >> performance. It's considered a slow path, which it normally is. >=20 > So I guess we'll need to fix that now, at least if we > want to make the 2.3 way the default. >=20 On many systems (those with "direct" PCI config access), there is another lock down the road: pci_config_lock. That can't be broken up as the protected resource is unique. So we do not gain much improving the higher-level lock. BTW, accessing the interrupt controller for IRQ line fiddling is not a per-device thing either. So as long as the latency of the code under the locks is not significantly worse with PCI-level masking, we don't lose scalability here. Jan --------------enig8AF2463241C8466EEF17A4C6 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/ iEYEARECAAYFAkzQbOsACgkQitSsb3rl5xTr5ACeMQd4/7qVaxVPbNt1mKDdK5ob aXwAoMszUM07l+t68zSi+Dkxc/0IsOp7 =5sW9 -----END PGP SIGNATURE----- --------------enig8AF2463241C8466EEF17A4C6--