From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: KVM handling external interrupts Date: Thu, 07 Jun 2012 14:11:24 +0200 Message-ID: <4FD09A6C.4000601@web.de> References: <4FD062BC.5090703@web.de> <4FD06E27.9020201@web.de> <4FD087A7.8000508@web.de> <4FD08C28.9070600@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig73BB63896BB8D78331007738" 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]:60619 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753647Ab2FGML3 (ORCPT ); Thu, 7 Jun 2012 08:11:29 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig73BB63896BB8D78331007738 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-06-07 13:49, Abel Gordon wrote: >=20 >=20 > Jan Kiszka wrote on 07/06/2012 14:10:32: >=20 >>> BTW, the shadow IDT has to be put in the guest address space, right? = So >>> we need to make it read-only for the guest? >> >> Just found your solution: Append to a PCI bar. That's nasty. Better >> reserve some memory via e820. There is a paravirtual channel from QEMU= >> to the BIOS to communicate such reservations. >=20 > We will take a look at e820 and consider your suggestion, thanks! > The PCI BAR worked well to obtain an "unused" and "mapped" memory area > for unmodified guests. >=20 > Nasty ? Well, as usual, depends who you ask and the alternatives you > compare with. > For us, it was an elegant and easy way to achieve the goal. It's nasty as it requires more interaction between KVM and the userspace hypervisor and relies on PCI, which has nothing to do with the x86 architecture. Consider you only want to forward non-PCI interrupts (e.g. the LAPIC timer) and have no assigned device... >=20 >> BTW, the IDTR holds a linear address, not a virtual one. Unless I >> misremember, there is no need to map the IDT via the page table. The >> processor will not consult it for reading its entries. >=20 > As I understand and as we noticed in our runs using ELI, the processor > uses the page tables to translate the IDTR (linear address) into physic= al > address (guest physical in this case). >=20 > (1) Logical addresses are converted to linear addresses using segments = (not > relevant in our case) > (2) Linear addresses are converted to physical addresses using page tab= les > (this is our case) >=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. But how do you ensure that the shadow IDT is mapped where you expect it? How do you detect where it is mapped? That reminds me of our KVM VAPIC and the hoops that code has to jump through to ensure this just for 32-bit XP guests... Jan --------------enig73BB63896BB8D78331007738 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/QmmwACgkQitSsb3rl5xTXagCgq1eqw/hfhHaMTZs/vYUZbNEU G1oAoMOpgiZgw1mba0GG356b0rZBBmyB =Pz32 -----END PGP SIGNATURE----- --------------enig73BB63896BB8D78331007738--