From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: KVM handling external interrupts Date: Thu, 07 Jun 2012 17:05:55 +0200 Message-ID: <4FD0C353.7030707@web.de> References: <4FD062BC.5090703@web.de> <4FD06E27.9020201@web.de> <4FD087A7.8000508@web.de> <4FD08C28.9070600@web.de> <4FD09A6C.4000601@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAAE5F0791C4F3F2871324CB9" 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.12]:63675 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761081Ab2FGPGB (ORCPT ); Thu, 7 Jun 2012 11:06:01 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAAE5F0791C4F3F2871324CB9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-06-07 14:25, Abel Gordon wrote: > Jan Kiszka wrote on 07/06/2012 15:11:24: >=20 >>> Am I missing something ? In your case, I assume, [virtual =3D logical= ] > and >>> [linear =3D linear] >>> or you are using some different semantics ? >> No, you are right, the descriptor tables run through paging as well. >=20 > Txs. Now that you understand your mistake, the discussion will be simpl= er. >=20 > > But how do you ensure that the shadow IDT is mapped where you expect= it? >=20 > First, I assume, you will agree with us that using the e820 as you > suggested doesn't help because we need mapped memory. >=20 > How ? As we described in the paper, we use the PCI BAR to obtain mapped= > memory. > Where ? Doesn't matter. We know the GPA of the BAR and just do a revers= e > translation to obtain the GVA. It remains a fragile approach: - host-side reverse translations may not return a stable result, thus may require to redo this step several times - the guest may decide to remove/disable the device you chose for appending the IDT - changing the real BAR size can confuse the guest, or it only maps what it requires of the real device That's why I consider it nasty. 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. Jan --------------enigAAE5F0791C4F3F2871324CB9 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/Qw1YACgkQitSsb3rl5xRvogCbB8j3bGMIAiyip1c7TNqMDTSV ABkAoJ2u2drnMHzc4E3psHDa38iywQ4y =ySJw -----END PGP SIGNATURE----- --------------enigAAE5F0791C4F3F2871324CB9--