From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: KVM handling external interrupts Date: Thu, 07 Jun 2012 13:54:35 +0200 Message-ID: <4FD0967B.70807@web.de> References: <4FD062BC.5090703@web.de> <4FD06E27.9020201@web.de> <4FD087A7.8000508@web.de> <4FD08CE9.4070906@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig42A76239A3A53A802AE800B3" Cc: Alex Landau , Dan Tsafrir , sheng qiu , kvm , Muli Ben-Yehuda , Nadav Har'El , Nadav Amit To: Abel Gordon Return-path: Received: from mout.web.de ([212.227.17.11]:50327 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750743Ab2FGLyj (ORCPT ); Thu, 7 Jun 2012 07:54:39 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig42A76239A3A53A802AE800B3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-06-07 13:51, Abel Gordon wrote: >=20 >=20 > Jan Kiszka wrote on 07/06/2012 14:13:45: >=20 >>> Well, the shadow IDT only needs to be synced with interrupts coming > from >>> assigned devices. The rest of the entries doesn't matter, they just >>> generate an exception. Once they generate an exception, they are > delivered >>> through the host IDT. So, all you need to know are the vectors assign= ed >>> to the guest to build the shadow IDT. >> >> Not totally true. If the host decides to allocate some new vector that= >> collides with some guest usage, you need to rearrange the shadow IDT a= nd >> the physical IRQ routing. So you need to track what the host does. >=20 > Well, depends if you re-allocate the vector used by the guest or the ve= ctor > used by the host. Anyway, I think we understand each other :) KVM is just a subsystem of the Linux kernel, usually not involved in LAPIC vector allocations. Your suggestion would turn this around a bit. Not impossible, but expect some discussions. ;) Jan --------------enig42A76239A3A53A802AE800B3 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/QlnsACgkQitSsb3rl5xSf0gCeMyzyWD0ouxAw6jqr+kN5I8GW GuAAn1uDrmrAshJN7mu+A0HzQpab2nH1 =d7A6 -----END PGP SIGNATURE----- --------------enig42A76239A3A53A802AE800B3--