From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nthhr-0007Ac-0I for qemu-devel@nongnu.org; Mon, 22 Mar 2010 09:30:11 -0400 Received: from [199.232.76.173] (port=38981 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nthhq-0007AT-Au for qemu-devel@nongnu.org; Mon, 22 Mar 2010 09:30:10 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nthhp-0000rm-7m for qemu-devel@nongnu.org; Mon, 22 Mar 2010 09:30:10 -0400 Received: from mx20.gnu.org ([199.232.41.8]:15587) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Nthho-0000rc-Vk for qemu-devel@nongnu.org; Mon, 22 Mar 2010 09:30:09 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nthhn-0003Q7-6F for qemu-devel@nongnu.org; Mon, 22 Mar 2010 09:30:07 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups Date: Mon, 22 Mar 2010 13:30:01 +0000 References: <4BA6DB3F.7010702@codemonkey.ws> In-Reply-To: <4BA6DB3F.7010702@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003221330.02217.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: "Michael S. Tsirkin" , Juan Quintela > A VirtIOBlock device cannot be a VirtIODevice while being a > VirtIOPCIProxy (proxy is a poor name, btw). > > It really ought to be: > > DeviceState -> VirtIODevice -> VirtIOBlock > > and: > > PCIDevice -> VirtIOPCI : implements VirtIOBus > > The interface between the VirtIODevice and VirtIOBus is the virtio > transport. > > The main reason a separate bus is needed is the same reason it's needed > in Linux. VirtIOBlock has to be tied to some bus. It cannot be tied to > the PCI bus without having it be part of the implementation detail. > Introducing another bus type fixes this (and it's what we do in the > kernel). Why does virtio need a device state and bus at all? Can't it just be an internal implementation interface, which happens to be used by all devices that happen to exposed a block device over a virtio transport? If you have a virtio bus then IMO the PCI bridge device should be independent of the virtio device that is connected to it. Paul