From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: KVM handling external interrupts Date: Sun, 10 Jun 2012 14:16:11 +0200 Message-ID: <4FD4900B.6030306@web.de> References: <4FD062BC.5090703@web.de> <4FD06E27.9020201@web.de> <4FD087A7.8000508@web.de> <4FD08C28.9070600@web.de> <4FD09A6C.4000601@web.de> <4FD0C353.7030707@web.de> <4FD473E1.6070302@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBDF5D3D0B3B69199A8964000" Cc: Alex Landau , Dan Tsafrir , sheng qiu , kvm , kvm-owner@vger.kernel.org, Muli Ben-Yehuda , Nadav Har'El , Nadav Amit To: Abel Gordon Return-path: Received: from mout.web.de ([212.227.17.11]:57540 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752238Ab2FJMQU (ORCPT ); Sun, 10 Jun 2012 08:16:20 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBDF5D3D0B3B69199A8964000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-06-10 12:43, Abel Gordon wrote: >=20 >=20 > kvm-owner@vger.kernel.org wrote on 10/06/2012 13:16:01: >=20 >>> Yep, these are corner cases we should deal with but they are not part= >>> of the common case/critical path. >>> >>>> I'm wondering if redirecting (to different cores) or masking (at >>>> device/IOAPIC/LAPIC level) of non-guest interrupts and only relying = on >>>> preemption timer/NMI isn't simpler. Then you wouldn't have to shadow= > the >>>> IDT. >>> >>> Yep, as we suggested in the paper, that could be also an alternative.= >>> Is it really simpler ? Again, depends who you ask and what you need t= o >>> change. >>> All the alternatives have a set of pros and cons. >>> >> For sure. But avoiding the shadow IDT would likely mean avoiding >> userspace changes for KVM. And that means simplification. And avoid PC= I >> dependencies. >=20 > But you lose flexibility. Remember that if you don't shadow the IDT > you need at least one dedicated core that never uses ELI to handle > all the physical interrupts. With the shadow IDT, you could enable > ELI in all the cores. You need to program the preemption timer anyway. Once you leave some guest due to its expiry, you will re-enable the host IRQs and process the= m. > In addition, if you don't use the shadow IDT, host interrupts will not > be balanced across all the ELI cores. Thus, if you run many VMs/VCPU, y= ou > might experience higher latency/bottlenecks or have scalability > problems unless you use a shadow IDT (depending on the workload, > offcourse). That might be an issue. My feeling is software-based ELI could be a transitional feature (until hardware supports it properly) and may focus more on static setups where you have dedicated cores for guests and separated I/O processing. In any case, I would suggest to start small, mostly self-contained, ie. with changes that stay within KVM as far as possible. If that is accepted, you could suggest more sophisticated mechanisms on top, addressing more use cases. Jan --------------enigBDF5D3D0B3B69199A8964000 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/ iEYEARECAAYFAk/UkAsACgkQitSsb3rl5xRLAACgxy1sIy4D8p8kSi5HrdVK2iNz XlgAnjq4hUWYjrmtnmplQM8Jbie3WKDW =3fOg -----END PGP SIGNATURE----- --------------enigBDF5D3D0B3B69199A8964000--