From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ry2bR-0002Yc-JO for qemu-devel@nongnu.org; Thu, 16 Feb 2012 09:46:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ry2bL-00039C-Gr for qemu-devel@nongnu.org; Thu, 16 Feb 2012 09:46:33 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:63089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ry2bL-000390-4p for qemu-devel@nongnu.org; Thu, 16 Feb 2012 09:46:27 -0500 Received: by pbbro12 with SMTP id ro12so3140985pbb.4 for ; Thu, 16 Feb 2012 06:46:25 -0800 (PST) Message-ID: <4F3D16BB.5060804@codemonkey.ws> Date: Thu, 16 Feb 2012 08:46:19 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4F2AB552.2070909@redhat.com> <20120205093723.GQ23536@redhat.com> <4F2E4F8B.8090504@redhat.com> <20120205095153.GA29265@redhat.com> <4F2EAFF6.7030006@codemonkey.ws> <4F2F9E89.7090607@redhat.com> <87vcnih5qt.fsf@rustcorp.com.au> <4F3BB59D.2020505@redhat.com> <4F3C2AC5.80400@codemonkey.ws> <20120216085741.GB19771@redhat.com> In-Reply-To: <20120216085741.GB19771@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Next gen kvm api List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel , Rusty Russell , linux-kernel , KVM list , Avi Kivity On 02/16/2012 02:57 AM, Gleb Natapov wrote: > On Wed, Feb 15, 2012 at 03:59:33PM -0600, Anthony Liguori wrote: >> On 02/15/2012 07:39 AM, Avi Kivity wrote: >>> On 02/07/2012 08:12 PM, Rusty Russell wrote: >>>>> I would really love to have this, but the problem is that we'd need a >>>>> general purpose bytecode VM with binding to some kernel APIs. The >>>>> bytecode VM, if made general enough to host more complicated devices, >>>>> would likely be much larger than the actual code we have in the kernel now. >>>> >>>> We have the ability to upload bytecode into the kernel already. It's in >>>> a great bytecode interpreted by the CPU itself. >>> >>> Unfortunately it's inflexible (has to come with the kernel) and open to >>> security vulnerabilities. >> >> I wonder if there's any reasonable way to run device emulation >> within the context of the guest. Could we effectively do something >> like SMM? >> >> For a given set of traps, reflect back into the guest quickly >> changing the visibility of the VGA region. It may require installing >> a new CR3 but maybe that wouldn't be so bad with VPIDs. >> > What will it buy us? Surely not speed. Entering a guest is not much > (if at all) faster than exiting to userspace and any non trivial > operation will require exit to userspace anyway, You can emulate the PIT/RTC entirely within the guest using kvmclock which doesn't require an additional exit to get the current time base. So instead of: 1) guest -> host kernel 2) host kernel -> userspace 3) implement logic using rdtscp via VDSO 4) userspace -> host kernel 5) host kernel -> guest You go: 1) guest -> host kernel 2) host kernel -> guest (with special CR3) 3) implement logic using rdtscp + kvmclock page 4) change CR3 within guest and RETI to VMEXIT source RIP Same basic concept as PS/2 emulation with SMM. Regards, Anthony Liguori