From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nu1hM-0005EI-DN for qemu-devel@nongnu.org; Tue, 23 Mar 2010 06:51:00 -0400 Received: from [199.232.76.173] (port=34724 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nu1hL-0005E0-8d for qemu-devel@nongnu.org; Tue, 23 Mar 2010 06:50:59 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nu1hJ-00060s-L9 for qemu-devel@nongnu.org; Tue, 23 Mar 2010 06:50:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28337) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nu1hJ-00060o-5q for qemu-devel@nongnu.org; Tue, 23 Mar 2010 06:50:57 -0400 Date: Tue, 23 Mar 2010 12:47:24 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups Message-ID: <20100323104724.GA23512@redhat.com> References: <20100322171945.GA19994@redhat.com> <201003230049.41271.paul@codesourcery.com> <4BA81651.1070801@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BA81651.1070801@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Juan Quintela , Gerd Hoffmann , Paul Brook , qemu-devel@nongnu.org On Mon, Mar 22, 2010 at 08:16:01PM -0500, Anthony Liguori wrote: > 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 If we need to change command line because of an implementation change, IMO something is wrong with the design. Users shouldn't care about non-existent virtio bus. >> >> >>> - 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 >> >> >>