From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYJOu-00056R-Bu for qemu-devel@nongnu.org; Tue, 13 Nov 2012 11:31:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYJOr-000302-9f for qemu-devel@nongnu.org; Tue, 13 Nov 2012 11:31:48 -0500 Received: from greensocs.com ([87.106.252.221]:33874 helo=s15328186.onlinehome-server.info) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYJOr-0002zu-3N for qemu-devel@nongnu.org; Tue, 13 Nov 2012 11:31:45 -0500 Message-ID: <50A275EC.3030700@greensocs.com> Date: Tue, 13 Nov 2012 17:31:40 +0100 From: =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= MIME-Version: 1.0 References: <50A258ED.7080807@greensocs.com> <20121113163242.613b3d07@BR9GNB5Z> In-Reply-To: <20121113163242.613b3d07@BR9GNB5Z> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Virtio refactoring. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Peter Maydell , aliguori@us.ibm.com, Evgeny Voevodin , Mark Burton , qemu-devel@nongnu.org, agraf@suse.de On 13/11/2012 16:32, Cornelia Huck wrote: > On Tue, 13 Nov 2012 15:27:57 +0100 > KONRAD Fr=C3=A9d=C3=A9ric wrote: > >> To fix this, an idea is to use a new qbus named VirtioBus to link virt= io-pci >> or virtio-mmio with all the virtio backend ( VirtioDevice ). So >> "virtio-pci" and >> "virtio-mmio" will have a VirtioBus. > Just to spell this out: > > We'd go from > > system bus > -> virtio transport bridge dev (virtio-xxx-bridge) > -> virtio transport bus (virtio-xxx-bus) > -> virtio transport dev (virtio--xxx) > > to > > system bus > -> virtio transport bridge dev (virtio-bridge-xxx) > -> virtio bus (virtio-bus-xxx) > -> virtio dev (virtio--xxx) > > ? I'm not sure of what you mean,.. do you mean for s390 ? for the moment we have e.g : virtio-blk-pci ( in virtio-pci.c ) and we want virtio-pci -> virtio-bus -> virtio-blk. ( or virtio-mmio -> virtio-bus -> virtio-blk. for pci-less system. ) > > Would this also mean we could have several virtio-busses with different > transports? I think so. > >> To do that we will do the following things in the right order : >> * Introduce a new VirtioBus ( same way as scsi-bus.c ), with >> VirtIODevice >> interface : >> -> callback to completely abstract the VirtioDevice from >> VirtioPCI. >> -> for the queue, load/save the queue/config, features, ...= , >> other ? >> * Add a VirtioBus to the VirtioPCIProxy. ( virtio-pci.c ) : >> -> moving all to the newer callback. >> * For each of the virtio-device : ( virtio-x.c ) >> -> making a separate class for virtio-x which is a VirtioDe= vice. >> -> making a virtio-x-pci which has a virtio-x. >> * Create virtio-mmio ( virtio-mmio.c ). >> >> Is it the right approach ? Do I miss something ? > What of the alias handling? Can this be killed once everything has been > converted? Which alias ? > >> When it will work, we must be sure of : >> >> -> migration compatibility. >> -> not breaking the s390 transport. >> -> compatibility with s390 ccw. > There shouldn't be major problems rebasing the virtio-ccw code on top > of this rework (though I'd probably try to keep the basic channel I/O > support separate from this patchset). >