From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: KVM IO performance Date: Tue, 15 Jul 2008 10:22:08 +0300 Message-ID: <487C5020.3000209@qumranet.com> References: <08DF4D958216244799FC84F3514D70F001ABD037@pdsmsx415.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sukanto Ghosh , kvm@vger.kernel.org To: "Dong, Eddie" Return-path: Received: from il.qumranet.com ([212.179.150.194]:50321 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753398AbYGOHXn (ORCPT ); Tue, 15 Jul 2008 03:23:43 -0400 In-Reply-To: <08DF4D958216244799FC84F3514D70F001ABD037@pdsmsx415.ccr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Dong, Eddie wrote: > Sukanto Ghosh wrote: > >> Hi all, >> >> Why has the IO device emulation part been kept in >> userspace ? >> IO attempts cause VM-exits to the KVM (running in >> kernel-mode) it then forwards these requests to the >> userspace (mode-switch). After completion of IO in >> userspace, another mode switch is done to KVM before >> resuming the guests. >> What would be the problems had the device emulation parts >> been moved totally to kernelspace ? >> >> > The simple reason is that people don't want to pull a lot of code into > kernel whose failure may crash the whole system, of course there are > many other reasons such as maintaining synchronization with Qemu > upstream, coding style, maintanence effort etc. > Eddie > Nevertheless there is work in progress to integrate virtio network with the kernel's tap. This will eventually lead to zero copy networking (with some dma ioat magic). For block devices, there is no activity for kernel side, mainly because qcow2 format is complex and better be userspace, and the performance is relatively good. Dor