From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/3] virtio PCI device Date: Thu, 22 Nov 2007 09:32:43 +0200 Message-ID: <4745309B.8050404@qumranet.com> References: <11944899922822-git-send-email-aliguori@us.ibm.com> <11944900141678-git-send-email-aliguori@us.ibm.com> <11944900152750-git-send-email-aliguori@us.ibm.com> <11944900163817-git-send-email-aliguori@us.ibm.com> <4742F6B7.20503@qumranet.com> <474300AD.4060509@us.ibm.com> <4743076F.8000105@qumranet.com> <47435CCB.1050506@us.ibm.com> <4743DAA4.70800@qumranet.com> <1195669377.6352.247.camel@bodhitayantram.eng.vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1195669377.6352.247.camel-cxY/u30q8FloTgUnLF1by8fTvwmfpRNyZeezCHUQhQ4@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Zachary Amsden Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, virtualization-qjLDD68F18O7TbgM5vRIOg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Eric Van Hensbergen List-Id: virtualization@lists.linuxfoundation.org Zachary Amsden wrote: > On Wed, 2007-11-21 at 09:13 +0200, Avi Kivity wrote: > > >> Where the device is implemented is an implementation detail that should >> be hidden from the guest, isn't that one of the strengths of >> virtualization? Two examples: a file-based block device implemented in >> qemu gives you fancy file formats with encryption and compression, while >> the same device implemented in the kernel gives you a low-overhead path >> directly to a zillion-disk SAN volume. Or a user-level network device >> capable of running with the slirp stack and no permissions vs. the >> kernel device running copyless most of the time and using a dma engine >> for the rest but requiring you to be good friends with the admin. >> >> The user should expect zero reconfigurations moving a VM from one model >> to the other. >> > > I think that is pretty insightful, and indeed, is probably the only > reason we would ever consider using a virtio based driver. > > But is this really a virtualization problem, and is virtio the right > place to solve it? Doesn't I/O hotplug with multipathing or NIC teaming > provide the same infrastructure in a way that is useful in more than > just a virtualization context? > With the aid of a dictionary I was able to understand about half the words in the last sentence. Moving from device to device using hotplug+multipath is complex to configure, available on only some guests, uses rarely-exercised paths in the guest OS, and only works for a few types of devices (network and block). Having host independence in the device means you can change the device implementation for, say, a display driver (consider, for example, a vmgl+virtio driver, which can be implemented in userspace or tunneled via virtio-over-tcp to some remote display without going through userspace, without the guest knowing about it). -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/