From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [RFC] Next gen kvm api Date: Wed, 08 Feb 2012 04:42:58 +1030 Message-ID: <87vcnih5qt.fsf@rustcorp.com.au> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: qemu-devel , linux-kernel , Gleb Natapov , KVM list To: Avi Kivity , Anthony Liguori Return-path: In-Reply-To: <4F2F9E89.7090607@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On Mon, 06 Feb 2012 11:34:01 +0200, Avi Kivity wrote: > On 02/05/2012 06:36 PM, Anthony Liguori wrote: > > If userspace had a way to upload bytecode to the kernel that was > > executed for a PIO operation, it could either pass the operation to > > userspace or handle it within the kernel when possible without taking > > a heavy weight exit. > > > > If the bytecode can access variables in a shared memory area, it could > > be pretty efficient to work with. > > > > This means that the kernel never has to deal with specific in-kernel > > devices but that userspace can accelerator as many of its devices as > > it sees fit. > > 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. If every user were emulating different machines, LPF this would make sense. Are they? Or should we write those helpers once, in C, and provide that for them. Cheers, Rusty. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756907Ab2BGUyg (ORCPT ); Tue, 7 Feb 2012 15:54:36 -0500 Received: from ozlabs.org ([203.10.76.45]:54626 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756509Ab2BGUye (ORCPT ); Tue, 7 Feb 2012 15:54:34 -0500 From: Rusty Russell To: Avi Kivity , Anthony Liguori Cc: Gleb Natapov , linux-kernel , KVM list , qemu-devel Subject: Re: [Qemu-devel] [RFC] Next gen kvm api In-Reply-To: <4F2F9E89.7090607@redhat.com> 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> User-Agent: Notmuch/0.6.1-1 (http://notmuchmail.org) Emacs/23.3.1 (i686-pc-linux-gnu) Date: Wed, 08 Feb 2012 04:42:58 +1030 Message-ID: <87vcnih5qt.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 06 Feb 2012 11:34:01 +0200, Avi Kivity wrote: > On 02/05/2012 06:36 PM, Anthony Liguori wrote: > > If userspace had a way to upload bytecode to the kernel that was > > executed for a PIO operation, it could either pass the operation to > > userspace or handle it within the kernel when possible without taking > > a heavy weight exit. > > > > If the bytecode can access variables in a shared memory area, it could > > be pretty efficient to work with. > > > > This means that the kernel never has to deal with specific in-kernel > > devices but that userspace can accelerator as many of its devices as > > it sees fit. > > 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. If every user were emulating different machines, LPF this would make sense. Are they? Or should we write those helpers once, in C, and provide that for them. Cheers, Rusty. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39793) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rus3m-0003Iz-M0 for qemu-devel@nongnu.org; Tue, 07 Feb 2012 15:54:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rus3l-0001m7-GZ for qemu-devel@nongnu.org; Tue, 07 Feb 2012 15:54:42 -0500 Received: from ozlabs.org ([203.10.76.45]:36981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rus3l-0001ll-2v for qemu-devel@nongnu.org; Tue, 07 Feb 2012 15:54:41 -0500 From: Rusty Russell In-Reply-To: <4F2F9E89.7090607@redhat.com> 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> Date: Wed, 08 Feb 2012 04:42:58 +1030 Message-ID: <87vcnih5qt.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [RFC] Next gen kvm api List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity , Anthony Liguori Cc: qemu-devel , linux-kernel , Gleb Natapov , KVM list On Mon, 06 Feb 2012 11:34:01 +0200, Avi Kivity wrote: > On 02/05/2012 06:36 PM, Anthony Liguori wrote: > > If userspace had a way to upload bytecode to the kernel that was > > executed for a PIO operation, it could either pass the operation to > > userspace or handle it within the kernel when possible without taking > > a heavy weight exit. > > > > If the bytecode can access variables in a shared memory area, it could > > be pretty efficient to work with. > > > > This means that the kernel never has to deal with specific in-kernel > > devices but that userspace can accelerator as many of its devices as > > it sees fit. > > 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. If every user were emulating different machines, LPF this would make sense. Are they? Or should we write those helpers once, in C, and provide that for them. Cheers, Rusty.