From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:48942)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1TYHTG-0008K7-RN
	for qemu-devel@nongnu.org; Tue, 13 Nov 2012 09:28:13 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1TYHTD-00069e-PS
	for qemu-devel@nongnu.org; Tue, 13 Nov 2012 09:28:10 -0500
Received: from greensocs.com ([87.106.252.221]:44195
	helo=s15328186.onlinehome-server.info)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1TYHTD-00069V-Il
	for qemu-devel@nongnu.org; Tue, 13 Nov 2012 09:28:07 -0500
Message-ID: <50A258ED.7080807@greensocs.com>
Date: Tue, 13 Nov 2012 15:27:57 +0100
From: =?ISO-8859-1?Q?KONRAD_Fr=E9d=E9ric?= <fred.konrad@greensocs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Virtio refactoring.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org, aliguori@us.ibm.com, Peter Maydell <peter.maydell@linaro.org>, Mark Burton <mark.burton@greensocs.com>, Evgeny Voevodin <e.voevodin@samsung.com>, agraf@suse.de, cornelia.huck@de.ibm.com

Hi,

Just to be sure that we are all understanding the same thing about the 
virtio
refactoring.

The old patch-set ( git://git.greensocs.com/qemu_virtio.git virtio ) I 
sent was
not good because :

* It use a custom transport property ( e.g : transport=virtio-mmio.0 ) for
   selecting a transport device between refactored virtio-pci and 
virtio-mmio
   which isn't QOM compliant.
* It wasn't easily reviewable, because the virtio-pci-new.c file is 
created at
   the beginning of the patch-set in order to keep virtio-pci.c ( and not
   breaking the virtio-*-pci devices ).

To fix this, an idea is to use a new qbus named VirtioBus to link virtio-pci
or virtio-mmio with all the virtio backend ( VirtioDevice ). So 
"virtio-pci" and
"virtio-mmio" will have a VirtioBus.

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 VirtioDevice.
          -> 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 ?

When it will work, we must be sure of :

-> migration compatibility.
-> not breaking the s390 transport.
-> compatibility with s390 ccw.

Fred