From: "KONRAD Frédéric" <fred.konrad@greensocs.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Peter Maydell <peter.maydell@linaro.org>,
aliguori@us.ibm.com, e.voevodin@samsung.com,
mark.burton@greensocs.com, qemu-devel@nongnu.org,
stefanha@redhat.com, cornelia.huck@de.ibm.com
Subject: Re: [Qemu-devel] [RFC PATCH v5 6/6] virtio-blk : Refactor virtio-blk.
Date: Thu, 06 Dec 2012 11:10:05 +0100 [thread overview]
Message-ID: <50C06EFD.7090701@greensocs.com> (raw)
In-Reply-To: <50C06B0C.7040901@suse.de>
On 06/12/2012 10:53, Andreas Färber wrote:
> Am 06.12.2012 10:21, schrieb KONRAD Frédéric:
>> On 05/12/2012 18:22, Andreas Färber wrote:
>>> Am 05.12.2012 17:25, schrieb Peter Maydell:
>>>> On 4 December 2012 14:35, <fred.konrad@greensocs.com> wrote:
>>>>> From: KONRAD Frederic <fred.konrad@greensocs.com>
>>>>>
>>>>> Create virtio-blk which extends virtio-device, so it can be
>>>>> connected on
>>>>> virtio-bus.
>>>>>
>>>>> Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com>
>>>>> ---
>>>>> hw/virtio-blk.c | 170
>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++--------
>>>>> hw/virtio-blk.h | 4 ++
>>>>> 2 files changed, 150 insertions(+), 24 deletions(-)
>>>>>
>>>>> diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
>>>>> index e25cc96..ee1ea8b 100644
>>>>> --- a/hw/virtio-blk.c
>>>>> +++ b/hw/virtio-blk.c
>>>>> @@ -21,24 +21,42 @@
>>>>> #ifdef __linux__
>>>>> # include <scsi/sg.h>
>>>>> #endif
>>>>> +#include "virtio-bus.h"
>>>>>
>>>>> +/* Take this structure as our device structure. */
>>>>> typedef struct VirtIOBlock
>>>>> {
>>>>> + /*
>>>>> + * Adding parent_obj breaks to_virtio_blk cast function,
>>>>> + * and virtio_blk_init.
>>>>> + */
>>>>> + DeviceState parent_obj;
>>>>> + /*
>>>>> + * We don't need that anymore, as we'll use QOM cast to get the
>>>>> + * VirtIODevice. Just temporary keep it, for not breaking
>>>>> functionality.
>>>>> + */
>>>>> VirtIODevice vdev;
>>>> This doesn't make sense. After your previous patch, VirtIODevice
>>>> is-a DeviceState, and VirtIOBlock already is-a VirtIODevice,
>>>> so there's nothing to do here. Adding this parent_obj field
>>>> here is just breaking things (it would make the VirtIOBlock
>>>> into a direct child of DeviceState, which isn't what we want).
>>>>
>>>>> BlockDriverState *bs;
>>>>> VirtQueue *vq;
>>>>> void *rq;
>>>>> QEMUBH *bh;
>>>>> BlockConf *conf;
>>>>> - VirtIOBlkConf *blk;
>>>>> + /*
>>>>> + * We can't use pointer with properties.
>>>>> + */
>>>>> + VirtIOBlkConf blk;
>>>>> unsigned short sector_mask;
>>>>> DeviceState *qdev;
>>>>> } VirtIOBlock;
>>>>>
>>>>> -static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
>>>>> -{
>>>>> - return (VirtIOBlock *)vdev;
>>>>> -}
>>>>> +/*
>>>>> + * Use the QOM cast, so we don't need that anymore.
>>>>> + *
>>>>> + * static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
>>>>> + * {
>>>>> + * return (VirtIOBlock *)vdev;
>>>>> + * }
>>>>> + */
>>>> If we don't need it, just delete it.
>>> Seconded. You need to introduce a VIRTIO_BLOCK() macro, backed by
>>> OBJECT_CHECK(), and replace all callers of to_virtio_blk() with
>>> VIRTIO_BLOCK(). Compare my ISA series that I intentionally cc'ed you on.
>> Yes, that's why I comment to_virtio_blk().
>>
>> Isn't what I made in this patch with :
>>
>> +#define TYPE_VIRTIO_BLK "virtio-blk"
>> +#define VIRTIO_BLK(obj) \
>> + OBJECT_CHECK(VirtIOBlock, (obj), TYPE_VIRTIO_BLK)
>> +
>>
>> and
>>
>> - VirtIOBlock *s = to_virtio_blk(vdev);
>> + VirtIOBlock *s = VIRTIO_BLK(vdev);
>>
>> ?
> Sorry. I expected to see the macros above the typedef above, but in the
> header is even better! :) VIRTIO_BLOCK vs. VIRTIO_BLK is just a style
> question.
>
> Further, I missed on brief sight that the to_* function was commented
> out, thought it was still being used. Didn't find enough time to review
> the series fully yet.
Sorry for that, I'll remove the comment.
>
>> I agree with that, but, there is an issue :
>> The refactored VirtIOBlk is a device and seems to work, but the device
>> which use this VirtIOBlock
>> (eg virtio-blk-pci) are just allocating a structure ( in
>> virtio_common_init ).
>>
>> That's why this patch is breaking virtio-blk-pci.
> Don't understand that part due to lack of virtio knowledge...
> Patch 5/6 introduces VirtIODevice as sitting on TYPE_VIRTIO_BUS. So with
> this patch VirtIOBlk is moving to that new bus and virtio-blk-pci should
> only be necessary as a command line option alias for backwards
> compatibility, no? Are you saying you can't make this switch and
> refactoring for virtio-blk *only*?
I mean that all device which use virtio_blk_init will be broken as we
use the
OBJECT_CHECK cast and virtio_blk_init currently call virtio_common_init
which allocate a VirtIODevice structure ( and don't create any device ).
The other virtio-* devices shouldn't be affected. I must test.
You suggest an alias for backwards compatibility ? It must create a
virtio-pci and
a virtio-blk. Is it possible ?
Fred
>
> Andreas
>
next prev parent reply other threads:[~2012-12-06 10:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-04 14:35 [Qemu-devel] [RFC PATCH v5 0/6] Virtio refactoring fred.konrad
2012-12-04 14:35 ` [Qemu-devel] [RFC PATCH v5 1/6] qdev : add a maximum device allowed field for the bus fred.konrad
2012-12-04 14:35 ` [Qemu-devel] [RFC PATCH v5 2/6] virtio-bus : Introduce virtio-bus fred.konrad
2012-12-04 14:35 ` [Qemu-devel] [RFC PATCH v5 3/6] virtio-pci-bus : Introduce virtio-pci-bus fred.konrad
2012-12-04 14:35 ` [Qemu-devel] [RFC PATCH v5 4/6] virtio-pci : Refactor virtio-pci device fred.konrad
2012-12-04 14:49 ` Peter Maydell
2012-12-04 15:52 ` KONRAD Frédéric
2012-12-04 14:35 ` [Qemu-devel] [RFC PATCH v5 5/6] virtio-device : Refactor virtio-device fred.konrad
2012-12-04 14:55 ` Peter Maydell
2012-12-04 15:55 ` KONRAD Frédéric
2012-12-04 14:35 ` [Qemu-devel] [RFC PATCH v5 6/6] virtio-blk : Refactor virtio-blk fred.konrad
2012-12-05 16:25 ` Peter Maydell
2012-12-05 17:22 ` Andreas Färber
2012-12-06 9:21 ` KONRAD Frédéric
2012-12-06 9:53 ` Andreas Färber
2012-12-06 10:10 ` KONRAD Frédéric [this message]
2012-12-06 10:13 ` Peter Maydell
2012-12-06 13:58 ` KONRAD Frédéric
2012-12-06 14:21 ` Peter Maydell
2012-12-06 14:48 ` KONRAD Frédéric
2012-12-06 9:11 ` KONRAD Frédéric
2012-12-06 9:18 ` Andreas Färber
2012-12-06 9:23 ` KONRAD Frédéric
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=50C06EFD.7090701@greensocs.com \
--to=fred.konrad@greensocs.com \
--cc=afaerber@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 \
--cc=stefanha@redhat.com \
/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.