From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: KVM handling external interrupts Date: Thu, 07 Jun 2012 12:51:19 +0200 Message-ID: <4FD087A7.8000508@web.de> References: <4FD062BC.5090703@web.de> <4FD06E27.9020201@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC01154F6833A9DCB7BD371CE" 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]:53492 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760616Ab2FGKvV (ORCPT ); Thu, 7 Jun 2012 06:51:21 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC01154F6833A9DCB7BD371CE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-06-07 12:47, Abel Gordon wrote: >=20 >=20 > Jan Kiszka wrote on 07/06/2012 12:02:31: >=20 >>>> Yes, that's exactly something we already did in a research project. >>>> You can read our paper published in ASPLOS 2012: ELI: Bare-metal >>>> performance for I/O virtualization >>>> ( >>>> http://dl.acm.org/citation.cfm? >> id=3D2151020&dl=3DACM&coll=3DDL&CFID=3D86701665&CFTOKEN=3D26302003 >>> >>> Interesting. Can you provide it publicly (or send a version privately= )? >> >> Sorry, should have googled first: >> >> http://www.mulix.org/pubs/eli/eli.pdf :) > np ;) >=20 >>>> Note this is not so simple, there are many other issues you should >>>> consider. >>> >>> Is it just complicated, not upstreamable, or are the unsolved issues >>> like security holes or the need to paravirtualize the guest? >> >> My first feeling is that it's not easily upstreamable due to the need = to >> fiddle with the host's IDT, specifically on VCPU task migration. But I= >> need to read the requirements of this more carefully. Still interestin= g >> work! >=20 > You don't need to fiddle with the host's IDT, you need to fiddle with > the shadow IDT and interrupt vector mapping/remapping. Yes, but you need to sync the host IDT into the shadow table. This may require some hooks in generic code to avoid scanning the host table on each guest entry. 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? Jan --------------enigC01154F6833A9DCB7BD371CE 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/Qh6cACgkQitSsb3rl5xQIxwCg30I/ioAEGZKpcu3c3nzZvUSA ARAAn2cnFtcxY8O8Zeax463REk8D4M36 =2+bC -----END PGP SIGNATURE----- --------------enigC01154F6833A9DCB7BD371CE--