From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC] Next gen kvm api Date: Sun, 05 Feb 2012 10:36:06 -0600 Message-ID: <4F2EAFF6.7030006@codemonkey.ws> References: <4F2AB552.2070909@redhat.com> <20120205093723.GQ23536@redhat.com> <4F2E4F8B.8090504@redhat.com> <20120205095153.GA29265@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel , Avi Kivity , KVM list , linux-kernel To: Gleb Natapov Return-path: In-Reply-To: <20120205095153.GA29265@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 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