From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ru54X-0004TE-EF for qemu-devel@nongnu.org; Sun, 05 Feb 2012 11:36:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ru54W-0003wi-99 for qemu-devel@nongnu.org; Sun, 05 Feb 2012 11:36:13 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:32836) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ru54W-0003wZ-1v for qemu-devel@nongnu.org; Sun, 05 Feb 2012 11:36:12 -0500 Received: by pbaa11 with SMTP id a11so5852769pba.4 for ; Sun, 05 Feb 2012 08:36:10 -0800 (PST) Message-ID: <4F2EAFF6.7030006@codemonkey.ws> Date: Sun, 05 Feb 2012 10:36:06 -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> In-Reply-To: <20120205095153.GA29265@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 , Avi Kivity , KVM list , linux-kernel On 02/05/2012 03:51 AM, Gleb Natapov wrote: > On Sun, Feb 05, 2012 at 11:44:43AM +0200, Avi Kivity wrote: >> On 02/05/2012 11:37 AM, Gleb Natapov wrote: >>> On Thu, Feb 02, 2012 at 06:09:54PM +0200, Avi Kivity wrote: >>>> Device model >>>> ------------ >>>> Currently kvm virtualizes or emulates a set of x86 cores, with or >>>> without local APICs, a 24-input IOAPIC, a PIC, a PIT, and a number of >>>> PCI devices assigned from the host. The API allows emulating the local >>>> APICs in userspace. >>>> >>>> The new API will do away with the IOAPIC/PIC/PIT emulation and defer >>>> them to userspace. Note: this may cause a regression for older guests >>>> that don't support MSI or kvmclock. Device assignment will be done >>>> using VFIO, that is, without direct kvm involvement. >>>> >>> So are we officially saying that KVM is only for modern guest >>> virtualization? >> >> No, but older guests may have reduced performance in some workloads >> (e.g. RHEL4 gettimeofday() intensive workloads). >> > Reduced performance is what I mean. Obviously old guests will continue working. An interesting solution to this problem would be an in-kernel device VM. Most of the time, the hot register is just one register within a more complex device. The reads are often side-effect free and trivially computed from some device state + host time. 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. This could replace ioeventfd as a mechanism (which would allow clearing the notify flag before writing to an eventfd). We could potentially just use BPF for this. Regards, Anthony Liguori