All of lore.kernel.org
 help / color / mirror / Atom feed
From: "KONRAD Frédéric" <fred.konrad@greensocs.com>
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
Subject: [Qemu-devel] Virtio refactoring.
Date: Tue, 13 Nov 2012 15:27:57 +0100	[thread overview]
Message-ID: <50A258ED.7080807@greensocs.com> (raw)

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

             reply	other threads:[~2012-11-13 14:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-13 14:27 KONRAD Frédéric [this message]
2012-11-13 15:32 ` [Qemu-devel] Virtio refactoring Cornelia Huck
2012-11-13 16:31   ` KONRAD Frédéric
2012-11-13 18:09     ` Cornelia Huck
2012-11-15 10:32       ` KONRAD Frédéric
2012-11-15 12:05         ` Cornelia Huck
2012-11-13 23:00   ` Andreas Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50A258ED.7080807@greensocs.com \
    --to=fred.konrad@greensocs.com \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=e.voevodin@samsung.com \
    --cc=mark.burton@greensocs.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.