* [Qemu-devel] Virtio refactoring.
@ 2012-11-13 14:27 KONRAD Frédéric
2012-11-13 15:32 ` Cornelia Huck
0 siblings, 1 reply; 7+ messages in thread
From: KONRAD Frédéric @ 2012-11-13 14:27 UTC (permalink / raw)
To: qemu-devel, aliguori, Peter Maydell, Mark Burton,
Evgeny Voevodin, agraf, cornelia.huck
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Qemu-devel] Virtio refactoring.
2012-11-13 14:27 [Qemu-devel] Virtio refactoring KONRAD Frédéric
@ 2012-11-13 15:32 ` Cornelia Huck
2012-11-13 16:31 ` KONRAD Frédéric
2012-11-13 23:00 ` Andreas Färber
0 siblings, 2 replies; 7+ messages in thread
From: Cornelia Huck @ 2012-11-13 15:32 UTC (permalink / raw)
To: KONRAD Frédéric
Cc: Peter Maydell, aliguori, Evgeny Voevodin, Mark Burton, qemu-devel, agraf
On Tue, 13 Nov 2012 15:27:57 +0100
KONRAD Frédéric <fred.konrad@greensocs.com> wrote:
> 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.
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-<type>-xxx)
to
system bus
-> virtio transport bridge dev (virtio-bridge-xxx)
-> virtio bus (virtio-bus-xxx)
-> virtio dev (virtio-<type>-xxx)
?
Would this also mean we could have several virtio-busses with different
transports?
>
> 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 ?
What of the alias handling? Can this be killed once everything has been
converted?
>
> 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).
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Qemu-devel] Virtio refactoring.
2012-11-13 15:32 ` Cornelia Huck
@ 2012-11-13 16:31 ` KONRAD Frédéric
2012-11-13 18:09 ` Cornelia Huck
2012-11-13 23:00 ` Andreas Färber
1 sibling, 1 reply; 7+ messages in thread
From: KONRAD Frédéric @ 2012-11-13 16:31 UTC (permalink / raw)
To: Cornelia Huck
Cc: Peter Maydell, aliguori, Evgeny Voevodin, Mark Burton, qemu-devel, agraf
On 13/11/2012 16:32, Cornelia Huck wrote:
> On Tue, 13 Nov 2012 15:27:57 +0100
> KONRAD Frédéric <fred.konrad@greensocs.com> wrote:
>
>> 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.
> 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-<type>-xxx)
>
> to
>
> system bus
> -> virtio transport bridge dev (virtio-bridge-xxx)
> -> virtio bus (virtio-bus-xxx)
> -> virtio dev (virtio-<type>-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 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 ?
> 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).
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Virtio refactoring.
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
0 siblings, 1 reply; 7+ messages in thread
From: Cornelia Huck @ 2012-11-13 18:09 UTC (permalink / raw)
To: KONRAD Frédéric
Cc: Peter Maydell, aliguori, Evgeny Voevodin, Mark Burton, qemu-devel, agraf
On Tue, 13 Nov 2012 17:31:40 +0100
KONRAD Frédéric <fred.konrad@greensocs.com> wrote:
> On 13/11/2012 16:32, Cornelia Huck wrote:
> > On Tue, 13 Nov 2012 15:27:57 +0100
> > KONRAD Frédéric <fred.konrad@greensocs.com> wrote:
> >
> >> 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.
> > 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-<type>-xxx)
> >
> > to
> >
> > system bus
> > -> virtio transport bridge dev (virtio-bridge-xxx)
> > -> virtio bus (virtio-bus-xxx)
> > -> virtio dev (virtio-<type>-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. )
I meant the structure you see in 'info qtree'. We might be talking
about the same thing :)
> >> 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 ?
The alias stuff in hw/qdev-monitor.c that lets you specify either
virtio-<type>-<transport> or virtio-<type>.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Virtio refactoring.
2012-11-13 18:09 ` Cornelia Huck
@ 2012-11-15 10:32 ` KONRAD Frédéric
2012-11-15 12:05 ` Cornelia Huck
0 siblings, 1 reply; 7+ messages in thread
From: KONRAD Frédéric @ 2012-11-15 10:32 UTC (permalink / raw)
To: Cornelia Huck
Cc: Peter Maydell, aliguori, Evgeny Voevodin, Mark Burton, qemu-devel, agraf
Hi,
On 13/11/2012 19:09, Cornelia Huck wrote:
> On Tue, 13 Nov 2012 17:31:40 +0100
> KONRAD Frédéric <fred.konrad@greensocs.com> wrote:
>>
>> We'd go from
>>
>> system bus
>> -> virtio transport bridge dev (virtio-xxx-bridge)
>> -> virtio transport bus (virtio-xxx-bus)
>> -> virtio transport dev (virtio-<type>-xxx)
>>
>> to
>>
>> system bus
>> -> virtio transport bridge dev (virtio-bridge-xxx)
>> -> virtio bus (virtio-bus-xxx)
>> -> virtio dev (virtio-<type>-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. )
> I meant the structure you see in 'info qtree'. We might be talking
> about the same thing :)
For the qtree structure we have eg for virtio block :
bus: main-system-bus
type System
dev: pcihost, id ""
bus: pci.0
type PCI
dev: virtio-blk-pci, id ""
...
And it would become :
bus: main-system-bus
type System
dev: pcihost, id ""
bus: pci.0
type PCI
dev: virtio-pci, id ""
bus: virtio.0
type VIRTIO
dev: virtio-blk, id ""
...
>
>>>> 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 ?
> The alias stuff in hw/qdev-monitor.c that lets you specify either
> virtio-<type>-<transport> or virtio-<type>.
>
So it would break the alias, we must find a solution for that.
Fred
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Qemu-devel] Virtio refactoring.
2012-11-15 10:32 ` KONRAD Frédéric
@ 2012-11-15 12:05 ` Cornelia Huck
0 siblings, 0 replies; 7+ messages in thread
From: Cornelia Huck @ 2012-11-15 12:05 UTC (permalink / raw)
To: KONRAD Frédéric
Cc: Peter Maydell, aliguori, Evgeny Voevodin, Mark Burton, qemu-devel, agraf
On Thu, 15 Nov 2012 11:32:13 +0100
KONRAD Frédéric <fred.konrad@greensocs.com> wrote:
> For the qtree structure we have eg for virtio block :
>
> bus: main-system-bus
> type System
> dev: pcihost, id ""
> bus: pci.0
> type PCI
> dev: virtio-blk-pci, id ""
> ...
>
My current virtio-ccw layout is:
bus: main-system-bus
type System
dev: virtio-ccw-bridge, id ""
bus: virtio-ccw
type virtio-ccw-bus
dev: virtio-blk-ccw, id ""
...
> And it would become :
>
> bus: main-system-bus
> type System
> dev: pcihost, id ""
> bus: pci.0
> type PCI
> dev: virtio-pci, id ""
> bus: virtio.0
> type VIRTIO
> dev: virtio-blk, id ""
> ...
>
I guess we could have the following for virtio-ccw:
bus: main-system-bus
type System
dev: css, id ""
bus: css.fe
type ccw
dev: virtio-ccw, id ""
bus: virtio.0
type virtio
dev: virtio-blk, id ""
...
IOW, we introduce a channel subsystem (css) analogous to pcihost, have
a ccw bus which can hold all kinds of channel devices, introduce a bus
per channel subsystem image (here: the virtual css fe) and stick the
virtio bus under it. If we want to support passthrough of real channel
devices some day, they get their own bus for their channel subsystem
(css.0, css.1, ...) and have the devices show up under it.
(Just thinking aloud. I'll probably need to play with that idea a bit.)
> >
> >>>> 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 ?
> > The alias stuff in hw/qdev-monitor.c that lets you specify either
> > virtio-<type>-<transport> or virtio-<type>.
> >
> So it would break the alias, we must find a solution for that.
I think only virtio-xxx-pci and s390-virtio-xxx need to get backward
compatibility; virtio-mmio and virtio-ccw should not need to deal with
old interfaces.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Virtio refactoring.
2012-11-13 15:32 ` Cornelia Huck
2012-11-13 16:31 ` KONRAD Frédéric
@ 2012-11-13 23:00 ` Andreas Färber
1 sibling, 0 replies; 7+ messages in thread
From: Andreas Färber @ 2012-11-13 23:00 UTC (permalink / raw)
To: Cornelia Huck
Cc: Peter Maydell, aliguori, Evgeny Voevodin, Mark Burton,
qemu-devel, agraf, KONRAD Frédéric
Am 13.11.2012 16:32, schrieb Cornelia Huck:
> On Tue, 13 Nov 2012 15:27:57 +0100
> KONRAD Frédéric <fred.konrad@greensocs.com> wrote:
>> * 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 ?
>
> What of the alias handling? Can this be killed once everything has been
> converted?
AFAIU yes, but we may need to add new aliases for the long versions
(virtio-blk-pci) instead. ;)
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-11-15 12:05 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-13 14:27 [Qemu-devel] Virtio refactoring KONRAD Frédéric
2012-11-13 15:32 ` 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
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.