Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946380AbWJSTCN (ORCPT ); Thu, 19 Oct 2006 15:02:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1946381AbWJSTCN (ORCPT ); Thu, 19 Oct 2006 15:02:13 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:19636 "EHLO e1.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1946380AbWJSTCM (ORCPT ); Thu, 19 Oct 2006 15:02:12 -0400 Message-ID: <4537CBB2.2080701@us.ibm.com> Date: Thu, 19 Oct 2006 14:02:10 -0500 From: Anthony Liguori User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: Avi Kivity CC: Andi Kleen , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/7] KVM: Kernel-based Virtual Machine References: <4537818D.4060204@qumranet.com> <4537A343.1050008@qumranet.com> In-Reply-To: <4537A343.1050008@qumranet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1673 Lines: 49 Avi Kivity wrote: > Andi Kleen wrote: >> Avi Kivity writes: >> >> >>> The following patchset adds a driver for Intel's hardware >>> virtualization >>> extensions to the x86 architecture. The driver adds a character device >>> (/dev/kvm) that exposes the virtualization capabilities to >>> userspace. Using >>> this driver, a process can run a virtual machine (a "guest") in a fully >>> virtualized PC containing its own virtual hard disks, network >>> adapters, and >>> display. >>> >>> Using this driver, one can start multiple virtual machines on a >>> host. Each >>> virtual machine is a process on the host; a virtual cpu is a thread >>> in that >>> process. kill(1), nice(1), top(1) work as expected. >>> >> >> Where is the user space for this? Is it free? > > I have to go through the motions of creating a sourceforge project for > this and uploading it. And yes, it is free. Don't even bother creating a project. Just submit the patches back to QEMU. There's been a lot of discussion about this functionality within QEMU. There's no reason to fork QEMU yet again (Xen has given up and is now maintaining a patch queue). In this case, there's no reason why you would even need a patch queue. Regards, Anthony Liguori >> I suppose you need a device model. Do you use qemu's? >> > > Yes. I can't imagine anyone doing that work from scratch (Xen also > uses qemu). > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/