From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ntsj0-0004Bw-I1 for qemu-devel@nongnu.org; Mon, 22 Mar 2010 21:16:06 -0400 Received: from [199.232.76.173] (port=42873 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ntsj0-0004Bh-2q for qemu-devel@nongnu.org; Mon, 22 Mar 2010 21:16:06 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Ntsiy-0005nb-Hy for qemu-devel@nongnu.org; Mon, 22 Mar 2010 21:16:05 -0400 Received: from mail-yx0-f191.google.com ([209.85.210.191]:65087) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ntsiy-0005nX-9t for qemu-devel@nongnu.org; Mon, 22 Mar 2010 21:16:04 -0400 Received: by yxe29 with SMTP id 29so2460943yxe.4 for ; Mon, 22 Mar 2010 18:16:03 -0700 (PDT) Message-ID: <4BA81651.1070801@codemonkey.ws> Date: Mon, 22 Mar 2010 20:16:01 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups References: <20100322171945.GA19994@redhat.com> <201003230049.41271.paul@codesourcery.com> In-Reply-To: <201003230049.41271.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Juan Quintela , Gerd Hoffmann , qemu-devel@nongnu.org, "Michael S. Tsirkin" On 03/22/2010 07:49 PM, Paul Brook wrote: >> Solutions: >> - VirtIOPCIBus and hang devices from there (anthony). Why? because >> this is a simulated pci bus, we can implement the features that we >> need (not full pci) in the three showed architectures. We will have >> VirtIOPCIBLock everywhere, and its VirtIOPCIBus implmentation will >> hide the details. >> > This is not how I understood Anthony's proposal. > > VirtIOPCIBus makes no sense. The whole reason we have this problem is because > the VirtIO devices can not make any assumptions about the bus they are > connected to. > > The key point is that we promote VirtIO devices to nodes in the device tree. > i.e. VirtIODevice descends directly from DeviceState. > > Instead of trying to make a single polymorphic hybryd object, split into > separate objects for the component parts. Each host binding (PCI, syborg, > s390, etc.) provides a single VirtIO bridge device. This includes a VirtIOBus, > to which the VirtIODevice is attached. > > Most of the code and abstraction layers for this are already there. > We just replace virtio_bind_device with VirtIOBus, add direct registration of > VirtIODevice, and rip out all the crufty old device specific bits from virtio- > pci.c. > Right. The only real challenge is dealing with legacy save/restore and command line syntax. For save/restore, we can possibly have a dummy device that can split the VirtioPCI device state from the virtio device states and do the right thing. I'm not sure what we should do for command line syntax. We can keep -drive working as is. Do we need to support -device based creation? I don't think we've really considered what to do in a situation like this. Regards, Anthony Liguori > > >> - having multiple inheritance is "more natural" to virtio, then we have >> to change all the system to be able to allow multiple inherintance, >> even if it is more complex, and nothing else uses/needs it (mst). >> > I'm not convinced multiple inheritance solves the real problem, much less that > it is worthwhile. > > Paul > > >