[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring.
From: |
KONRAD Frédéric |
Subject: |
Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring. |
Date: |
Mon, 17 Dec 2012 18:13:28 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
On 17/12/2012 16:45, Michael S. Tsirkin wrote:
On Fri, Dec 07, 2012 at 02:32:29PM +0100, address@hidden wrote:
From: KONRAD Frederic <address@hidden>
You can clone that from here :
git.greensocs.com/home/greensocs/git/qemu_virtio.git virtio_refactoring_v6
The problem with the last RFC v5 was that virtio-blk refactoring broke
virtio-blk-pci device ( SEGFAULT ). So I modify this last step to fix that
issue.
In order to not break anything, I think we have to refactor virtio-pci-blk in a
next step then add a supplementary step which clean virtio-blk
( eg : fix the cast ).
Does it make sense ?
I am yet to go over the patches but I did try to read
previous discussion and I am still puzzled about the motivation. One of
the previous messages mentioned this is to allow virtio-mmio.
Yes, the main goal is to have the choice of the transport device.
eg :
-device virtio-pci,id=transport1 -device virtio-scsi,bus=transport1
or
-device virtio-mmio,id=transport1 -device virtio-scsi,bus=transport1
That's why anthony suggest to create a virtio-bus to connect transport
to device.
so all virtio-x devices must be created. And virtio-pci must have a
virtio-bus.
Then to keep compability with the older version virtio-x-pci must create
virtio-pci and virtio-x.
Is the point to allow virtio-mmio? Why can't virtio-mmio be just
another bus, like a pci bus, and another binding, like the virtio-pci
binding?
Do you mean something like creating all virtio device like virtio-mmio-x ?
Is the issue that bindings are not devices?
I'm sending a patchset to use DeviceState as binding pointer -
will this address the issue?
The issue is that all is linked, and here the virtio-blk refactoring breaks
virtio-blk-pci and virtio-blk-s390 devices as they didn't use QOM.
But the newer version ( V7 ) didn't break anything.
If this was covered but I missed this I'll be thankful for
pointers if any.
Thanks,
- [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., fred . konrad, 2012/12/07
- [Qemu-devel] [RFC PATCH v6 1/6] qdev : add a maximum device allowed field for the bus., fred . konrad, 2012/12/07
- [Qemu-devel] [RFC PATCH v6 3/6] virtio-pci-bus : Introduce virtio-pci-bus., fred . konrad, 2012/12/07
- [Qemu-devel] [RFC PATCH v6 2/6] virtio-bus : Introduce virtio-bus, fred . konrad, 2012/12/07
- [Qemu-devel] [RFC PATCH v6 5/6] virtio-device : Refactor virtio-device., fred . konrad, 2012/12/07
- [Qemu-devel] [RFC PATCH v6 6/6] virtio-blk : Add the virtio-blk device., fred . konrad, 2012/12/07
- [Qemu-devel] [RFC PATCH v6 4/6] virtio-pci : Refactor virtio-pci device., fred . konrad, 2012/12/07
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Michael S. Tsirkin, 2012/12/17
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring.,
KONRAD Frédéric <=
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Peter Maydell, 2012/12/18
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Michael S. Tsirkin, 2012/12/18
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Peter Maydell, 2012/12/18
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Paolo Bonzini, 2012/12/18
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Peter Maydell, 2012/12/18
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Michael S. Tsirkin, 2012/12/18
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Peter Maydell, 2012/12/18
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Paolo Bonzini, 2012/12/18
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Peter Maydell, 2012/12/18