Re: [Qemu-devel] [RFC PATCH v5 4/6] virtio-pci : Refactor virtio-pci device.

[KONRAD Frédéric]

On 04/12/2012 15:49, Peter Maydell wrote:

On 4 December 2012 14:35,   wrote:

From: KONRAD Frederic 

Create the virtio-pci device. This transport device will create a
virtio-pci-bus, so one VirtIODevice can be connected.

Signed-off-by: KONRAD Frederic 
---
  hw/virtio-pci.c | 112 
  hw/virtio-pci.h |  14 +++
  2 files changed, 126 insertions(+)

diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 5ac8d0d..8426122 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -1119,6 +1119,115 @@ static TypeInfo virtio_scsi_info = {
  .class_init= virtio_scsi_class_init,
  };

+/*
+ * virtio-pci : This is the PCIDevice which have a virtio-pci-bus.
+ */
+
+/* init callback */
+static void virtio_pci_init_cb(void *opaque)
+/* exit callback */
+static void virtio_pci_exit_cb(void *opaque)
+static int virtio_pci_init(PCIDevice *pci_dev)
+static void virtio_pci_exit(PCIDevice *pci_dev)

It's rather confusing to have an init and an init_cb and also
an exit and an exit_cb, and not to have anything explaining
what the difference is or when each one is called or what
needs to be done in one that can't be done in the other.

Right, I'll change the name and add comments.


-- PMM

Re: [Qemu-devel] [RFC PATCH v5 5/6] virtio-device : Refactor virtio-device.

[KONRAD Frédéric]

On 04/12/2012 15:55, Peter Maydell wrote:

On 4 December 2012 14:35,   wrote:

From: KONRAD Frederic 

Create the virtio-device which is abstract. All the virtio-device can extend
this class.

Signed-off-by: KONRAD Frederic 
---
  hw/virtio.c | 56 
  hw/virtio.h | 29 +
  2 files changed, 85 insertions(+)

diff --git a/hw/virtio.c b/hw/virtio.c
index f40a8c5..cd46af1 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -16,6 +16,7 @@
  #include "trace.h"
  #include "qemu-error.h"
  #include "virtio.h"
+#include "virtio-bus.h"
  #include "qemu-barrier.h"

  /* The alignment to use between consumer and producer parts of vring.
@@ -934,6 +935,38 @@ VirtIODevice *virtio_common_init(const char *name, 
uint16_t device_id,
  return vdev;
  }

+/*
+ * The same initialization as above without allocating the structure.
+ */
+void virtio_common_init_(VirtIODevice *vdev, const char *name,
+ uint16_t device_id, size_t config_size,
+ size_t struct_size)

If you find yourself cut-and-pasting 25 lines of code, think again.
In this case, just make virtio_common_init() a wrapper that does
a malloc and calls your non-allocation init.

I didn't think about it, I'll do it.

Thanks,

Fred.

Re: [Qemu-devel] [RFC PATCH v5 6/6] virtio-blk : Refactor virtio-blk.

[KONRAD Frédéric]

On 05/12/2012 17:25, Peter Maydell wrote:

On 4 December 2012 14:35,   wrote:

From: KONRAD Frederic 

Create virtio-blk which extends virtio-device, so it can be connected on
virtio-bus.

Signed-off-by: KONRAD Frederic 
---
  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 
  #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).


Ok, I think you're right, I'll check.


  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.

-- PMM

Yes, sure, I put it in comment to explain, why I deleted it.

Thanks,

Fred.

Re: [Qemu-devel] [RFC PATCH v5 6/6] virtio-blk : Refactor virtio-blk.

[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,   wrote:

From: KONRAD Frederic 

Create virtio-blk which extends virtio-device, so it can be connected on
virtio-bus.

Signed-off-by: KONRAD Frederic 
---
  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 
  #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);

?


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.


Regards,
Andreas



Thanks,

Fred.

Re: [Qemu-devel] [RFC PATCH v5 6/6] virtio-blk : Refactor virtio-blk.

[KONRAD Frédéric]

On 06/12/2012 10:18, Andreas Färber wrote:

Am 06.12.2012 10:11, schrieb KONRAD Frédéric:

On 05/12/2012 17:25, Peter Maydell wrote:

On 4 December 2012 14:35,   wrote:

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

-- PMM

Yes, sure, I put it in comment to explain, why I deleted it.

Please don't comment out unneeded things. Instead, remove them
completely and put the explanation into the commit message. That helps
keep the patch small and avoids commented-out code bitrotting.

Andreas


Ok, no problem.

Re: [Qemu-devel] [RFC PATCH v5 6/6] virtio-blk : Refactor virtio-blk.

[KONRAD Frédéric]

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,   wrote:

From: KONRAD Frederic 

Create virtio-blk which extends virtio-device, so it can be
connected on
virtio-bus.

Signed-off-by: KONRAD Frederic 
---
   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 
   #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

Re: [Qemu-devel] [RFC PATCH v5 6/6] virtio-blk : Refactor virtio-blk.

[KONRAD Frédéric]

On 06/12/2012 11:13, Peter Maydell wrote:

On 6 December 2012 09:53, Andreas Färber  wrote:

Am 06.12.2012 10:21, schrieb KONRAD Frédéric:

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?

It can't just be a command line alias, or we will break migration.
It has to be a simple device that composes together the virtio-pci
and virtio-blk devices, plus legacy support for properties and
migration state, I think.

-- PMM

Can we do virtio-blk refactoring and virtio-blk-pci at the same time for not
breaking anything ?

Or do you have a better idea ?

Fred

Re: [Qemu-devel] [RFC PATCH v5 6/6] virtio-blk : Refactor virtio-blk.

[KONRAD Frédéric]

On 06/12/2012 15:21, Peter Maydell wrote:

On 6 December 2012 13:58, KONRAD Frédéric  wrote:

On 06/12/2012 11:13, Peter Maydell wrote:

It can't just be a command line alias, or we will break migration.
It has to be a simple device that composes together the virtio-pci
and virtio-blk devices, plus legacy support for properties and
migration state, I think.

Can we do virtio-blk refactoring and virtio-blk-pci at the same time for not
breaking anything ?

Not breaking things is a key part of the requirements here.

Agree with that.


It's ok to say "I haven't converted virtio-net or the s390
transport in this patchset and therefore they are broken" as
an initial RFC (because we can look at how PCI/blk is done
and check it works before we expand the same thing out to
other transports/devices).  But you need to show how the
virtio-blk / virtio-pci refactoring works and leaves you with
a virtio-blk-pci that isn't broken (either at the end or at
any step along the way).

And if virtio-blk-pci is broken can we refactor it in the same "patch" ?



-- PMM

Re: [Qemu-devel] [RFC PATCH v7 7/8] virtio-pci-blk : Switch to new API.

[KONRAD Frédéric]

On 12/12/2012 15:25, Peter Maydell wrote:

On 10 December 2012 16:45,   wrote:

-static void virtio_blk_class_init(ObjectClass *klass, void *data)
-{
-DeviceClass *dc = DEVICE_CLASS(klass);
-PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
-
-k->init = virtio_blk_init_pci;
-k->exit = virtio_blk_exit_pci;
-k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
-k->device_id = PCI_DEVICE_ID_VIRTIO_BLOCK;
-k->revision = VIRTIO_PCI_ABI_VERSION;
-k->class_id = PCI_CLASS_STORAGE_SCSI;
-dc->reset = virtio_pci_reset;
-dc->props = virtio_blk_properties;
-}

This hunk removes the setting of the PCI vendor and device IDs
but I can't see where they are set in the new code.

How will the PCI transport's PCI vendor/device/class IDs be
set (a) when a virtio-blk backend is created and separately
plugged into a virtio-pci transport (b) for the legacy
virtio-pci-blk? [ideally the answer to (b) should be "in the
same way as for (a)"]

-- PMM


It's done in the virtio_pci_device_plugged(), ( step 4 )
At this time we have the device ID, so we can put the PCI IDs :

+static void virtio_pci_device_plugged(void *opaque)
+{
+VirtIOPCIProxy *proxy = VIRTIO_PCI(opaque);
+uint8_t *config;
+uint32_t size;
+
+/* Put the PCI IDs */
+switch (get_virtio_device_id(proxy->bus)) {
+
+case VIRTIO_ID_BLOCK:
+pci_config_set_device_id(proxy->pci_dev.config,
+ PCI_DEVICE_ID_VIRTIO_BLOCK);
+pci_config_set_class(proxy->pci_dev.config, PCI_CLASS_STORAGE_SCSI);
+break;
+default:
+error_report("unknown device id\n");
+break;
+
+}

I'll move the "case" to the step 7 as it should be.

Fred

Re: [Qemu-devel] [RFC PATCH v7 7/8] virtio-pci-blk : Switch to new API.

[KONRAD Frédéric]

On 11/12/2012 18:50, Peter Maydell wrote:

On 10 December 2012 16:45,   wrote:

From: KONRAD Frederic 

Here the virtio-blk-pci is modified for the new API. The device virtio-pci-blk
extends virtio-pci. It creates and connects a virtio-blk during the init.

Did you check whether this maintains backwards compatibility
for vmstate migration information and device properties?
(haven't investigated myself yet, just asking whether you have)

-- PMM

What do you mean exactly by backwards compatibility for vmstate migration ?

The device properties didn't change.
The virtio-blk-pci creates a virtio-blk device, puts the virtio block 
properties and  inits the virtio-blk.

Re: [Qemu-devel] [RFC PATCH v7 7/8] virtio-pci-blk : Switch to new API.

[KONRAD Frédéric]

On 12/12/2012 18:58, Peter Maydell wrote:

On 12 December 2012 17:53, Andreas Färber  wrote:

Am 12.12.2012 15:25, schrieb Peter Maydell:

How will the PCI transport's PCI vendor/device/class IDs be
set (a) when a virtio-blk backend is created and separately
plugged into a virtio-pci transport (b) for the legacy
virtio-pci-blk? [ideally the answer to (b) should be "in the
same way as for (a)"]

The obvious answer would be that PCI properties need to be set on the
PCI device, not an a VirtioDevice sitting on a virtio-bus.

I.e., with the proposed refactoring we'd have on the virtio-bus:

- VirtioDevice
   + VirtioBlockDevice
   + VirtioSCSIDevice - has-a scsi-bus
   ...

In turn that means that every VirtioDevice to be exposed as PCI device
to the guest needs it own PCIDevice exposing a private virtio-bus.

- PCIDevice
   - VirtioPCIDevice - has-a virtio-bus
 + virtio-blk-pci - has-a VirtioBlockDevice on its virtio-bus
 + virtio-scsi-pci - has-a VirtioSCSIDevice on its virtio-bus
 ...

...this bit is only for legacy back-compat. It should be equally
valid to just use the PCI transport plugged into a VirtioDevice,
both of which were created by the user with -device [and for
new transports, separate transport and backend should be the
standard]. That means the virtio-bus interface needs a way for
the backend to announce to the transport what it is so that
the PCI transport can set the right PCI IDs.

-- PMM
Yes, it's done with uint16_t get_virtio_device_id(VirtioBusState *bus) 
function from second step.

Re: [Qemu-devel] [RFC PATCH v7 7/8] virtio-pci-blk : Switch to new API.

[KONRAD Frédéric]

On 13/12/2012 09:24, KONRAD Frédéric wrote:

On 12/12/2012 15:25, Peter Maydell wrote:

On 10 December 2012 16:45,  wrote:

-static void virtio_blk_class_init(ObjectClass *klass, void *data)
-{
-DeviceClass *dc = DEVICE_CLASS(klass);
-PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
-
-k->init = virtio_blk_init_pci;
-k->exit = virtio_blk_exit_pci;
-k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
-k->device_id = PCI_DEVICE_ID_VIRTIO_BLOCK;
-k->revision = VIRTIO_PCI_ABI_VERSION;
-k->class_id = PCI_CLASS_STORAGE_SCSI;
-dc->reset = virtio_pci_reset;
-dc->props = virtio_blk_properties;
-}

This hunk removes the setting of the PCI vendor and device IDs
but I can't see where they are set in the new code.

How will the PCI transport's PCI vendor/device/class IDs be
set (a) when a virtio-blk backend is created and separately
plugged into a virtio-pci transport (b) for the legacy
virtio-pci-blk? [ideally the answer to (b) should be "in the
same way as for (a)"]

-- PMM


It's done in the virtio_pci_device_plugged(), ( step 4 )
At this time we have the device ID, so we can put the PCI IDs :

+static void virtio_pci_device_plugged(void *opaque)
+{
+VirtIOPCIProxy *proxy = VIRTIO_PCI(opaque);
+uint8_t *config;
+uint32_t size;
+
+/* Put the PCI IDs */
+switch (get_virtio_device_id(proxy->bus)) {
+
+case VIRTIO_ID_BLOCK:
+pci_config_set_device_id(proxy->pci_dev.config,
+ PCI_DEVICE_ID_VIRTIO_BLOCK);
+pci_config_set_class(proxy->pci_dev.config, 
PCI_CLASS_STORAGE_SCSI);

+break;
+default:
+error_report("unknown device id\n");
+break;
+
+}

I'll move the "case" to the step 7 as it should be.


I meant step 6* : Add the virtio-blk device.

the virtio-blk-pci set the PCI IDs on the same way as for virtio-blk.


Fred

Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring.

[KONRAD Frédéric]

On 17/12/2012 16:45, Michael S. Tsirkin wrote:

On Fri, Dec 07, 2012 at 02:32:29PM +0100, fred.kon...@greensocs.com wrote:

From: KONRAD Frederic 

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,

Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring.

[KONRAD Frédéric]

On 18/12/2012 12:01, Michael S. Tsirkin wrote:

On Tue, Dec 18, 2012 at 10:33:37AM +, Peter Maydell wrote:

On 17 December 2012 15:45, Michael S. Tsirkin  wrote:

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?

(a) the current code is really not very nice because it's not
actually a proper set of QOM/qdev devices
(b) unlike PCI, you can't create sysbus devices on the
command line, because they don't correspond to a user
pluggable bit of hardware. We don't want users to have to know
an address and IRQ number for each virtio-mmio device (especially
since these are board specific); instead the board can create
and wire up transport devices wherever is suitable, and the
user just creates the backend (which is plugged into the virtio bus).

-- PMM

This is what I am saying: create your own bus and put
your devices there. Allocate resources when you init
a device.

Instead you seem to want to expose a virtio device as two devices to
user - if true this is not reasonable.

The modifications will be transparent to the user, as we will keep 
virtio-x-pci devices.

Re: [Qemu-devel] [RFC PATCH V8 13/15] virtio : Remove the function pointer.

[KONRAD Frédéric]

On 19/12/2012 20:50, Blue Swirl wrote:

On Wed, Dec 19, 2012 at 9:53 AM,   wrote:

From: KONRAD Frederic 

This remove the function pointer in VirtIODevice, and use only
VirtioDeviceClass function pointer. It should be applied after all
the device have been refactored.

Signed-off-by: KONRAD Frederic 
---
  hw/virtio-blk.c |  5 -
  hw/virtio-pci.c |  2 +-
  hw/virtio.c | 41 ++---
  hw/virtio.h | 12 
  4 files changed, 27 insertions(+), 33 deletions(-)

diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 65932fd..fbb829e 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -628,11 +628,6 @@ static int virtio_blk_device_init(VirtIODevice *vdev)
  virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK,
  sizeof(struct virtio_blk_config));

-vdev->get_config = virtio_blk_update_config;
-vdev->set_config = virtio_blk_set_config;
-vdev->get_features = virtio_blk_get_features;
-vdev->set_status = virtio_blk_set_status;
-vdev->reset = virtio_blk_reset;
  s->bs = blk->conf.bs;
  s->conf = &blk->conf;
  virtio_blk_set_conf(qdev, blk);
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index e3a8276..cdc3473 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -262,7 +262,7 @@ static void virtio_ioport_write(void *opaque, uint32_t 
addr, uint32_t val)
  case VIRTIO_PCI_GUEST_FEATURES:
 /* Guest does not negotiate properly?  We have to assume nothing. */
 if (val & (1 << VIRTIO_F_BAD_FEATURE)) {
-val = vdev->bad_features ? vdev->bad_features(vdev) : 0;
+val = get_virtio_device_bad_features(proxy->bus);
 }
  virtio_set_features(vdev, val);
  break;
diff --git a/hw/virtio.c b/hw/virtio.c
index e40fa12..82bf3dd 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -517,10 +517,11 @@ void virtio_update_irq(VirtIODevice *vdev)

  void virtio_set_status(VirtIODevice *vdev, uint8_t val)
  {
+VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
  trace_virtio_set_status(vdev, val);

-if (vdev->set_status) {
-vdev->set_status(vdev, val);
+if (k->set_status) {
+k->set_status(vdev, val);
  }
  vdev->status = val;
  }
@@ -528,12 +529,14 @@ void virtio_set_status(VirtIODevice *vdev, uint8_t val)
  void virtio_reset(void *opaque)
  {
  VirtIODevice *vdev = opaque;
+VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
  int i;

  virtio_set_status(vdev, 0);

-if (vdev->reset)
-vdev->reset(vdev);
+if (k->reset) {
+k->reset(vdev);
+}

  vdev->guest_features = 0;
  vdev->queue_sel = 0;
@@ -557,9 +560,10 @@ void virtio_reset(void *opaque)

  uint32_t virtio_config_readb(VirtIODevice *vdev, uint32_t addr)
  {
+VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
  uint8_t val;

-vdev->get_config(vdev, vdev->config);
+k->get_config(vdev, vdev->config);

  if (addr > (vdev->config_len - sizeof(val)))
  return (uint32_t)-1;
@@ -570,9 +574,10 @@ uint32_t virtio_config_readb(VirtIODevice *vdev, uint32_t 
addr)

  uint32_t virtio_config_readw(VirtIODevice *vdev, uint32_t addr)
  {
+VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
  uint16_t val;

-vdev->get_config(vdev, vdev->config);
+k->get_config(vdev, vdev->config);

  if (addr > (vdev->config_len - sizeof(val)))
  return (uint32_t)-1;
@@ -583,9 +588,10 @@ uint32_t virtio_config_readw(VirtIODevice *vdev, uint32_t 
addr)

  uint32_t virtio_config_readl(VirtIODevice *vdev, uint32_t addr)
  {
+VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
  uint32_t val;

-vdev->get_config(vdev, vdev->config);
+k->get_config(vdev, vdev->config);

  if (addr > (vdev->config_len - sizeof(val)))
  return (uint32_t)-1;
@@ -596,6 +602,7 @@ uint32_t virtio_config_readl(VirtIODevice *vdev, uint32_t 
addr)

  void virtio_config_writeb(VirtIODevice *vdev, uint32_t addr, uint32_t data)
  {
+VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
  uint8_t val = data;

  if (addr > (vdev->config_len - sizeof(val)))
@@ -603,12 +610,13 @@ void virtio_config_writeb(VirtIODevice *vdev, uint32_t 
addr, uint32_t data)

  stb_p(vdev->config + addr, val);

-if (vdev->set_config)
-vdev->set_config(vdev, vdev->config);
+if (k->set_config)

Missing braces, please use checkpatch.pl.
I don't understand, I used checkpatch.pl before submitting but it didn't 
find it.





+k->set_config(vdev, vdev->config);
  }

  void virtio_config_writew(VirtIODevice *vdev, uint32_t addr, uint32_t data)
  {
+VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);
  uint16_t val = data;

  if (addr > (vdev->config_len - sizeof(val)))
@@ -616,12 +624,13 @@ void virtio_config_writew(VirtIODevice *vdev, uint32_t 
addr, uint32_t data)

  stw_p(vdev->config + addr, val);

-if (vdev->set_config)
-vdev->set_config(vdev, vdev->config);
+if (

Re: [Qemu-devel] [RFC PATCH V8 06/15] virtio-s390-bus : Add virtio-s390-bus.

[KONRAD Frédéric]

On 19/12/2012 19:09, Cornelia Huck wrote:

On Wed, 19 Dec 2012 10:53:32 +0100
fred.kon...@greensocs.com wrote:


From: KONRAD Frederic 

Introduce virtio-s390-bus, which extends virtio-bus. It is used with s390
transport device.

Signed-off-by: KONRAD Frederic 
---
  hw/s390-virtio-bus.c | 28 
  hw/s390-virtio-bus.h | 13 +
  2 files changed, 41 insertions(+)

diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index e0ac2d1..720dbb9 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -33,6 +33,7 @@
  #include "kvm.h"

  #include "hw/s390-virtio-bus.h"
+#include "hw/virtio-bus.h"

  /* #define DEBUG_S390 */

@@ -556,8 +557,35 @@ static TypeInfo s390_virtio_bridge_info = {
  .class_init= s390_virtio_bridge_class_init,
  };

+/* virtio-s390-bus */
+
+VirtioBusState *virtio_s390_bus_new(VirtIOS390Device *dev)
+{
+DeviceState *qdev = DEVICE(dev);
+BusState *qbus = qbus_create(TYPE_VIRTIO_S390_BUS, qdev, NULL);
+VirtioBusState *bus = VIRTIO_BUS(qbus);
+qbus->allow_hotplug = 0;
+qbus->max_dev = 1;
+return bus;
+}
+
+static void virtio_s390_bus_class_init(ObjectClass *klass, void *data)
+{
+VirtioBusClass *k = VIRTIO_BUS_CLASS(klass);
+k->notify = virtio_s390_notify;
+k->get_features = virtio_s390_get_features;
+}
+
+static const TypeInfo virtio_s390_bus_info = {
+.name  = TYPE_VIRTIO_S390_BUS,
+.parent= TYPE_VIRTIO_BUS,
+.instance_size = sizeof(VirtioBusState),
+.class_init= virtio_s390_bus_class_init,
+};
+
  static void s390_virtio_register_types(void)
  {
+type_register_static(&virtio_s390_bus_info);
  type_register_static(&s390_virtio_bus_info);
  type_register_static(&virtio_s390_device_info);
  type_register_static(&s390_virtio_serial);
diff --git a/hw/s390-virtio-bus.h b/hw/s390-virtio-bus.h
index a83afe7..7c5a945 100644
--- a/hw/s390-virtio-bus.h
+++ b/hw/s390-virtio-bus.h
@@ -22,6 +22,7 @@
  #include "virtio-rng.h"
  #include "virtio-serial.h"
  #include "virtio-scsi.h"
+#include "virtio-bus.h"

  #define VIRTIO_DEV_OFFS_TYPE  0   /* 8 bits */
  #define VIRTIO_DEV_OFFS_NUM_VQ1   /* 8 bits */
@@ -57,8 +58,20 @@
  #define S390_VIRTIO_BUS(obj) \
   OBJECT_CHECK(VirtIOS390Bus, (obj), TYPE_S390_VIRTIO_BUS)

+/* virtio-s390-bus */
+
+#define TYPE_VIRTIO_S390_BUS "virtio-s390-bus"
+#define VIRTIO_S390_BUS_GET_CLASS(obj) \
+OBJECT_GET_CLASS(VirtioBusClass, obj, TYPE_VIRTIO_S390_BUS)
+#define VIRTIO_PCI_BUS_CLASS(klass) \
+OBJECT_CLASS_CHECK(VirtioBusClass, klass, TYPE_VIRTIO_S390_BUS)
+#define VIRTIO_PCI_BUS(obj) \
+OBJECT_CHECK(VirtioBusState, (obj), TYPE_VIRTIO_S390_BUS)

PCI? This looks wrong.

oops, yes sorry for that.
It didn't complain as I don't use the VirtioBusClass for the moment.

I fixed it.

Thanks.



+
  typedef struct VirtIOS390Device VirtIOS390Device;

+VirtioBusState *virtio_s390_bus_new(VirtIOS390Device *dev);
+
  typedef struct VirtIOS390DeviceClass {
  DeviceClass qdev;
  int (*init)(VirtIOS390Device *dev);

Re: [Qemu-devel] [RFC PATCH V8 04/15] virtio-pci : Refactor virtio-pci device.

[KONRAD Frédéric]

On 02/01/2013 15:14, Anthony Liguori wrote:

fred.kon...@greensocs.com writes:


From: KONRAD Frederic 

Create the virtio-pci device. This transport device will create a
virtio-pci-bus, so one VirtIODevice can be connected.

Signed-off-by: KONRAD Frederic 
---
  hw/virtio-pci.c | 130 
  hw/virtio-pci.h |  19 +
  2 files changed, 149 insertions(+)

diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 859a1ed..916ed7c 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -1118,6 +1118,133 @@ static TypeInfo virtio_scsi_info = {
  .class_init= virtio_scsi_class_init,
  };
  
+/*

+ * virtio-pci : This is the PCIDevice which have a virtio-pci-bus.
+ */
+
+/* This is called by virtio-bus just after the device is plugged. */
+static void virtio_pci_device_plugged(void *opaque)
+{
+VirtIOPCIProxy *proxy = VIRTIO_PCI(opaque);
+VirtioBusState *bus = proxy->bus;
+uint8_t *config;
+uint32_t size;
+
+/* Put the PCI IDs */
+switch (get_virtio_device_id(proxy->bus)) {
+
+
+default:
+error_report("unknown device id\n");
+break;
+
+}
+
+/*
+ * vdev shouldn't be accessed directly by virtio-pci.
+ * We will remove that at the end of the series to keep virtio-x-pci
+ * working.
+ */
+proxy->vdev = proxy->bus->vdev;
+/*
+ */
+
+config = proxy->pci_dev.config;
+if (proxy->class_code) {
+pci_config_set_class(config, proxy->class_code);
+}
+pci_set_word(config + PCI_SUBSYSTEM_VENDOR_ID,
+ pci_get_word(config + PCI_VENDOR_ID));
+pci_set_word(config + PCI_SUBSYSTEM_ID, get_virtio_device_id(proxy->bus));
+config[PCI_INTERRUPT_PIN] = 1;
+
+if (get_virtio_device_nvectors(bus) &&
+msix_init_exclusive_bar(&proxy->pci_dev,
+get_virtio_device_nvectors(bus), 1)) {
+set_virtio_device_nvectors(bus, 0);
+}
+
+proxy->pci_dev.config_write = virtio_write_config;
+
+size = VIRTIO_PCI_REGION_SIZE(&proxy->pci_dev)
+ + get_virtio_device_config_len(bus);
+if (size & (size-1)) {
+size = 1 << qemu_fls(size);
+}
+
+memory_region_init_io(&proxy->bar, &virtio_pci_config_ops, proxy,
+  "virtio-pci", size);
+pci_register_bar(&proxy->pci_dev, 0, PCI_BASE_ADDRESS_SPACE_IO,
+ &proxy->bar);
+
+if (!kvm_has_many_ioeventfds()) {
+proxy->flags &= ~VIRTIO_PCI_FLAG_USE_IOEVENTFD;
+}
+
+proxy->host_features |= 0x1 << VIRTIO_F_NOTIFY_ON_EMPTY;
+proxy->host_features |= 0x1 << VIRTIO_F_BAD_FEATURE;
+proxy->host_features = get_virtio_device_features(bus,
+  proxy->host_features);
+}
+
+/* This is called by virtio-bus just before the device is unplugged. */
+static void virtio_pci_device_unplug(void *opaque)
+{
+VirtIOPCIProxy *dev = VIRTIO_PCI(opaque);
+virtio_pci_stop_ioeventfd(dev);
+}
+
+static int virtio_pci_init(PCIDevice *pci_dev)
+{
+VirtIOPCIProxy *dev = VIRTIO_PCI(pci_dev);
+VirtioPCIClass *k = VIRTIO_PCI_GET_CLASS(pci_dev);
+dev->bus = virtio_pci_bus_new(dev);
+if (k->init != NULL) {
+return k->init(dev);
+}
+return 0;
+}
+
+static void virtio_pci_exit(PCIDevice *pci_dev)
+{
+VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev);
+VirtioBusState *bus = VIRTIO_BUS(proxy->bus);
+BusState *qbus = BUS(proxy->bus);
+virtio_bus_destroy_device(bus);
+qbus_free(qbus);
+}
+
+static void virtio_pci_rst(DeviceState *qdev)

s/rst/reset/

Regards,

Anthony Liguori

virtio_pci_reset conflicts with another function.
Can I add a step to renamed it at the end when virtio_pci_reset is unused ?




+{
+VirtIOPCIProxy *proxy = VIRTIO_PCI(qdev);
+VirtioBusState *bus = VIRTIO_BUS(proxy->bus);
+virtio_pci_stop_ioeventfd(proxy);
+virtio_bus_reset(bus);
+msix_unuse_all_vectors(&proxy->pci_dev);
+proxy->flags &= ~VIRTIO_PCI_FLAG_BUS_MASTER_BUG;
+}
+
+static void virtio_pci_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+k->init = virtio_pci_init;
+k->exit = virtio_pci_exit;
+k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+k->revision = VIRTIO_PCI_ABI_VERSION;
+k->class_id = PCI_CLASS_OTHERS;
+dc->reset = virtio_pci_rst;
+}
+
+static const TypeInfo virtio_pci_info = {
+.name  = TYPE_VIRTIO_PCI,
+.parent= TYPE_PCI_DEVICE,
+.instance_size = sizeof(VirtIOPCIProxy),
+.class_init= virtio_pci_class_init,
+.class_size= sizeof(VirtioPCIClass),
+};
+
  /* virtio-pci-bus */
  
  VirtioBusState *virtio_pci_bus_new(VirtIOPCIProxy *dev)

@@ -1144,6 +1271,8 @@ static void virtio_pci_bus_class_init(ObjectClass *klass, 
void *data)
  k->set_host_notifier = virtio_pci_set_host_notifier;
  k->set_guest_notifiers = virtio_pci_set_guest_notifiers;
  k->

Re: [Qemu-devel] [RFC PATCH V8 01/15] qdev : add a maximum device allowed field for the bus.

[KONRAD Frédéric]

On 02/01/2013 15:16, Andreas Färber wrote:

Am 02.01.2013 15:08, schrieb Anthony Liguori:

fred.kon...@greensocs.com writes:


From: KONRAD Frederic 

Add a max_dev field to BusState to specify the maximum amount of devices allowed
on the bus ( have no effect if max_dev=0 )

Signed-off-by: KONRAD Frederic 
---
  hw/qdev-core.h|  2 ++
  hw/qdev-monitor.c | 11 +++
  2 files changed, 13 insertions(+)

diff --git a/hw/qdev-core.h b/hw/qdev-core.h
index d672cca..af909b9 100644
--- a/hw/qdev-core.h
+++ b/hw/qdev-core.h
@@ -104,6 +104,8 @@ struct BusState {
  const char *name;
  int allow_hotplug;
  int max_index;
+/* maximum devices allowed on the bus, 0 : no limit. */
+int max_dev;

Can't for the virtio-bus case (which this is for AFAIU) the same effect
be achieved by setting max_index? If not, this could use some more
documentation - btw using gtk-doc style comments (above struct) would be
a bonus.
no, max_index is just a variable which count the number of bus children 
I think.

max_index is incremented each time bus_add_child is called.

maybe the name max_index is not a good choice ?



Regards,
Andreas

P.S. Please remember to use English punctuation rules, i.e. no spaces
before colon or inside parenthesis. ;)

:s sorry for that.

Re: [Qemu-devel] [RFC PATCH V8 02/15] virtio-bus : Introduce virtio-bus

[KONRAD Frédéric]

On 02/01/2013 15:12, Anthony Liguori wrote:

fred.kon...@greensocs.com writes:


From: KONRAD Frederic 

Introduce virtio-bus. Refactored transport device will create a bus which
extends virtio-bus.

Signed-off-by: KONRAD Frederic 
---
  hw/Makefile.objs |   1 +
  hw/virtio-bus.c  | 169 +++
  hw/virtio-bus.h  |  98 
  3 files changed, 268 insertions(+)
  create mode 100644 hw/virtio-bus.c
  create mode 100644 hw/virtio-bus.h

diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index d581d8d..6fa4de4 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -3,6 +3,7 @@ common-obj-y += loader.o
  common-obj-$(CONFIG_VIRTIO) += virtio-console.o
  common-obj-$(CONFIG_VIRTIO) += virtio-rng.o
  common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
+common-obj-$(CONFIG_VIRTIO) += virtio-bus.o
  common-obj-y += fw_cfg.o
  common-obj-$(CONFIG_PCI) += pci.o pci_bridge.o pci_bridge_dev.o
  common-obj-$(CONFIG_PCI) += msix.o msi.o
diff --git a/hw/virtio-bus.c b/hw/virtio-bus.c
new file mode 100644
index 000..7a3d06e
--- /dev/null
+++ b/hw/virtio-bus.c
@@ -0,0 +1,169 @@
+/*
+ * VirtioBus
+ *
+ *  Copyright (C) 2012 : GreenSocs Ltd
+ *  http://www.greensocs.com/ , email: i...@greensocs.com
+ *
+ *  Developed by :
+ *  Frederic Konrad   
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ */
+
+#include "hw.h"
+#include "qemu-error.h"
+#include "qdev.h"
+#include "virtio-bus.h"
+#include "virtio.h"
+
+/* #define DEBUG_VIRTIO_BUS */
+
+#ifdef DEBUG_VIRTIO_BUS
+#define DPRINTF(fmt, ...) \
+do { printf("virtio_bus: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do { } while (0)
+#endif
+
+/* Plug the VirtIODevice */
+int virtio_bus_plug_device(VirtIODevice *vdev)
+{
+DeviceState *qdev = DEVICE(vdev);
+BusState *qbus = BUS(qdev_get_parent_bus(qdev));
+VirtioBusState *bus = VIRTIO_BUS(qbus);
+VirtioBusClass *klass = VIRTIO_BUS_GET_CLASS(bus);
+DPRINTF("%s : plug device.\n", qbus->name);
+
+bus->vdev = vdev;
+
+if (klass->device_plugged != NULL) {
+klass->device_plugged(qbus->parent);
+}
+
+/*
+ * The lines below will disappear when we drop VirtIOBindings, at the end
+ * of the serie.

s/serie/series/g


+ */
+bus->bindings.notify = klass->notify;
+bus->bindings.save_config = klass->save_config;
+bus->bindings.save_queue = klass->save_queue;
+bus->bindings.load_config = klass->load_config;
+bus->bindings.load_queue = klass->load_queue;
+bus->bindings.load_done = klass->load_done;
+bus->bindings.get_features = klass->get_features;
+bus->bindings.query_guest_notifiers = klass->query_guest_notifiers;
+bus->bindings.set_guest_notifiers = klass->set_guest_notifiers;
+bus->bindings.set_host_notifier = klass->set_host_notifier;
+bus->bindings.vmstate_change = klass->vmstate_change;
+virtio_bind_device(bus->vdev, &(bus->bindings), qbus->parent);
+/*
+ */

No need for empty comment or the parens around bus->bindings.


+
+return 0;
+}
+
+/* Reset the virtio_bus */
+void virtio_bus_reset(VirtioBusState *bus)
+{
+DPRINTF("%s : reset device.\n", qbus->name);
+if (bus->vdev != NULL) {
+virtio_reset(bus->vdev);
+}
+}
+
+/* Destroy the VirtIODevice */
+void virtio_bus_destroy_device(VirtioBusState *bus)
+{
+DeviceState *qdev;
+BusState *qbus = BUS(bus);
+VirtioBusClass *klass = VIRTIO_BUS_GET_CLASS(bus);
+DPRINTF("%s : remove device.\n", qbus->name);
+
+if (bus->vdev != NULL) {
+if (klass->device_unplug != NULL) {
+klass->device_unplug(qbus->parent);
+}
+qdev = DEVICE(bus->vdev);
+qdev_free(qdev);
+bus->vdev = NULL;
+}
+}
+
+/* Get the device id of the plugged device. */
+uint16_t get_virtio_device_id(VirtioBusState *bus)
+{
+assert(bus->vdev != NULL);
+return bus->vdev->device_id;
+}
+
+/* Get the nvectors field of the plugged device. */
+int get_virtio_device_nvectors(VirtioBusState *bus)
+{
+assert(bus->vdev != NULL);
+return bus->vdev->nvectors;
+}
+
+/* Set the nvectors field of the plugged device. */
+void set_virtio_device_nvectors(VirtioBusState *bus, int nvectors)
+{
+assert(bus->vdev != NULL);
+bus->vdev->nvectors = nvectors;
+}
+
+/* Get the config_len field of the plugged device. */
+size_t

Re: [Qemu-devel] [RFC PATCH V8 01/15] qdev : add a maximum device allowed field for the bus.

[KONRAD Frédéric]

On 02/01/2013 15:08, Anthony Liguori wrote:

fred.kon...@greensocs.com writes:


From: KONRAD Frederic 

Add a max_dev field to BusState to specify the maximum amount of devices allowed
on the bus ( have no effect if max_dev=0 )

Signed-off-by: KONRAD Frederic 
---
  hw/qdev-core.h|  2 ++
  hw/qdev-monitor.c | 11 +++
  2 files changed, 13 insertions(+)

diff --git a/hw/qdev-core.h b/hw/qdev-core.h
index d672cca..af909b9 100644
--- a/hw/qdev-core.h
+++ b/hw/qdev-core.h
@@ -104,6 +104,8 @@ struct BusState {
  const char *name;
  int allow_hotplug;
  int max_index;
+/* maximum devices allowed on the bus, 0 : no limit. */
+int max_dev;
  QTAILQ_HEAD(ChildrenHead, BusChild) children;
  QLIST_ENTRY(BusState) sibling;
  };
diff --git a/hw/qdev-monitor.c b/hw/qdev-monitor.c
index a1b4d6a..7a9d275 100644
--- a/hw/qdev-monitor.c
+++ b/hw/qdev-monitor.c
@@ -292,6 +292,17 @@ static BusState *qbus_find_recursive(BusState *bus, const 
char *name,
  if (bus_typename && !object_dynamic_cast(OBJECT(bus), bus_typename)) {
  match = 0;
  }
+if ((bus->max_dev != 0) && (bus->max_dev <= bus->max_index)) {
+if (name != NULL) {
+/* bus was explicitly specified : return an error. */
+qerror_report(ERROR_CLASS_GENERIC_ERROR, "Bus '%s' is full",
+  bus->name);
+return NULL;
+} else {
+/* bus was not specified : try to find another one. */
+match = 0;
+}
+}
  if (match) {
  return bus;
  }

Nice change, but I wonder if this should be a class property instead of
an object property?  Would different objects of the same class ever set
this differently?

I don't know. What do you think is the best ?

Fred



Regards,

Anthony Liguori


--
1.7.11.7

Re: [Qemu-devel] [kvmarm] [RFC v5 7/8] hw/kvm/arm_gic: Implement support for KVM in-kernel ARM GIC

[KONRAD Frédéric]

On 24/01/2013 16:43, Peter Maydell wrote:

Implement support for using the KVM in-kernel GIC for ARM.

Signed-off-by: Peter Maydell 
---
  hw/a15mpcore.c   |8 ++-
  hw/arm/Makefile.objs |1 +
  hw/kvm/arm_gic.c |  169 ++
  3 files changed, 177 insertions(+), 1 deletion(-)
  create mode 100644 hw/kvm/arm_gic.c

diff --git a/hw/a15mpcore.c b/hw/a15mpcore.c
index fe6c34c..1ca6f28 100644
--- a/hw/a15mpcore.c
+++ b/hw/a15mpcore.c
@@ -19,6 +19,7 @@
   */
  
  #include "sysbus.h"

+#include "sysemu/kvm.h"
  
  /* A15MP private memory region.  */
  
@@ -40,8 +41,13 @@ static int a15mp_priv_init(SysBusDevice *dev)

  {
  A15MPPrivState *s = FROM_SYSBUS(A15MPPrivState, dev);
  SysBusDevice *busdev;
+const char *gictype = "arm-gic";

s/arm-gic/arm_gic/ ^^ ?

Christoffer and I had trouble with that:

qemu-system-arm: Unknown device 'arm-gic' for default sysbus

Fred
  
-s->gic = qdev_create(NULL, "arm_gic");

+if (kvm_irqchip_in_kernel()) {
+gictype = "kvm-arm-gic";
+}
+
+s->gic = qdev_create(NULL, gictype);
  qdev_prop_set_uint32(s->gic, "num-cpu", s->num_cpu);
  qdev_prop_set_uint32(s->gic, "num-irq", s->num_irq);

Re: [Qemu-devel] traversal termination in qbus_find_recursive() due to "max_dev"

[KONRAD Frédéric]

On 31/01/2013 14:23, Laszlo Ersek wrote:

Hi,

I'm working on propagating errors out to do_device_add(). I've come
accross qbus_find_recursive().

Re commit 1395af6f ("qdev: add a maximum device allowed field for the
bus."), could someone please explain:

(1) why the early termination due to max_index vs. max_dev merits an
error message -- both non-recursive call-sites print an error of their
own anyway,

(2) why the

   max_dev != 0 &&
   max_dev <= max_index &&
   name != NULL

condition justifies traversal termination -- in general, a bus called
"foo", albeit full of devices, could allow some of those devices to be a
child bus. Let's call one such (direct) child bus "bar".

If we're looking for "bar", or for one of its descendants, the current
logic seems to stop the search early, at "foo".

I think "bus_class->max_dev" should be checked only when we're actually
trying to add the device to the bus. (In qdev_set_parent_bus() -->
bus_add_child().)

- bus_add_child() should check the limit and set an Error,
- qdev_set_parent_bus_nofail() would abort() if there's an Error,
- qdev_set_parent_bus() would change signature and propagate error,
- all callers would be converted to either the new _nofail() or the old
function with the new signature.

I can try to write the patch if there's consensus about what should happen.

Thoughts?

Thanks!
Laszlo

Hi,

I don't think I understand what is a traversal termination.

But, this was added to specify a maximum amount of device on a bus.
(for virtio-bus which can have only one device connected)

1 - When you explicitly set the bus in command line with bus=...and it 
is full

  it returns the error:
  qemu-system-i386: --device virtio-net,bus=virtio-pci-bus.0: Bus 
'virtio-pci-bus.0' not found

  That's why I added the error.

2 - I understand what you mean, but does your idea allows us to connect 
a device to the first

 non-full bus?

Thanks,
Fred

Re: [Qemu-devel] [RFC 1/2] qbus_find_recursive(): don't abort search for named bus on full bus node

[KONRAD Frédéric]

On 31/01/2013 16:52, Peter Maydell wrote:

On 31 January 2013 15:42, Laszlo Ersek  wrote:

The bus we're looking for could be in the sub-tree rooted at the node
being checked; don't skip looping over the children.

Signed-off-by: Laszlo Ersek 
---
  hw/qdev-monitor.c |   10 +
  1 files changed, 1 insertions(+), 9 deletions(-)

diff --git a/hw/qdev-monitor.c b/hw/qdev-monitor.c
index 4e2a92b..34f5014 100644
--- a/hw/qdev-monitor.c
+++ b/hw/qdev-monitor.c
@@ -295,15 +295,7 @@ static BusState *qbus_find_recursive(BusState *bus, const 
char *name,
  match = 0;
  }
  if ((bus_class->max_dev != 0) && (bus_class->max_dev <= bus->max_index)) {
-if (name != NULL) {
-/* bus was explicitly specified: return an error. */
-qerror_report(ERROR_CLASS_GENERIC_ERROR, "Bus '%s' is full",
-  bus->name);
-return NULL;
-} else {
-/* bus was not specified: try to find another one. */
-match = 0;
-}
+match = 0;
  }

This looks like the wrong fix to this problem -- if the user passed
us a specific name to search for and we found it and it was full, then
we definitely want to stop here. On the other hand, if the user passed
us a specific name and this bus isn't that named bus then we shouldn't
be checking the max_index at all.

So I think the right fix is that the condition should be
   if (match && (bus_class->max_dev != 0)
   && (bus_class->max_dev <= bus->max_index)) {

and the rest of the code in this function stays as is.

-- PMM

The final result looks the same no?

If you look the qdev-monitor.c code just above the patch, you'll find 
the same thing:


if (name && (strcmp(bus->name, name) != 0)) {
match = 0;
}
if (bus_typename && !object_dynamic_cast(OBJECT(bus), bus_typename)) {
match = 0;
}
if ((bus_class->max_dev != 0) && (bus_class->max_dev <= 
bus->max_index)) {

...

Fred

Re: [Qemu-devel] [PATCH 1/3] virtio-net: pass host features to virtio_net_init

[KONRAD Frédéric]

On 06/02/2013 00:47, Jesse Larrew wrote:

From: Anthony Liguori 

Signed-off-by: Anthony Liguori 
---
  hw/s390x/s390-virtio-bus.c | 3 ++-
  hw/s390x/virtio-ccw.c  | 3 ++-
  hw/virtio-net.c| 3 ++-
  hw/virtio-pci.c| 3 ++-
  hw/virtio.h| 3 ++-
  5 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
index d467781..089ed92 100644
--- a/hw/s390x/s390-virtio-bus.c
+++ b/hw/s390x/s390-virtio-bus.c
@@ -153,7 +153,8 @@ static int s390_virtio_net_init(VirtIOS390Device *dev)
  {
  VirtIODevice *vdev;
  
-vdev = virtio_net_init((DeviceState *)dev, &dev->nic, &dev->net);

+vdev = virtio_net_init((DeviceState *)dev, &dev->nic, &dev->net,
+   dev->host_features);

Is it possible to do that without passing host_features to the init?

Virtio refactoring try to remove this virtio_x_init by creating 
virtio_net device.


Then the virtio_net_pci device create a virtio_net and pass the 
configuration to it.


How is it possible to make that compatible with the refactoring?

  if (!vdev) {
  return -1;
  }
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 231f81e..d92e427 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -555,7 +555,8 @@ static int virtio_ccw_net_init(VirtioCcwDevice *dev)
  {
  VirtIODevice *vdev;
  
-vdev = virtio_net_init((DeviceState *)dev, &dev->nic, &dev->net);

+vdev = virtio_net_init((DeviceState *)dev, &dev->nic, &dev->net,
+   dev->host_features[0]);
  if (!vdev) {
  return -1;
  }
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index e37358a..f1c2884 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -1279,7 +1279,8 @@ static void virtio_net_guest_notifier_mask(VirtIODevice 
*vdev, int idx,
  }
  
  VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf,

-  virtio_net_conf *net)
+  virtio_net_conf *net,
+  uint32_t host_features)
  {
  VirtIONet *n;
  int i;
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 9abbcdf..a869f53 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -997,7 +997,8 @@ static int virtio_net_init_pci(PCIDevice *pci_dev)

Re: [Qemu-devel] [PATCH for 1.5] virtio: make virtio device's structures public.

[KONRAD Frédéric]

oops, sorry for that, it was not supposed to be resent. :-s

Fred.

On 11/02/2013 10:37, fred.kon...@greensocs.com wrote:

From: KONRAD Frederic 

These structures must be made public to avoid two memory allocations for
refactored virtio devices.

Signed-off-by: KONRAD Frederic 
---
  hw/virtio-balloon.c| 15 ---
  hw/virtio-balloon.h| 14 ++
  hw/virtio-blk.c| 16 
  hw/virtio-blk.h| 15 +++
  hw/virtio-net.c| 41 -
  hw/virtio-net.h| 41 +
  hw/virtio-rng.c| 19 ---
  hw/virtio-rng.h| 19 +++
  hw/virtio-scsi.c   | 15 ---
  hw/virtio-scsi.h   | 16 
  hw/virtio-serial-bus.c | 41 -
  hw/virtio-serial.h | 41 +
  12 files changed, 146 insertions(+), 147 deletions(-)

diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index c0a7902..c2ad249 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -29,21 +29,6 @@
  #include 
  #endif
  
-typedef struct VirtIOBalloon

-{
-VirtIODevice vdev;
-VirtQueue *ivq, *dvq, *svq;
-uint32_t num_pages;
-uint32_t actual;
-uint64_t stats[VIRTIO_BALLOON_S_NR];
-VirtQueueElement stats_vq_elem;
-size_t stats_vq_offset;
-QEMUTimer *stats_timer;
-int64_t stats_last_update;
-int64_t stats_poll_interval;
-DeviceState *qdev;
-} VirtIOBalloon;
-
  static VirtIOBalloon *to_virtio_balloon(VirtIODevice *vdev)
  {
  return (VirtIOBalloon *)vdev;
diff --git a/hw/virtio-balloon.h b/hw/virtio-balloon.h
index b1828f4..579a1e5 100644
--- a/hw/virtio-balloon.h
+++ b/hw/virtio-balloon.h
@@ -52,4 +52,18 @@ typedef struct VirtIOBalloonStat {
  uint64_t val;
  } QEMU_PACKED VirtIOBalloonStat;
  
+typedef struct VirtIOBalloon {

+VirtIODevice vdev;
+VirtQueue *ivq, *dvq, *svq;
+uint32_t num_pages;
+uint32_t actual;
+uint64_t stats[VIRTIO_BALLOON_S_NR];
+VirtQueueElement stats_vq_elem;
+size_t stats_vq_offset;
+QEMUTimer *stats_timer;
+int64_t stats_last_update;
+int64_t stats_poll_interval;
+DeviceState *qdev;
+} VirtIOBalloon;
+
  #endif
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 34913ee..5380211 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -25,22 +25,6 @@
  # include 
  #endif
  
-typedef struct VirtIOBlock

-{
-VirtIODevice vdev;
-BlockDriverState *bs;
-VirtQueue *vq;
-void *rq;
-QEMUBH *bh;
-BlockConf *conf;
-VirtIOBlkConf *blk;
-unsigned short sector_mask;
-DeviceState *qdev;
-#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
-VirtIOBlockDataPlane *dataplane;
-#endif
-} VirtIOBlock;
-
  static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
  {
  return (VirtIOBlock *)vdev;
diff --git a/hw/virtio-blk.h b/hw/virtio-blk.h
index 43ca492..2a7aef2 100644
--- a/hw/virtio-blk.h
+++ b/hw/virtio-blk.h
@@ -108,6 +108,21 @@ struct VirtIOBlkConf
  uint32_t data_plane;
  };
  
+typedef struct VirtIOBlock {

+VirtIODevice vdev;
+BlockDriverState *bs;
+VirtQueue *vq;
+void *rq;
+QEMUBH *bh;
+BlockConf *conf;
+VirtIOBlkConf *blk;
+unsigned short sector_mask;
+DeviceState *qdev;
+#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
+VirtIOBlockDataPlane *dataplane;
+#endif
+} VirtIOBlock;
+
  #define DEFINE_VIRTIO_BLK_FEATURES(_state, _field) \
  DEFINE_VIRTIO_COMMON_FEATURES(_state, _field)
  
diff --git a/hw/virtio-net.c b/hw/virtio-net.c

index dfb9687..ba0d70b 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -26,47 +26,6 @@
  #define MAC_TABLE_ENTRIES64
  #define MAX_VLAN(1 << 12)   /* Per 802.1Q definition */
  
-typedef struct VirtIONet

-{
-VirtIODevice vdev;
-uint8_t mac[ETH_ALEN];
-uint16_t status;
-VirtQueue *rx_vq;
-VirtQueue *tx_vq;
-VirtQueue *ctrl_vq;
-NICState *nic;
-QEMUTimer *tx_timer;
-QEMUBH *tx_bh;
-uint32_t tx_timeout;
-int32_t tx_burst;
-int tx_waiting;
-uint32_t has_vnet_hdr;
-size_t host_hdr_len;
-size_t guest_hdr_len;
-uint8_t has_ufo;
-struct {
-VirtQueueElement elem;
-ssize_t len;
-} async_tx;
-int mergeable_rx_bufs;
-uint8_t promisc;
-uint8_t allmulti;
-uint8_t alluni;
-uint8_t nomulti;
-uint8_t nouni;
-uint8_t nobcast;
-uint8_t vhost_started;
-struct {
-int in_use;
-int first_multi;
-uint8_t multi_overflow;
-uint8_t uni_overflow;
-uint8_t *macs;
-} mac_table;
-uint32_t *vlans;
-DeviceState *qdev;
-} VirtIONet;
-
  /* TODO
   * - we could suppress RX interrupt if we were so inclined.
   */
diff --git a/hw/virtio-net.h b/hw/virtio-net.h
index c0bb284..609818b 100644
--- a/hw/virtio-net.h
+++ b/hw/virtio-net.h
@@ -130,6 +130,47 @@ struct virtio_net_ctrl_mac {
  uint32_t entries;
  

Re: [Qemu-devel] [PATCH for-1.5 0/8] virtio-blk refactoring.

[KONRAD Frédéric]

On 11/02/2013 12:58, Cornelia Huck wrote:

On Mon, 11 Feb 2013 10:37:20 +0100
fred.kon...@greensocs.com wrote:


From: KONRAD Frederic 

This is the next part of virtio-refactoring.

I send it now to have it reviewed.

Basically it creates virtio-blk device which extends virtio-device.
Then a virtio-blk can be connected on a virtio-bus.
virtio-blk-pci, virtio-blk-s390x, virtio-blk-ccw are created too, they extend
respectively virtio-pci, virtio-s390-device, virtio-ccw-device and have a
virtio-blk.

It is on top of "virtio: make virtio device's structures public" I posted
before, but you can checkout my branch here:

git://git.greensocs.com/qemu_virtio.git virtio-blk-v4

I made basic tests (with linux guests) on:
  * qemu-system-i386
  * qemu-system-s390x

I didn't test dataplane as I don't know how it works? Depends on linux AIO?

Stefan can you try launching dataplane with my tree?

I didn't test virtio-ccw as I don't have the hardware.

Anyone can try it on ccw hardware?

Compiles and works for me. My block device shows up in 'info qtree' as
follows:

   dev: virtual-css-bridge, id ""
 irq 0
 bus: virtual-css
   type virtual-css-bus
   dev: virtio-blk-ccw, id "virtio-disk0"
 devno = "fe.0.0815"
 drive = drive-virtio-disk0
 logical_block_size = 512
 physical_block_size = 512
 min_io_size = 0
 opt_io_size = 0
 bootindex = -1
 discard_granularity = 0
 serial = 
 scsi = on
 indirect_desc = on
 event_idx = on
 bus: virtio-disk0.0
   type virtio-ccw-bus
   dev: virtio-blk, id ""
 drive = drive-virtio-disk0
 logical_block_size = 512
 physical_block_size = 512
 min_io_size = 0
 opt_io_size = 0
 bootindex = -1
 discard_granularity = 0
 cyls = 16383
 heads = 16
 secs = 63
 serial = 
 config-wce = off
 scsi = on


That's a good news :).

Thanks for testing!

Fred

Re: [Qemu-devel] [PATCH V2 for-1.5] virtio: make virtio device's structures public.

[KONRAD Frédéric]

Is this ok for everybody?

On 12/02/2013 18:00, fred.kon...@greensocs.com wrote:

From: KONRAD Frederic 

These structures must be made public to avoid two memory allocations for
refactored virtio devices.

Changes V2 <- V1:
 * Move the dataplane include into the header (virtio-blk).

Signed-off-by: KONRAD Frederic 
---
  hw/virtio-balloon.c| 15 ---
  hw/virtio-balloon.h| 14 ++
  hw/virtio-blk.c| 19 ---
  hw/virtio-blk.h| 18 ++
  hw/virtio-net.c| 50 -
  hw/virtio-net.h| 51 ++
  hw/virtio-rng.c| 19 ---
  hw/virtio-rng.h| 19 +++
  hw/virtio-scsi.c   | 15 ---
  hw/virtio-scsi.h   | 16 
  hw/virtio-serial-bus.c | 41 
  hw/virtio-serial.h | 41 
  12 files changed, 159 insertions(+), 159 deletions(-)

diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index c0a7902..c2ad249 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -29,21 +29,6 @@
  #include 
  #endif
  
-typedef struct VirtIOBalloon

-{
-VirtIODevice vdev;
-VirtQueue *ivq, *dvq, *svq;
-uint32_t num_pages;
-uint32_t actual;
-uint64_t stats[VIRTIO_BALLOON_S_NR];
-VirtQueueElement stats_vq_elem;
-size_t stats_vq_offset;
-QEMUTimer *stats_timer;
-int64_t stats_last_update;
-int64_t stats_poll_interval;
-DeviceState *qdev;
-} VirtIOBalloon;
-
  static VirtIOBalloon *to_virtio_balloon(VirtIODevice *vdev)
  {
  return (VirtIOBalloon *)vdev;
diff --git a/hw/virtio-balloon.h b/hw/virtio-balloon.h
index b1828f4..579a1e5 100644
--- a/hw/virtio-balloon.h
+++ b/hw/virtio-balloon.h
@@ -52,4 +52,18 @@ typedef struct VirtIOBalloonStat {
  uint64_t val;
  } QEMU_PACKED VirtIOBalloonStat;
  
+typedef struct VirtIOBalloon {

+VirtIODevice vdev;
+VirtQueue *ivq, *dvq, *svq;
+uint32_t num_pages;
+uint32_t actual;
+uint64_t stats[VIRTIO_BALLOON_S_NR];
+VirtQueueElement stats_vq_elem;
+size_t stats_vq_offset;
+QEMUTimer *stats_timer;
+int64_t stats_last_update;
+int64_t stats_poll_interval;
+DeviceState *qdev;
+} VirtIOBalloon;
+
  #endif
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 34913ee..dc8f5a2 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -17,30 +17,11 @@
  #include "hw/block-common.h"
  #include "sysemu/blockdev.h"
  #include "virtio-blk.h"
-#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
-#include "hw/dataplane/virtio-blk.h"
-#endif
  #include "scsi-defs.h"
  #ifdef __linux__
  # include 
  #endif
  
-typedef struct VirtIOBlock

-{
-VirtIODevice vdev;
-BlockDriverState *bs;
-VirtQueue *vq;
-void *rq;
-QEMUBH *bh;
-BlockConf *conf;
-VirtIOBlkConf *blk;
-unsigned short sector_mask;
-DeviceState *qdev;
-#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
-VirtIOBlockDataPlane *dataplane;
-#endif
-} VirtIOBlock;
-
  static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
  {
  return (VirtIOBlock *)vdev;
diff --git a/hw/virtio-blk.h b/hw/virtio-blk.h
index 43ca492..fc6765b 100644
--- a/hw/virtio-blk.h
+++ b/hw/virtio-blk.h
@@ -16,6 +16,9 @@
  
  #include "virtio.h"

  #include "hw/block-common.h"
+#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
+#include "hw/dataplane/virtio-blk.h"
+#endif
  
  /* from Linux's linux/virtio_blk.h */
  
@@ -108,6 +111,21 @@ struct VirtIOBlkConf

  uint32_t data_plane;
  };
  
+typedef struct VirtIOBlock {

+VirtIODevice vdev;
+BlockDriverState *bs;
+VirtQueue *vq;
+void *rq;
+QEMUBH *bh;
+BlockConf *conf;
+VirtIOBlkConf *blk;
+unsigned short sector_mask;
+DeviceState *qdev;
+#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
+VirtIOBlockDataPlane *dataplane;
+#endif
+} VirtIOBlock;
+
  #define DEFINE_VIRTIO_BLK_FEATURES(_state, _field) \
  DEFINE_VIRTIO_COMMON_FEATURES(_state, _field)
  
diff --git a/hw/virtio-net.c b/hw/virtio-net.c

index 573c669..32fc8fe 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -26,56 +26,6 @@
  #define MAC_TABLE_ENTRIES64
  #define MAX_VLAN(1 << 12)   /* Per 802.1Q definition */
  
-typedef struct VirtIONetQueue {

-VirtQueue *rx_vq;
-VirtQueue *tx_vq;
-QEMUTimer *tx_timer;
-QEMUBH *tx_bh;
-int tx_waiting;
-struct {
-VirtQueueElement elem;
-ssize_t len;
-} async_tx;
-struct VirtIONet *n;
-} VirtIONetQueue;
-
-typedef struct VirtIONet
-{
-VirtIODevice vdev;
-uint8_t mac[ETH_ALEN];
-uint16_t status;
-VirtIONetQueue vqs[MAX_QUEUE_NUM];
-VirtQueue *ctrl_vq;
-NICState *nic;
-uint32_t tx_timeout;
-int32_t tx_burst;
-uint32_t has_vnet_hdr;
-size_t host_hdr_len;
-size_t guest_hdr_len;
-uint8_t has_ufo;
-int mergeable_rx_bufs;
-uint8_t promisc;
-uint8_t allmulti;
-uint8_t allu

Re: [Qemu-devel] [PATCH V2 for-1.5] virtio: make virtio device's structures public.

[KONRAD Frédéric]

On 18/02/2013 09:47, Andreas Färber wrote:

Am 12.02.2013 18:00, schrieb fred.kon...@greensocs.com:

From: KONRAD Frederic 

These structures must be made public to avoid two memory allocations for
refactored virtio devices.

Changes V2 <- V1:
 * Move the dataplane include into the header (virtio-blk).

Signed-off-by: KONRAD Frederic 
---
  hw/virtio-balloon.c| 15 ---
  hw/virtio-balloon.h| 14 ++
  hw/virtio-blk.c| 19 ---
  hw/virtio-blk.h| 18 ++
  hw/virtio-net.c| 50 -
  hw/virtio-net.h| 51 ++
  hw/virtio-rng.c| 19 ---
  hw/virtio-rng.h| 19 +++
  hw/virtio-scsi.c   | 15 ---
  hw/virtio-scsi.h   | 16 
  hw/virtio-serial-bus.c | 41 
  hw/virtio-serial.h | 41 
  12 files changed, 159 insertions(+), 159 deletions(-)

[...]

diff --git a/hw/virtio-scsi.h b/hw/virtio-scsi.h
index 8d9d15f..613deb5 100644
--- a/hw/virtio-scsi.h
+++ b/hw/virtio-scsi.h
@@ -16,6 +16,7 @@
  
  #include "virtio.h"

  #include "pci/pci.h"
+#include 

This should be "hw/scsi.h" and change log should not be in commit
message. Otherwise looks okay as a pure movement, not tested.

Regards,
Andreas


Ok,

I thought the change log was allowed as it is a one patch series.

Do you think I must remove it?

I tested it, it was breaking dataplane compilation, that's why I made 
the second version.


As it is a pure movement it don't require heaving testing right?

Thanks,
Fred

Re: [Qemu-devel] [PATCH V2 for-1.5] virtio: make virtio device's structures public.

[KONRAD Frédéric]

On 18/02/2013 09:59, Andreas Färber wrote:

Am 18.02.2013 09:53, schrieb KONRAD Frédéric:

On 18/02/2013 09:47, Andreas Färber wrote:

Am 12.02.2013 18:00, schrieb fred.kon...@greensocs.com:

From: KONRAD Frederic 

These structures must be made public to avoid two memory allocations for
refactored virtio devices.

Changes V2 <- V1:
  * Move the dataplane include into the header (virtio-blk).

Signed-off-by: KONRAD Frederic 
---
   hw/virtio-balloon.c| 15 ---
   hw/virtio-balloon.h| 14 ++
   hw/virtio-blk.c| 19 ---
   hw/virtio-blk.h| 18 ++
   hw/virtio-net.c| 50
-
   hw/virtio-net.h| 51
++
   hw/virtio-rng.c| 19 ---
   hw/virtio-rng.h| 19 +++
   hw/virtio-scsi.c   | 15 ---
   hw/virtio-scsi.h   | 16 
   hw/virtio-serial-bus.c | 41 
   hw/virtio-serial.h | 41 
   12 files changed, 159 insertions(+), 159 deletions(-)

[...]

diff --git a/hw/virtio-scsi.h b/hw/virtio-scsi.h
index 8d9d15f..613deb5 100644
--- a/hw/virtio-scsi.h
+++ b/hw/virtio-scsi.h
@@ -16,6 +16,7 @@
 #include "virtio.h"
   #include "pci/pci.h"
+#include 

This should be "hw/scsi.h" and change log should not be in commit
message. Otherwise looks okay as a pure movement, not tested.


Note that I copied this line (with ) from virtio-scsi.c.

Ok,

I thought the change log was allowed as it is a one patch series.

Do you think I must remove it?

For a one-patch series without cover letter the change log should go
under --- so that it doesn't get committed.

Ok thanks, I'll fix that.




I tested it, it was breaking dataplane compilation, that's why I made
the second version.

As it is a pure movement it don't require heaving testing right?

Compile-testing should suffice, but I didn't test whether the virtio-net
multiqueue changes for instance have broken it.

Andreas


It should work, I rebased it on the latest git before sending it.

Thanks,
Fred

Re: [Qemu-devel] [PATCH for-1.5 0/8] virtio-blk refactoring.

[KONRAD Frédéric]

On 11/02/2013 10:37, fred.kon...@greensocs.com wrote:

From: KONRAD Frederic 

This is the next part of virtio-refactoring.

I send it now to have it reviewed.

Basically it creates virtio-blk device which extends virtio-device.
Then a virtio-blk can be connected on a virtio-bus.
virtio-blk-pci, virtio-blk-s390x, virtio-blk-ccw are created too, they extend
respectively virtio-pci, virtio-s390-device, virtio-ccw-device and have a
virtio-blk.

It is on top of "virtio: make virtio device's structures public" I posted
before, but you can checkout my branch here:

git://git.greensocs.com/qemu_virtio.git virtio-blk-v4

I made basic tests (with linux guests) on:
  * qemu-system-i386
  * qemu-system-s390x

I didn't test dataplane as I don't know how it works? Depends on linux AIO?

Stefan can you try launching dataplane with my tree?

I didn't test virtio-ccw as I don't have the hardware.

Anyone can try it on ccw hardware?

Thanks.

Fred

Changes V3 -> V4:
   * Added virtio-ccw.
   * Removed virtio-blk-init/exit from virtio.h

KONRAD Frederic (8):
   virtio-blk: don't use pointer for configuration.
   virtio-blk: add the virtio-blk device.
   virtio-blk-pci: switch to new API.
   virtio-blk-s390: switch to the new API.
   virtio-blk-ccw switch to new API.
   virtio-blk: cleanup: init and exit functions.
   virtio-blk: cleanup: QOM cast
   virtio-blk: cleanup: remove qdev field.

  hw/s390x/s390-virtio-bus.c |  30 +++
  hw/s390x/s390-virtio-bus.h |  13 -
  hw/s390x/virtio-ccw.c  |  38 -
  hw/s390x/virtio-ccw.h  |  14 -
  hw/virtio-blk.c| 131 +
  hw/virtio-blk.h|  33 ++--
  hw/virtio-pci.c| 124 +++---
  hw/virtio-pci.h|  15 +-
  hw/virtio.h|   2 -
  9 files changed, 251 insertions(+), 149 deletions(-)


Is this ok, for everybody?

I did basic test with x86 guest and s390x,
Cornelia reported that it works for CCW too.

I can't test dataplane as it seems not to work with TCG.

Thanks,
Fred

Re: [Qemu-devel] [RFC v2 00/12] Virtio-mmio refactoring.

[KONRAD Frédéric]

Hi,

We actually want to add virtio models for arm, therefore these patches 
are really helpful.


We will try it, start looking at the issues.

Any feedback ?

On 17/09/2012 12:00, Evgeny Voevodin wrote:

Previous RFC you can find at
http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03665.html
Yes, long time ago...
Since I'm not sure when I'll be able to continue on this,
I'm publishing this work as is.
In this patchset I tried to split virtio-xxx-pci devices into
virtio-pci + virtio-xxx (blk, net, serial,...). Also virtio-mmio
transport is introduced based on Peter's work which is accessible
here: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01870.html

The main idea was to let users specify
-device virtio-pci,id=virtio-pci.0
-device virtio-blk,transport=virtio-pci.0,...
  
and


-device virtio-mmio,id=virtio-mmio.0
-device virtio-blk,transport=virtio-mmio.0,...

I created virtio-pci and virtio-mmio transport devices and tried to enclose
back-end functionality into virtio-blk, virtio-net, etc. On
initialization of transport device it creates a bus to which a back-end device
could be connected. Each back-end device is implemented in corresponding source
file. As for PCI transport, I temporary placed it in a new virtio-pci-new.c file
to not break a functionality of still presented virtio-xxx-pci devices.

Known issues to be resolved:
1. On creation of back-end we need to resolve somehow if props were explicitly 
set
by user.
2. Back-end device can't be initialized if there are no free bus created by 
transport,
so you can't specify
-device virtio-blk,transport=virtio-pci.0,...
-device virtio-pci,id=virtio-pci.0
3. Implement virtio-xxx-devices such that they just create virtio-pci and 
virtio-xxx
devices during initialization.
4. Refactor all remaining back-ends since I just tried blk, net, serial and 
balloon.
5. Refactor s390
6. Further?

Evgeny Voevodin (9):
   Virtio: Add transport bindings.
   hw/qdev-properties.c: Add "transport" property.
   hw/pci.c: Make pci_add_option_rom global visible
   hw/virtio-serial-bus.c: Add virtio-serial device.
   hw/virtio-balloon.c: Add virtio-balloon device.
   hw/virtio-net.c: Add virtio-net device.
   hw/virtio-blk.c: Add virtio-blk device.
   hw/virtio-pci-new.c: Add VirtIOPCI device.
   hw/exynos4210.c: Create two virtio-mmio transport instances.

Peter Maydell (3):
   virtio: Add support for guest setting of queue size
   virtio: Support transports which can specify the vring alignment
   Add MMIO based virtio transport

  hw/Makefile.objs   |3 +
  hw/exynos4210.c|   13 +
  hw/pci.c   |3 +-
  hw/pci.h   |2 +
  hw/qdev-properties.c   |   29 ++
  hw/qdev.h  |3 +
  hw/virtio-balloon.c|   42 +++
  hw/virtio-balloon.h|9 +
  hw/virtio-blk.c|   65 
  hw/virtio-blk.h|   15 +
  hw/virtio-mmio.c   |  400 +
  hw/virtio-net.c|   59 +++
  hw/virtio-net.h|   16 +
  hw/virtio-pci-new.c|  925 
  hw/virtio-pci.h|   18 +
  hw/virtio-serial-bus.c |   44 +++
  hw/virtio-serial.h |   11 +
  hw/virtio-transport.c  |  147 
  hw/virtio-transport.h  |   74 
  hw/virtio.c|   20 +-
  hw/virtio.h|2 +
  21 files changed, 1896 insertions(+), 4 deletions(-)
  create mode 100644 hw/virtio-mmio.c
  create mode 100644 hw/virtio-pci-new.c
  create mode 100644 hw/virtio-transport.c
  create mode 100644 hw/virtio-transport.h

[Qemu-devel] Virtio devices with mmio.

[KONRAD Frédéric]

Hi,

We are actually trying to use virtio devices with Virt-mmio bus.

The idea is to use theses patches I mentioned in a previous mail 
(http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg04913.html).


We are currently drawing the plan of how we can complete theses patches 
to have it upstreamed.


Actually we have two major topics.

Backends / transport separation :

We need a good separation between backends and virtio-pci/virtio-mmio, 
actually it seems to be the case for virt-mmio but not for virtio-pci as 
the old device file is temporary kept for compability ( virtio-pci-new.c ).


Quality of code :

We need to be sure that all the devices are happy with the QOM design, 
any hints about that ?


For the moment your plan is :

Implementing virtio-xxx-pci which create virtio-pci and virtio-xxx ( as 
suggested by Evgeny Voevodin ).

Looking at the command line issues.
Refactor remaining back-ends ( virtio-scsi, virto-serial, ... ) and 
update s390.
Check the QOM design of all the modification ( virtio-mmio, transport, 
... ).


Is that making sense ? Any suggestion ?

I'll reporting back by the end of the week.

Fred

Re: [Qemu-devel] Cross-compiling QEMU for ARM

[KONRAD Frédéric]

On 10/03/2013 17:28, Leonid Bloch wrote:

On Sun, Mar 10, 2013 at 4:59 PM, Peter Maydell  wrote:

On 10 March 2013 14:36, Leonid Bloch  wrote:

I want to cross compile QEMU itself to run on ARM, but all my searches
lead me to tutorials for cross compiling other programs for ARM and
testing them with QEMU, which is not what I need.
The only relevant link I found was this:
http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg00099.html
But this doesn't work for me as well.

I am using Buildroot as my toolchain, and the farthest I got was:
$ ./configure --cpu=armv7hl --static --cc=arm-linux-cc

Don't specify --cpu : this is almost always going to break things,
and you should just let configure work it out based on your compiler.
Don't just specify --cc, because we want to run other cross tools
too. Instead, use --cross-prefix=arm-linux-gnueabi- (or whatever
the correct prefix is for your toolchain).

Tried that at first, but then getting an error:
Error: pkg-config binary 'arm-linux-pkg-config' not found


I compiled qemu for ARM with buildroot:

- You have to install pkg-config for your buildroot toolchain.
- fdt, glib, zlib...

Some of them are really tricky to cross-compile, if I remember right.

Which buildroot version are you using?

Fred

You'll also need to have a cross-build environment with the minimal
set of libraries/includes that QEMU needs to build, including
but not limited to zlib and glib. How to set this up depends on
what your cross compilation setup is; in this case you'll need to
ask the buildroot folks.

Question for the qemu-devel folks: does anybody have a situation
where they genuinely need to pass --cpu to configure (ie the
autodetection is wrong or insufficient)? [configure does mention
one case, which is when cross-compiling to x86 Darwin and SunOS,
but the latter at least is busted anyway because later on we
do things based on SunOS uname results which there is no way
to override for the cross-compile case.] I'm tempted to suggest
we should drop --cpu entirely...

-- PMM

Re: [Qemu-devel] [PATCH 09/18] hw: include hw header files with full paths

[KONRAD Frédéric]

On 01/03/2013 14:33, Paolo Bonzini wrote:

Done with this script:

cd hw
for i in `find . -name '*.h' | sed 's/^..//'`; do
   echo '\,^#.*include.*["<]'$i'[">], s,'$i',hw/&,'
done | sed -i -f - `find . -type f`

This is so that paths remain valid as files are moved.

Instead, files in hw/dataplane are referenced with the relative path.
We know they are not going to move to include/, and they are the only
include files that are in subdirectories _and_ move.

Signed-off-by: Paolo Bonzini 

Hi Paolo,
  
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c

index 34913ee..248a966 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -16,11 +16,11 @@
  #include "trace.h"
  #include "hw/block-common.h"
  #include "sysemu/blockdev.h"
-#include "virtio-blk.h"
+#include "hw/virtio-blk.h"
  #ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
-#include "hw/dataplane/virtio-blk.h"
+#include "dataplane/virtio-blk.h"

Is that normal? ^^
Or I missed something?
I though you include hw header with full paths?

Thanks,

Fred

Re: [Qemu-devel] [PATCH 09/18] hw: include hw header files with full paths

[KONRAD Frédéric]

On 12/03/2013 09:19, KONRAD Frédéric wrote:

On 01/03/2013 14:33, Paolo Bonzini wrote:

Done with this script:

cd hw
for i in `find . -name '*.h' | sed 's/^..//'`; do
   echo '\,^#.*include.*["<]'$i'[">], s,'$i',hw/&,'
done | sed -i -f - `find . -type f`

This is so that paths remain valid as files are moved.

Instead, files in hw/dataplane are referenced with the relative path.
We know they are not going to move to include/, and they are the only
include files that are in subdirectories _and_ move.



Sorry for the noise, I didn't saw that. :-s.

Fred

Signed-off-by: Paolo Bonzini 

Hi Paolo,

  diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 34913ee..248a966 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -16,11 +16,11 @@
  #include "trace.h"
  #include "hw/block-common.h"
  #include "sysemu/blockdev.h"
-#include "virtio-blk.h"
+#include "hw/virtio-blk.h"
  #ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
-#include "hw/dataplane/virtio-blk.h"
+#include "dataplane/virtio-blk.h"

Is that normal? ^^
Or I missed something?
I though you include hw header with full paths?

Thanks,

Fred

Re: [Qemu-devel] [PATCH v6 2/8] virtio-blk: add the virtio-blk device.

[KONRAD Frédéric]

On 12/03/2013 15:28, Peter Maydell wrote:

On 12 March 2013 09:22,   wrote:

  /* The ID for virtio_block */
@@ -130,4 +134,28 @@ typedef struct VirtIOBlock {
  #define DEFINE_VIRTIO_BLK_FEATURES(_state, _field) \
  DEFINE_VIRTIO_COMMON_FEATURES(_state, _field)

+#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
+#define DEFINE_DATA_PLANE_PROPERTIES(_state, _field)  \
+DEFINE_PROP_BIT("x-data-plane", _state, _field.data_plane, 0, false),
+#else
+#define DEFINE_DATA_PLANE_PROPERTIES(_state, _field)
+#endif /* CONFIG_VIRTIO_BLK_DATA_PLANE */
+
+#ifdef __linux__
+#define DEFINE_VIRTIO_BLK_SCSI_PROPERTY(_state, _field)   \
+DEFINE_PROP_BIT("scsi", _state, _field.scsi, 0, true),
+#else
+#define DEFINE_VIRTIO_BLK_SCSI_PROPERTY(_state, _field)
+#endif /* __linux__ */
+
+#define DEFINE_VIRTIO_BLK_PROPERTIES(_state, _field)  \
+DEFINE_BLOCK_PROPERTIES(_state, _field.conf), \
+DEFINE_BLOCK_CHS_PROPERTIES(_state, _field.conf), \
+DEFINE_PROP_STRING("serial", _state, _field.serial),  \
+DEFINE_PROP_BIT("config-wce", _state, _field.config_wce, 0, true),\
+DEFINE_VIRTIO_BLK_SCSI_PROPERTY(_state, _field)   \
+DEFINE_DATA_PLANE_PROPERTIES(_state, _field)
+
+void virtio_blk_set_conf(DeviceState *dev, VirtIOBlkConf *blk);
+
  #endif
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 39c1966..9ed0228 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -1084,19 +1084,10 @@ static void virtio_rng_exit_pci(PCIDevice *pci_dev)

  static Property virtio_blk_properties[] = {
  DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
-DEFINE_BLOCK_PROPERTIES(VirtIOPCIProxy, blk.conf),
-DEFINE_BLOCK_CHS_PROPERTIES(VirtIOPCIProxy, blk.conf),
-DEFINE_PROP_STRING("serial", VirtIOPCIProxy, blk.serial),
-#ifdef __linux__
-DEFINE_PROP_BIT("scsi", VirtIOPCIProxy, blk.scsi, 0, true),
-#endif
-DEFINE_PROP_BIT("config-wce", VirtIOPCIProxy, blk.config_wce, 0, true),
  DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, 
VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
-#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
-DEFINE_PROP_BIT("x-data-plane", VirtIOPCIProxy, blk.data_plane, 0, false),
-#endif
  DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
  DEFINE_VIRTIO_BLK_FEATURES(VirtIOPCIProxy, host_features),
+DEFINE_VIRTIO_BLK_PROPERTIES(VirtIOPCIProxy, blk)
  DEFINE_PROP_END_OF_LIST(),

You need to tweak your macro definitions so that the user can
put a comma after DEFINE_VIRTIO_BLK_PROPERTIES() [compare
DEFINE_BLOCK_PROPERTIES and DEFINE_BLOCK_CHS_PROPERTIES].
Otherwise it's going to get confusing and somebody's going
to add one without noticing that that gets you an extra
empty properties array element.

Do you have any idea for that?

It's a little tricky with the two conditions 
CONFIG_VIRTIO_BLK_DATA_PLANE and __linux__,


I can't have #define with an #ifdef inside..

Do you see what I mean?



  };

--
1.7.11.7


-- PMM

Re: [Qemu-devel] [PATCH v6 2/8] virtio-blk: add the virtio-blk device.

[KONRAD Frédéric]

On 12/03/2013 15:42, Peter Maydell wrote:

On 12 March 2013 14:37, KONRAD Frédéric  wrote:

On 12/03/2013 15:28, Peter Maydell wrote:

On 12 March 2013 09:22,   wrote:

   /* The ID for virtio_block */
@@ -130,4 +134,28 @@ typedef struct VirtIOBlock {
   #define DEFINE_VIRTIO_BLK_FEATURES(_state, _field) \
   DEFINE_VIRTIO_COMMON_FEATURES(_state, _field)

+#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
+#define DEFINE_DATA_PLANE_PROPERTIES(_state, _field)
\
+DEFINE_PROP_BIT("x-data-plane", _state, _field.data_plane, 0,
false),
+#else
+#define DEFINE_DATA_PLANE_PROPERTIES(_state, _field)
+#endif /* CONFIG_VIRTIO_BLK_DATA_PLANE */
+
+#ifdef __linux__
+#define DEFINE_VIRTIO_BLK_SCSI_PROPERTY(_state, _field)
\
+DEFINE_PROP_BIT("scsi", _state, _field.scsi, 0, true),
+#else
+#define DEFINE_VIRTIO_BLK_SCSI_PROPERTY(_state, _field)
+#endif /* __linux__ */
+
+#define DEFINE_VIRTIO_BLK_PROPERTIES(_state, _field)
\
+DEFINE_BLOCK_PROPERTIES(_state, _field.conf),
\
+DEFINE_BLOCK_CHS_PROPERTIES(_state, _field.conf),
\
+DEFINE_PROP_STRING("serial", _state, _field.serial),
\
+DEFINE_PROP_BIT("config-wce", _state, _field.config_wce, 0,
true),\
+DEFINE_VIRTIO_BLK_SCSI_PROPERTY(_state, _field)
\
+DEFINE_DATA_PLANE_PROPERTIES(_state, _field)
+
+void virtio_blk_set_conf(DeviceState *dev, VirtIOBlkConf *blk);
+
   #endif
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 39c1966..9ed0228 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -1084,19 +1084,10 @@ static void virtio_rng_exit_pci(PCIDevice
*pci_dev)

   static Property virtio_blk_properties[] = {
   DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
-DEFINE_BLOCK_PROPERTIES(VirtIOPCIProxy, blk.conf),
-DEFINE_BLOCK_CHS_PROPERTIES(VirtIOPCIProxy, blk.conf),
-DEFINE_PROP_STRING("serial", VirtIOPCIProxy, blk.serial),
-#ifdef __linux__
-DEFINE_PROP_BIT("scsi", VirtIOPCIProxy, blk.scsi, 0, true),
-#endif
-DEFINE_PROP_BIT("config-wce", VirtIOPCIProxy, blk.config_wce, 0,
true),
   DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
-#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
-DEFINE_PROP_BIT("x-data-plane", VirtIOPCIProxy, blk.data_plane, 0,
false),
-#endif
   DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
   DEFINE_VIRTIO_BLK_FEATURES(VirtIOPCIProxy, host_features),
+DEFINE_VIRTIO_BLK_PROPERTIES(VirtIOPCIProxy, blk)
   DEFINE_PROP_END_OF_LIST(),

You need to tweak your macro definitions so that the user can
put a comma after DEFINE_VIRTIO_BLK_PROPERTIES() [compare
DEFINE_BLOCK_PROPERTIES and DEFINE_BLOCK_CHS_PROPERTIES].
Otherwise it's going to get confusing and somebody's going
to add one without noticing that that gets you an extra
empty properties array element.

Do you have any idea for that?

It's a little tricky with the two conditions CONFIG_VIRTIO_BLK_DATA_PLANE
and __linux__,

I can't have #define with an #ifdef inside..

Do you see what I mean?

Yes, I see your problem there, but DEFINE_VIRTIO_BLK_SCSI_PROPERTY
and DEFINE_DATA_PLANE_PROPERTIES are just convenience macros, not
ones that are expected to be used by other code, right? So you can
define them with commas (and name them something so it's obvious
they're not intended for wider use as property array elements),
and then just make sure your public-facing DEFINE_VIRTIO_BLK_PROPERTIES
doesn't end with a comma. (You can do that by putting the macros
that expand to maybe-comma-or-not at the front, not the end.)

-- PMM

ok, I can put a comment which say not to use them?

Thanks,

Fred

Re: [Qemu-devel] [PATCH v6 2/8] virtio-blk: add the virtio-blk device.

[KONRAD Frédéric]

On 12/03/2013 16:12, Peter Maydell wrote:

On 12 March 2013 15:08, KONRAD Frédéric  wrote:

On 12/03/2013 15:42, Peter Maydell wrote:

Yes, I see your problem there, but DEFINE_VIRTIO_BLK_SCSI_PROPERTY
and DEFINE_DATA_PLANE_PROPERTIES are just convenience macros, not
ones that are expected to be used by other code, right? So you can
define them with commas (and name them something so it's obvious
they're not intended for wider use as property array elements),
and then just make sure your public-facing DEFINE_VIRTIO_BLK_PROPERTIES
doesn't end with a comma. (You can do that by putting the macros
that expand to maybe-comma-or-not at the front, not the end.)

-- PMM

ok, I can put a comment which say not to use them?

And suitable macro names (ie not ones which look like all
the other DEFINE_FOO_PROPERTIES ones). Alternatively since the
macro's only used once as far as I can see, you could just not
bother to abstract it out. The virtio-ccw blk properties still
just have inline #ifdefs for the scsi prop for instance.

-- PMM


The macro is used for virtio-blk device and virtio-blk-pci.
s390x devices don't use the same properties.

Re: [Qemu-devel] [PATCH v6 2/8] virtio-blk: add the virtio-blk device.

[KONRAD Frédéric]

On 12/03/2013 17:31, Cornelia Huck wrote:

On Tue, 12 Mar 2013 16:22:22 +0100
KONRAD Frédéric  wrote:


On 12/03/2013 16:12, Peter Maydell wrote:

On 12 March 2013 15:08, KONRAD Frédéric  wrote:

On 12/03/2013 15:42, Peter Maydell wrote:

Yes, I see your problem there, but DEFINE_VIRTIO_BLK_SCSI_PROPERTY
and DEFINE_DATA_PLANE_PROPERTIES are just convenience macros, not
ones that are expected to be used by other code, right? So you can
define them with commas (and name them something so it's obvious
they're not intended for wider use as property array elements),
and then just make sure your public-facing DEFINE_VIRTIO_BLK_PROPERTIES
doesn't end with a comma. (You can do that by putting the macros
that expand to maybe-comma-or-not at the front, not the end.)

-- PMM

ok, I can put a comment which say not to use them?

And suitable macro names (ie not ones which look like all
the other DEFINE_FOO_PROPERTIES ones). Alternatively since the
macro's only used once as far as I can see, you could just not
bother to abstract it out. The virtio-ccw blk properties still
just have inline #ifdefs for the scsi prop for instance.

-- PMM

The macro is used for virtio-blk device and virtio-blk-pci.
s390x devices don't use the same properties.


Looking at the s390 devices, the difference seems to be the following:

- CHS - missing on virtio-ccw, I'll do a patch.
- config_wce - missing on s390-virtio and virtio-ccw, should probably
   be added.
- x-data-plane - we plan to add this eventually to virtio-ccw, but not
   to s390-virtio. Could that be split out from the generic properties?


ok, so what I can do is:

- split up x-data-plane property (so it will be only in virtio-pci.c).
- fix this comma thing.

Then when you put these two missing properties you can just replace all 
of them

 with the macro.

Is that ok for everybody? Peter? Stefan?

Thanks for replies,

Fred

Re: [Qemu-devel] [PATCH v6 2/8] virtio-blk: add the virtio-blk device.

[KONRAD Frédéric]

On 13/03/2013 09:24, KONRAD Frédéric wrote:

On 12/03/2013 17:31, Cornelia Huck wrote:

On Tue, 12 Mar 2013 16:22:22 +0100
KONRAD Frédéric  wrote:


On 12/03/2013 16:12, Peter Maydell wrote:
On 12 March 2013 15:08, KONRAD Frédéric  
wrote:

On 12/03/2013 15:42, Peter Maydell wrote:

Yes, I see your problem there, but DEFINE_VIRTIO_BLK_SCSI_PROPERTY
and DEFINE_DATA_PLANE_PROPERTIES are just convenience macros, not
ones that are expected to be used by other code, right? So you can
define them with commas (and name them something so it's obvious
they're not intended for wider use as property array elements),
and then just make sure your public-facing 
DEFINE_VIRTIO_BLK_PROPERTIES

doesn't end with a comma. (You can do that by putting the macros
that expand to maybe-comma-or-not at the front, not the end.)

-- PMM

ok, I can put a comment which say not to use them?

And suitable macro names (ie not ones which look like all
the other DEFINE_FOO_PROPERTIES ones). Alternatively since the
macro's only used once as far as I can see, you could just not
bother to abstract it out. The virtio-ccw blk properties still
just have inline #ifdefs for the scsi prop for instance.

-- PMM

The macro is used for virtio-blk device and virtio-blk-pci.
s390x devices don't use the same properties.


Looking at the s390 devices, the difference seems to be the following:

- CHS - missing on virtio-ccw, I'll do a patch.
- config_wce - missing on s390-virtio and virtio-ccw, should probably
   be added.
- x-data-plane - we plan to add this eventually to virtio-ccw, but not
   to s390-virtio. Could that be split out from the generic properties?


ok, so what I can do is:

- split up x-data-plane property (so it will be only in virtio-pci.c).
- fix this comma thing.

Then when you put these two missing properties you can just replace 
all of them

 with the macro.

Is that ok for everybody? Peter? Stefan?


Any other suggestion?

Thanks,

Fred

Re: [Qemu-devel] [PATCH v6 2/8] virtio-blk: add the virtio-blk device.

[KONRAD Frédéric]

On 14/03/2013 08:25, Cornelia Huck wrote:

On Wed, 13 Mar 2013 16:32:31 +0100
KONRAD Frédéric  wrote:


On 13/03/2013 09:24, KONRAD Frédéric wrote:

On 12/03/2013 17:31, Cornelia Huck wrote:

On Tue, 12 Mar 2013 16:22:22 +0100
KONRAD Frédéric  wrote:


On 12/03/2013 16:12, Peter Maydell wrote:

On 12 March 2013 15:08, KONRAD Frédéric 
wrote:

On 12/03/2013 15:42, Peter Maydell wrote:

Yes, I see your problem there, but DEFINE_VIRTIO_BLK_SCSI_PROPERTY
and DEFINE_DATA_PLANE_PROPERTIES are just convenience macros, not
ones that are expected to be used by other code, right? So you can
define them with commas (and name them something so it's obvious
they're not intended for wider use as property array elements),
and then just make sure your public-facing
DEFINE_VIRTIO_BLK_PROPERTIES
doesn't end with a comma. (You can do that by putting the macros
that expand to maybe-comma-or-not at the front, not the end.)

-- PMM

ok, I can put a comment which say not to use them?

And suitable macro names (ie not ones which look like all
the other DEFINE_FOO_PROPERTIES ones). Alternatively since the
macro's only used once as far as I can see, you could just not
bother to abstract it out. The virtio-ccw blk properties still
just have inline #ifdefs for the scsi prop for instance.

-- PMM

The macro is used for virtio-blk device and virtio-blk-pci.
s390x devices don't use the same properties.


Looking at the s390 devices, the difference seems to be the following:

- CHS - missing on virtio-ccw, I'll do a patch.
- config_wce - missing on s390-virtio and virtio-ccw, should probably
be added.
- x-data-plane - we plan to add this eventually to virtio-ccw, but not
to s390-virtio. Could that be split out from the generic properties?


ok, so what I can do is:

- split up x-data-plane property (so it will be only in virtio-pci.c).
- fix this comma thing.

Then when you put these two missing properties you can just replace
all of them
  with the macro.

Is that ok for everybody? Peter? Stefan?


Any other suggestion?

I currently have the following two patches sitting in my pending queue
(git://github.com/cohuck/qemu virtio-ccw-pending); I'll probably submit
them once my current pull request is through.

On top of this, s390-virtio and virtio-ccw could use the generic macro
for the virtio-blk properties from the start if x-data-plane is split
out (I can add it to virtio-ccw once we support it).


Ok good,

And what about config-wce property for virtio-blk-s390x? It is missing too.

Fred

Re: [Qemu-devel] [PATCH v6 2/8] virtio-blk: add the virtio-blk device.

[KONRAD Frédéric]

On 14/03/2013 09:42, Cornelia Huck wrote:

On Thu, 14 Mar 2013 09:37:54 +0100
KONRAD Frédéric  wrote:


On 14/03/2013 08:25, Cornelia Huck wrote:

On Wed, 13 Mar 2013 16:32:31 +0100
KONRAD Frédéric  wrote:


On 13/03/2013 09:24, KONRAD Frédéric wrote:

On 12/03/2013 17:31, Cornelia Huck wrote:

On Tue, 12 Mar 2013 16:22:22 +0100
KONRAD Frédéric  wrote:


On 12/03/2013 16:12, Peter Maydell wrote:

On 12 March 2013 15:08, KONRAD Frédéric 
wrote:

On 12/03/2013 15:42, Peter Maydell wrote:

Yes, I see your problem there, but DEFINE_VIRTIO_BLK_SCSI_PROPERTY
and DEFINE_DATA_PLANE_PROPERTIES are just convenience macros, not
ones that are expected to be used by other code, right? So you can
define them with commas (and name them something so it's obvious
they're not intended for wider use as property array elements),
and then just make sure your public-facing
DEFINE_VIRTIO_BLK_PROPERTIES
doesn't end with a comma. (You can do that by putting the macros
that expand to maybe-comma-or-not at the front, not the end.)

-- PMM

ok, I can put a comment which say not to use them?

And suitable macro names (ie not ones which look like all
the other DEFINE_FOO_PROPERTIES ones). Alternatively since the
macro's only used once as far as I can see, you could just not
bother to abstract it out. The virtio-ccw blk properties still
just have inline #ifdefs for the scsi prop for instance.

-- PMM

The macro is used for virtio-blk device and virtio-blk-pci.
s390x devices don't use the same properties.


Looking at the s390 devices, the difference seems to be the following:

- CHS - missing on virtio-ccw, I'll do a patch.
- config_wce - missing on s390-virtio and virtio-ccw, should probably
 be added.
- x-data-plane - we plan to add this eventually to virtio-ccw, but not
 to s390-virtio. Could that be split out from the generic properties?


ok, so what I can do is:

- split up x-data-plane property (so it will be only in virtio-pci.c).
- fix this comma thing.

Then when you put these two missing properties you can just replace
all of them
   with the macro.

Is that ok for everybody? Peter? Stefan?


Any other suggestion?

I currently have the following two patches sitting in my pending queue
(git://github.com/cohuck/qemu virtio-ccw-pending); I'll probably submit
them once my current pull request is through.

On top of this, s390-virtio and virtio-ccw could use the generic macro
for the virtio-blk properties from the start if x-data-plane is split
out (I can add it to virtio-ccw once we support it).


Ok good,

And what about config-wce property for virtio-blk-s390x? It is missing too.

See the second patch :)




good, sorry for the noise :).

Thanks,

Fred

Re: [Qemu-devel] [PATCH v8 00/10] virtio-blk refactoring.

[KONRAD Frédéric]

On 15/03/2013 10:16, fred.kon...@greensocs.com wrote:

From: KONRAD Frederic 

This is the next part of virtio-refactoring.

Basically it creates virtio-blk device which extends virtio-device.
Then a virtio-blk can be connected on a virtio-bus.
virtio-blk-pci, virtio-blk-s390x, virtio-blk-ccw are created too, they extend
respectively virtio-pci, virtio-s390-device, virtio-ccw-device and have a
virtio-blk.

You can checkout my branch here:

git://project.greensocs.com/qemu-virtio.git virtio-blk-v8

I made basic tests (with linux guests) on:
  * qemu-system-i386
  * qemu-system-s390x

Cornelia made virtio-ccw test, and Stefan tried dataplane.

Changes v7 -> v8:
 * Fix the allow_hotplug assertion spotted by Anthony.

Cornelia, if you have time can you test virtio-blk hotplug with that change?

Thanks,
Fred

 * Attached the make virtio device's structures public (v4).
Changes v6 -> v7:
 * Fix the DEFINE_VIRTIO_BLK_PROPERTIES macro issue spotted by Peter.

Thanks.

Fred

KONRAD Frederic (10):
   virtio: make virtio device's structures public.
   virtio-x-bus: fix allow_hotplug assertion.
   virtio-blk: don't use pointer for configuration.
   virtio-blk: add the virtio-blk device.
   virtio-blk-pci: switch to new API.
   virtio-blk-s390: switch to the new API.
   virtio-blk-ccw switch to new API.
   virtio-blk: cleanup: init and exit functions.
   virtio-blk: cleanup: QOM cast
   virtio-blk: cleanup: remove qdev field.

  hw/s390x/s390-virtio-bus.c |  32 ++
  hw/s390x/s390-virtio-bus.h |  13 +++-
  hw/s390x/virtio-ccw.c  |  39 +++-
  hw/s390x/virtio-ccw.h  |  14 -
  hw/virtio-balloon.c|  15 -
  hw/virtio-balloon.h|  14 +
  hw/virtio-blk.c| 151 +
  hw/virtio-blk.h|  39 
  hw/virtio-net.c|  50 ---
  hw/virtio-net.h|  50 +++
  hw/virtio-pci.c| 129 +-
  hw/virtio-pci.h|  15 -
  hw/virtio-rng.c|  19 --
  hw/virtio-rng.h|  19 ++
  hw/virtio-scsi.c   |  15 -
  hw/virtio-scsi.h   |  16 +
  hw/virtio-serial-bus.c |  41 
  hw/virtio-serial.h |  41 
  hw/virtio.h|   2 -
  19 files changed, 405 insertions(+), 309 deletions(-)

Re: [Qemu-devel] [PATCH v8 00/10] virtio-blk refactoring.

[KONRAD Frédéric]

On 15/03/2013 13:44, Cornelia Huck wrote:

On Fri, 15 Mar 2013 10:19:50 +0100
KONRAD Frédéric  wrote:


On 15/03/2013 10:16, fred.kon...@greensocs.com wrote:

From: KONRAD Frederic 

This is the next part of virtio-refactoring.

Basically it creates virtio-blk device which extends virtio-device.
Then a virtio-blk can be connected on a virtio-bus.
virtio-blk-pci, virtio-blk-s390x, virtio-blk-ccw are created too, they extend
respectively virtio-pci, virtio-s390-device, virtio-ccw-device and have a
virtio-blk.

You can checkout my branch here:

git://project.greensocs.com/qemu-virtio.git virtio-blk-v8

I made basic tests (with linux guests) on:
   * qemu-system-i386
   * qemu-system-s390x

Cornelia made virtio-ccw test, and Stefan tried dataplane.

Changes v7 -> v8:
  * Fix the allow_hotplug assertion spotted by Anthony.

Cornelia, if you have time can you test virtio-blk hotplug with that change?

Sadly, no joy :(

(qemu) device_add virtio-blk-ccw,drive=drive-virtio-disk1,id=xxx

(qemu) device_del xxx
*** glibc detected *** 
/data/git/yyy/qemu/build/s390x-softmmu/qemu-system-s390x: double free or 
corruption (fasttop): 0x80cb8e30 ***

gdb says:


#15 0x03fffdb9cbee in __libc_message () from /lib64/libc.so.6
#16 0x03fffdba5146 in _int_free () from /lib64/libc.so.6
#17 0x8019fa3e in free_and_trace (mem=0x80cb8e30)
 at /data/git/yyy/qemu/vl.c:2786
#18 0x03fffded16de in g_free () from /lib64/libglib-2.0.so.0
#19 0x8019a406 in qemu_del_vm_change_state_handler (e=0x80cb8e30)
 at /data/git/yyy/qemu/vl.c:1691
#20 0x8020fd38 in virtio_common_cleanup (vdev=0x80cbb818)
 at /data/git/yyy/qemu/hw/virtio.c:892
#21 0x801fe888 in virtio_blk_device_exit (dev=0x80cbb818)
 at /data/git/yyy/qemu/hw/virtio-blk.c:694
#22 0x800bb50a in device_unparent (obj=0x80cbb818)
 at /data/git/yyy/qemu/hw/qdev.c:774
#23 0x80146956 in object_unparent (obj=0x80cbb818)
 at /data/git/yyy/qemu/qom/object.c:370
#24 0x800b92aa in qdev_free (dev=0x80cbb818)
 at /data/git/yyy/qemu/hw/qdev.c:271
#25 0x800e751c in virtio_bus_destroy_device (bus=0x80cbb740)
 at /data/git/yyy/qemu/hw/virtio-bus.c:97
#26 0x801f34f6 in virtio_ccw_blk_exit (ccw_dev=0x80cb9660)
 at /data/git/yyy/qemu/hw/s390x/virtio-ccw.c:588
#27 0x801f41c8 in virtio_ccw_busdev_exit (dev=0x80cb9660)
 at /data/git/yyy/qemu/hw/s390x/virtio-ccw.c:858
#28 0x800bb50a in device_unparent (obj=0x80cb9660)
 at /data/git/yyy/qemu/hw/qdev.c:774
#29 0x80146956 in object_unparent (obj=0x80cb9660)
 at /data/git/yyy/qemu/qom/object.c:370
#30 0x800b92aa in qdev_free (dev=0x80cb9660)
 at /data/git/yyy/qemu/hw/qdev.c:271
#31 0x801f42ec in virtio_ccw_busdev_unplug (dev=0x80cb9660)
 at /data/git/yyy/qemu/hw/s390x/virtio-ccw.c:877
#32 0x800b8e8e in qdev_unplug (dev=0x80cb9660, errp=0x3ffd388)
 at /data/git/yyy/qemu/hw/qdev.c:204
#33 0x80126610 in qmp_device_del (id=0x80cb8c80 "xxx", errp=
 0x3ffd388) at /data/git/yyy/qemu/qdev-monitor.c:626
#34 0x8008f8c2 in hmp_device_del (mon=0x80c5ff60, qdict=0x80cb6550)
 at /data/git/yyy/qemu/hmp.c:1175
#35 0x8022c73c in handle_user_command (mon=0x80c5ff60, cmdline=
 0x80c603d0 "device_del xxx") at /data/git/yyy/qemu/monitor.c:3966
#36 0x8022e7b4 in monitor_command_cb (mon=0x80c5ff60, cmdline=
 0x80c603d0 "device_del xxx", opaque=0x0)
 at /data/git/yyy/qemu/monitor.c:4582


That's with your tree +
http://marc.info/?l=qemu-devel&m=136334147200729&w=2 +
http://marc.info/?l=qemu-devel&m=136309339015104&w=2

master + the same two patches works fine.
So the issue is not this two patches, I mean the patch-set alone is not 
working

right?

I'll take a look.




Thanks,
Fred

  * Attached the make virtio device's structures public (v4).
Changes v6 -> v7:
  * Fix the DEFINE_VIRTIO_BLK_PROPERTIES macro issue spotted by Peter.

Thanks.

Fred

KONRAD Frederic (10):
virtio: make virtio device's structures public.
virtio-x-bus: fix allow_hotplug assertion.
virtio-blk: don't use pointer for configuration.
virtio-blk: add the virtio-blk device.
virtio-blk-pci: switch to new API.
virtio-blk-s390: switch to the new API.
virtio-blk-ccw switch to new API.
virtio-blk: cleanup: init and exit functions.
virtio-blk: cleanup: QOM cast
virtio-blk: cleanup: remove qdev field.

   hw/s390x/s390-virtio-bus.c |  32 ++
   hw/s390x/s390-virtio-bus.h |  13 +++-
   hw/s390x/virtio-ccw.c  |  39 +++-
   hw/s390x/virtio-ccw.h  |  14 -
   hw/virtio-balloon.c|  15 -
   hw/virtio-balloon.h|  14 +
   hw/virtio-blk.c| 151 
+
   hw/virtio-blk.h|  39 
   hw/virtio-net.c|  50 -

Re: [Qemu-devel] [PATCH v10 00/11] virtio-blk refactoring.

[KONRAD Frédéric]

On 18/03/2013 18:01, Cornelia Huck wrote:

On Mon, 18 Mar 2013 17:37:17 +0100
fred.kon...@greensocs.com wrote:


From: KONRAD Frederic 

This is the next part of virtio-refactoring.

Basically it creates virtio-blk device which extends virtio-device.
Then a virtio-blk can be connected on a virtio-bus.
virtio-blk-pci, virtio-blk-s390x, virtio-blk-ccw are created too, they extend
respectively virtio-pci, virtio-s390-device, virtio-ccw-device and have a
virtio-blk.

You can checkout my branch here:

git://project.greensocs.com/qemu-virtio.git virtio-blk-v10

Comes up fine with virtio-ccw. device_add/device_del seems to work as
well.

good thanks :).


I made basic tests (with linux guests) on:
  * qemu-system-i386
  * qemu-system-s390x

Cornelia made virtio-ccw test, and Stefan tried dataplane.

Changes v9 -> v10:
 * Fix the hot unplug issue spotted by Anthony.
Changes v8 -> v9:
 * Fix the hot unplug issue spotted by Cornelia.
Changes v7 -> v8:
 * Fix the allow_hotplug assertion spotted by Anthony.
 * Attached the make virtio device's structures public (v4).
Changes v6 -> v7:
 * Fix the DEFINE_VIRTIO_BLK_PROPERTIES macro issue spotted by Peter.

Thanks,

Fred

KONRAD Frederic (11):
   virtio: make virtio device's structures public.
   virtio-x-bus: fix allow_hotplug assertion.
   virtio-pci: fix hot unplug.
   virtio-blk: don't use pointer for configuration.
   virtio-blk: add the virtio-blk device.
   virtio-blk-pci: switch to new API.
   virtio-blk-s390: switch to the new API.
   virtio-blk-ccw switch to new API.
   virtio-blk: cleanup: init and exit functions.
   virtio-blk: cleanup: QOM cast
   virtio-blk: cleanup: remove qdev field.

  hw/s390x/s390-virtio-bus.c |  32 ++
  hw/s390x/s390-virtio-bus.h |  13 +++-
  hw/s390x/virtio-ccw.c  |  35 ++-
  hw/s390x/virtio-ccw.h  |  14 -
  hw/virtio-balloon.c|  15 -
  hw/virtio-balloon.h|  14 +
  hw/virtio-blk.c| 151 +
  hw/virtio-blk.h|  39 
  hw/virtio-net.c|  50 ---
  hw/virtio-net.h|  50 +++
  hw/virtio-pci.c| 142 ++
  hw/virtio-pci.h|  15 -
  hw/virtio-rng.c|  19 --
  hw/virtio-rng.h|  19 ++
  hw/virtio-scsi.c   |  15 -
  hw/virtio-scsi.h   |  16 +
  hw/virtio-serial-bus.c |  41 
  hw/virtio-serial.h |  41 
  hw/virtio.h|   2 -
  19 files changed, 401 insertions(+), 322 deletions(-)

Re: [Qemu-devel] [PATCH] virtio-blk: Do not segfault fault if failed to initialize dataplane

[KONRAD Frédéric]

On 19/03/2013 09:27, Dunrong Huang wrote:

$ ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 -drive 
if=none,id=drive0,cache=none,aio=native,format=raw,file=/root/Image/centos-6.4.raw
 -device virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on # 
make dataplane fail to initialize
qemu-system-x86_64: -device 
virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on: device is 
incompatible with x-data-plane, use config-wce=off
*** glibc detected *** /root/usr/bin/qemu-system-x86_64: free(): invalid 
pointer: 0x7f001fef12f8 ***
=== Backtrace: =
/lib64/libc.so.6(+0x7d776)[0x7f00153a5776]
/root/usr/bin/qemu-system-x86_64(+0x2c34ec)[0x7f001cf5b4ec]
/root/usr/bin/qemu-system-x86_64(+0x342f9a)[0x7f001cfdaf9a]
/root/usr/bin/qemu-system-x86_64(+0x33694e)[0x7f001cfce94e]


  (gdb) bt
  #0  0x7f3bf3a12015 in raise () from /lib64/libc.so.6
  #1  0x7f3bf3a1348b in abort () from /lib64/libc.so.6
  #2  0x7f3bf3a51a4e in __libc_message () from /lib64/libc.so.6
  #3  0x7f3bf3a57776 in malloc_printerr () from /lib64/libc.so.6
  #4  0x7f3bfb60d4ec in free_and_trace (mem=0x7f3bfe0129f8) at vl.c:2786
  #5  0x7f3bfb68cf9a in virtio_cleanup (vdev=0x7f3bfe0129f8) at 
/root/Develop/QEMU/qemu/hw/virtio.c:900
  #6  0x7f3bfb68094e in virtio_blk_device_init (vdev=0x7f3bfe0129f8) at 
/root/Develop/QEMU/qemu/hw/virtio-blk.c:666
  #7  0x7f3bfb68dadf in virtio_device_init (qdev=0x7f3bfe0129f8) at 
/root/Develop/QEMU/qemu/hw/virtio.c:1092
  #8  0x7f3bfb50da46 in device_realize (dev=0x7f3bfe0129f8, 
err=0x7fff479c9258) at hw/qdev.c:176
.

In virtio_blk_device_init(), the memory which vdev point to is a static
member of "struct VirtIOBlkPCI", not heap memory, and it does not
get freed. So we shoule use virtio_common_cleanup() to clean this VirtIODevice
rather than virtio_cleanup(), which attempts to free the vdev.

This error was introduced by commit 05ff686536f408ba6e8426b1b54d25bd3379fda2
recently.

Signed-off-by: Dunrong Huang 

Reviewed-by: KONRAD Frederic 

Oops sorry for that :/

---
  hw/virtio-blk.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index e6f8875..f2143fd 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -663,7 +663,7 @@ static int virtio_blk_device_init(VirtIODevice *vdev)
  s->vq = virtio_add_queue(vdev, 128, virtio_blk_handle_output);
  #ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
  if (!virtio_blk_data_plane_create(vdev, blk, &s->dataplane)) {
-virtio_cleanup(vdev);
+virtio_common_cleanup(vdev);
  return -1;
  }
  #endif

Re: [Qemu-devel] [PATCH] virtio-9p: Fix virtio-9p no longer building after hw-dirs branch merge

[KONRAD Frédéric]

On 09/04/2013 21:13, Anthony Liguori wrote:

Paolo Bonzini  writes:


Il 09/04/2013 10:22, Hans de Goede ha scritto:

Signed-off-by: Hans de Goede 
Cc: Paolo Bonzini 
---
  hw/9pfs/virtio-9p-device.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion

Ouch, /me installs libcap-ng-devel.

On a fresh F18, I tried to find all the deps needed that can be
reasonably installed.  This is what I came up with:

# yum install xen-devel iasl libfdt-devel libcap-ng-devel \
   spice-server-devel gnutls-devel cyrus-sasl-devel libjpeg-turbo-devel \
   libpng-devel uuid-devel xfsprogs-devel ncurses-devel brlapi-devel \
   libcurl-devel bluez-libs-devel libiscsi-devel libcap-ng-devel \
   spice-protocol SDL-devel libcap-devel usbredir-devel libseccomp-devel \
   ceph-devel

Still missing GlusterFS, VDE, and iscsi.  F18 doesn't seem to
package these at appropriate versions.

Regards,

Anthony Liguori

Isn't libattr-devel needed as well for virtio-9p?

I needed it to test my patch-set this morning.



Thanks.

Paolo


diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 43f930e..b476b81 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -12,11 +12,11 @@
   */
  
  #include "hw/virtio/virtio.h"

+#include "hw/virtio/virtio-9p.h"
  #include "hw/i386/pc.h"
  #include "qemu/sockets.h"
  #include "virtio-9p.h"
  #include "fsdev/qemu-fsdev.h"
-#include "virtio-9p-device.h"
  #include "virtio-9p-xattr.h"
  #include "virtio-9p-coth.h"
  

Re: [Qemu-devel] [PATCH] virtio-9p: Fix virtio-9p no longer building after hw-dirs branch merge

[KONRAD Frédéric]

On 09/04/2013 22:57, Anthony Liguori wrote:

KONRAD Frédéric  writes:


On 09/04/2013 21:13, Anthony Liguori wrote:

Paolo Bonzini  writes:


Il 09/04/2013 10:22, Hans de Goede ha scritto:

Signed-off-by: Hans de Goede 
Cc: Paolo Bonzini 
---
   hw/9pfs/virtio-9p-device.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion

Ouch, /me installs libcap-ng-devel.

On a fresh F18, I tried to find all the deps needed that can be
reasonably installed.  This is what I came up with:

# yum install xen-devel iasl libfdt-devel libcap-ng-devel \
spice-server-devel gnutls-devel cyrus-sasl-devel libjpeg-turbo-devel \
libpng-devel uuid-devel xfsprogs-devel ncurses-devel brlapi-devel \
libcurl-devel bluez-libs-devel libiscsi-devel libcap-ng-devel \
spice-protocol SDL-devel libcap-devel usbredir-devel libseccomp-devel \
ceph-devel

Still missing GlusterFS, VDE, and iscsi.  F18 doesn't seem to
package these at appropriate versions.

Regards,

Anthony Liguori

Isn't libattr-devel needed as well for virtio-9p?

I have CONFIG_VIRTFS=y without libattr-devel installed FWIW.

Regards,

Anthony Liguori


True, I just tested.

But when I launch the configure script without libcap-devel installed:

[konradf@localhost qemu]$ ./configure [...] --enable-virtfs

ERROR: VirtFS is supported only on Linux and requires libcap-devel and 
libattr-devel


That's why I installed it :).




I needed it to test my patch-set this morning.

Thanks.

Paolo


diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 43f930e..b476b81 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -12,11 +12,11 @@
*/
   
   #include "hw/virtio/virtio.h"

+#include "hw/virtio/virtio-9p.h"
   #include "hw/i386/pc.h"
   #include "qemu/sockets.h"
   #include "virtio-9p.h"
   #include "fsdev/qemu-fsdev.h"
-#include "virtio-9p-device.h"
   #include "virtio-9p-xattr.h"
   #include "virtio-9p-coth.h"
   

Re: [Qemu-devel] [PATCH] virtio-balloon: fix dynamic properties.

[KONRAD Frédéric]

On 12/04/2013 10:29, Peter Maydell wrote:

On 11 April 2013 23:38,   wrote:

From: KONRAD Frederic 

To keep compatibility with the old virtio-balloon-x, add the dynamic properties
to virtio-balloon-pci and virtio-balloon-ccw.

Does the approach I suggested on IRC where virtio-balloon-pci's
property set/get callbacks just set/get the property on
virtio-balloon via the public interface not work? Having to
expose virtio-balloon's callback functions seems a bit of
an encapsulation violation...

thanks
-- PMM

Oh, I didn't understand that like that.

What do you mean by the public interface?

I thought you wanted two set/get callbacks which call directly 
virtio-balloon callbacks.


Thanks,
Fred

Re: [Qemu-devel] [PATCH] virtio-balloon: fix dynamic properties.

[KONRAD Frédéric]

On 12/04/2013 11:14, Peter Maydell wrote:

On 12 April 2013 09:36, KONRAD Frédéric  wrote:

On 12/04/2013 10:29, Peter Maydell wrote:

Does the approach I suggested on IRC where virtio-balloon-pci's
property set/get callbacks just set/get the property on
virtio-balloon via the public interface not work? Having to
expose virtio-balloon's callback functions seems a bit of
an encapsulation violation...

Oh, I didn't understand that like that.

What do you mean by the public interface?

I mean the interface that any user of an object should
use to access properties, ie object_property_set()
and object_property_get(). Something like:

static void balloon_pci_fwd_get(Object *obj,
  struct Visitor *v, void *opaque, const char *name, Error **errp)
{
 VirtIOBalloonPCI *dev = VIRTIO_BALLOON_PCI(obj);
 object_property_get(OBJECT(&dev->vdev), v, name, errp);
}

Ditto for fwd_set; note that you can use the same accessors
for any property you need to forward to the underlying
virtio-balloon-device. Untested :-)

-- PMM

Ok understood,
will fix that.

Thanks,
Fred

Re: [Qemu-devel] [PATCH] virtio-balloon: fix dynamic properties.

[KONRAD Frédéric]

On 12/04/2013 11:14, Peter Maydell wrote:

On 12 April 2013 09:36, KONRAD Frédéric  wrote:

On 12/04/2013 10:29, Peter Maydell wrote:

Does the approach I suggested on IRC where virtio-balloon-pci's
property set/get callbacks just set/get the property on
virtio-balloon via the public interface not work? Having to
expose virtio-balloon's callback functions seems a bit of
an encapsulation violation...

Oh, I didn't understand that like that.

What do you mean by the public interface?

I mean the interface that any user of an object should
use to access properties, ie object_property_set()
and object_property_get(). Something like:

static void balloon_pci_fwd_get(Object *obj,
  struct Visitor *v, void *opaque, const char *name, Error **errp)
{
 VirtIOBalloonPCI *dev = VIRTIO_BALLOON_PCI(obj);
 object_property_get(OBJECT(&dev->vdev), v, name, errp);
}

Ditto for fwd_set; note that you can use the same accessors
for any property you need to forward to the underlying
virtio-balloon-device. Untested :-)

-- PMM

Note, I'm having a kind of similar issue with virtio-rng:

virtio-rng-pci have actually a child device named "default-backend".

The logic wants that default-backend is a child of virtio-rng-device but 
as we

want to keep compatibility.

And it's not possible to have this default-backend be a child of 
virtio-rng-pci and virtio-rng-device at the same time.

Re: [Qemu-devel] [PATCH v3 5/8] virtio-ccw: cleanup.

[KONRAD Frédéric]

On 15/04/2013 15:38, Cornelia Huck wrote:

On Sun, 14 Apr 2013 23:26:34 +0200
fred.kon...@greensocs.com wrote:


From: KONRAD Frederic 

This is a cleanup for virtio-ccw.
The init function is replaced by the device_plugged callback from
virtio-bus.

Hm, so you replaced a callback that might return an error by another
one that can't...

Yes, I think this is not the right thing to do.

Originally, virtio-device was able to be hot-plugged in virtio-bus, 
that's why I

used this callback.

So two solutions,
* Leave the init function as this.
* Modify the callback prototype (returning the error).

And probably do the same with PCI and S390.

What do you think is the best?

Thanks,
Fred




Signed-off-by: KONRAD Frederic 
---
  hw/s390x/virtio-ccw.c | 34 ++
  1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 5d62606..4857f97 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -392,8 +392,10 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
  return ret;
  }

-static int virtio_ccw_device_init(VirtioCcwDevice *dev, VirtIODevice *vdev)
+/* This is called by virtio-bus just after the device is plugged. */
+static void virtio_ccw_device_plugged(DeviceState *d)
  {
+VirtioCcwDevice *dev = VIRTIO_CCW_DEVICE(d);
  unsigned int cssid = 0;
  unsigned int ssid = 0;
  unsigned int schid;
@@ -401,7 +403,6 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev, 
VirtIODevice *vdev)
  bool have_devno = false;
  bool found = false;
  SubchDev *sch;
-int ret;
  int num;
  DeviceState *parent = DEVICE(dev);

@@ -410,7 +411,7 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev, 
VirtIODevice *vdev)
  sch->driver_data = dev;
  dev->sch = sch;

-dev->vdev = vdev;
+dev->vdev = dev->bus.vdev;
  dev->indicators = 0;

  /* Initialize subchannel structure. */
@@ -425,19 +426,16 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev, 
VirtIODevice *vdev)
  num = sscanf(dev->bus_id, "%x.%x.%04x", &cssid, &ssid, &devno);
  if (num == 3) {
  if ((cssid > MAX_CSSID) || (ssid > MAX_SSID)) {
-ret = -EINVAL;
  error_report("Invalid cssid or ssid: cssid %x, ssid %x",
   cssid, ssid);
  goto out_err;
  }
  /* Enforce use of virtual cssid. */
  if (cssid != VIRTUAL_CSSID) {
-ret = -EINVAL;
  error_report("cssid %x not valid for virtio devices", cssid);
  goto out_err;
  }
  if (css_devno_used(cssid, ssid, devno)) {
-ret = -EEXIST;
  error_report("Device %x.%x.%04x already exists", cssid, ssid,
   devno);
  goto out_err;
@@ -447,7 +445,6 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev, 
VirtIODevice *vdev)
  sch->devno = devno;
  have_devno = true;
  } else {
-ret = -EINVAL;
  error_report("Malformed devno parameter '%s'", dev->bus_id);
  goto out_err;
  }
@@ -464,7 +461,6 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev, 
VirtIODevice *vdev)
  }
  }
  if (!found) {
-ret = -ENODEV;
  error_report("No free subchannel found for %x.%x.%04x", cssid, 
ssid,
   devno);
  goto out_err;
@@ -488,7 +484,6 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev, 
VirtIODevice *vdev)
  if (devno == MAX_SCHID) {
  devno = 0;
  } else if (devno == schid - 1) {
-ret = -ENODEV;
  error_report("No free devno found");
  goto out_err;
  } else {
@@ -506,7 +501,6 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev, 
VirtIODevice *vdev)
  }
  }
  if (!found) {
-ret = -ENODEV;
  error_report("Virtual channel subsystem is full!");
  goto out_err;
  }
@@ -525,20 +519,19 @@ static int virtio_ccw_device_init(VirtioCcwDevice *dev, 
VirtIODevice *vdev)
  sch->id.cu_type = VIRTIO_CCW_CU_TYPE;
  sch->id.cu_model = dev->vdev->device_id;

-virtio_bind_device(vdev, &virtio_ccw_bindings, DEVICE(dev));
  /* Only the first 32 feature bits are used. */
-dev->host_features[0] = vdev->get_features(vdev, dev->host_features[0]);
+dev->host_features[0] = dev->vdev->get_features(dev->vdev,
+dev->host_features[0]);
  dev->host_features[0] |= 0x1 << VIRTIO_F_NOTIFY_ON_EMPTY;
  dev->host_features[0] |= 0x1 << VIRTIO_F_BAD_FEATURE;

  css_generate_sch_crws(sch->cssid, sch->ssid, sch->sch

Re: [Qemu-devel] [PATCH v3 8/8] virtio-rng: cleanup: use QOM casts.

[KONRAD Frédéric]

On 15/04/2013 15:34, Andreas Färber wrote:

Am 14.04.2013 15:01, schrieb fred.kon...@greensocs.com:

From: KONRAD Frederic 

As the virtio-rng-pci and virtio-rng-s390 are switched to the new API,

and virtio-rng-ccw ;)


we can use QOM casts.

Signed-off-by: KONRAD Frederic 
---
  hw/virtio/virtio-rng.c | 31 +--
  include/hw/virtio/virtio-rng.h |  2 +-
  2 files changed, 18 insertions(+), 15 deletions(-)

Thanks,

Reviewed-by: Andreas Färber 

I was surprised to see FOO(opaque) since we usually try to avoid it for
performance reasons, but it's not forbidden either.

True, I had taken that in account but forget this series :/.

Is it better to change that?

Thanks,
Fred

Also, leaving the variable name as "s" would've spared a few lines but
so what. :)

Regards,
Andreas

Re: [Qemu-devel] 'id' assigned to -device could not be set as net-client name (was Re: Nic devices' name are wrongly repeated)

[KONRAD Frédéric]

On 18/04/2013 10:19, Amos Kong wrote:

On Wed, Apr 10, 2013 at 02:28:40PM +0200, Andreas Färber wrote:

Hi,

Am 10.04.2013 14:05, schrieb Amos Kong:

If we don't assign 'id' for nic device, device name will be $model.$idx. The 
$idx are always 0 if we set nic by new style.

# qemu-upstream -device virtio-net-pci,netdev=h1 -netdev tap,id=h1 -device 
virtio-net-pci,netdev=h2 -netdev tap,id=h2 ...
(qemu) info network
virtio-net-pci.0: 
index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
  \ h1: 
index=0,type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
virtio-net-pci.0: 
index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
  \ h2: 
index=0,type=tap,ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown

it's introduced by commit d33d93b2

I can see that's inconvenient, but...


If we set links down by 'set_link virtio-net-pci.0', the first nic
will be set down. But how to set the second link down by id?

As you would do for all devices? I.e., add ,id=youruniqueid to -device.


Hi KONRAD,

  Your following patch just introduced a regression, 'id' assigned to -device
  could not be set as net-client name.


A regression from "net: make nic name unique" ?


qemu -device virtio-net-pci,netdev=ndev1,id=id1 -netdev tap,id=ndev1 \
   -device e1000,netdev=ndev2,id=id2 -netdev tap,id=ndev2

(qemu) info network
virtio-net-device.0: 
index=0,type=nic,model=virtio-net-device,macaddr=52:54:00:12:34:56
  \ ndev1: 
index=0,type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
id2: index=0,type=nic,model=e1000,macaddr=52:54:00:12:34:57
  \ ndev2: 
index=0,type=tap,ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown


yes :/, that seems to be the side effect of cutting virtio-net-pci in

virtio-net-pci + virtio-net-device.

Here virtio-net-device is the network device as you see in info network.

virtio-net-pci isn't anymore.

I wonder how to solve that as we can't duplicate the id.

I will take a look.

Fred



===
commit 1773d9ee6e7138e3956081670215e8bc0ae14828
Author: KONRAD Frederic 
Date:   Thu Apr 11 16:30:02 2013 +0200

 virtio-net: cleanup: init and exit function.
 
 This remove old init and exit function as they are no longer needed.
 
 Signed-off-by: KONRAD Frederic 

 Tested-by: Cornelia Huck 
 Message-id: 1365690602-22729-8-git-send-email-fred.kon...@greensocs.com
 Signed-off-by: Anthony Liguori 

commit 17a0ca55657114c055cb407291c1163e09b29973
Author: KONRAD Frederic 
Date:   Thu Apr 11 16:30:01 2013 +0200

 virtio-net: cleanup: use QOM cast.
 
 As the virtio-net-pci and virtio-net-s390 are switched to the new API,

 we can use QOM casts.
 
 Signed-off-by: KONRAD Frederic 

 Tested-by: Cornelia Huck 
 Message-id: 1365690602-22729-7-git-send-email-fred.kon...@greensocs.com
 Signed-off-by: Anthony Liguori 

commit 89334c8b6baebb1e84cd9bb6e796683e53391769
Author: KONRAD Frederic 
Date:   Thu Apr 11 16:30:00 2013 +0200

 virtio-net-ccw: switch to the new API.
 
 Here the virtio-net-ccw is modified for the new API. The device

 virtio-net-ccw extends virtio-ccw-device as before. It creates and
 connects a virtio-net-device during the init. The properties are not 
modified.
 
 Signed-off-by: KONRAD Frederic 

 Tested-by: Cornelia Huck 
 Message-id: 1365690602-22729-6-git-send-email-fred.kon...@greensocs.com
 Signed-off-by: Anthony Liguori 

commit 74b4fe3d79098b72813e461af565557bb5d35649
Author: KONRAD Frederic 
Date:   Thu Apr 11 16:29:59 2013 +0200

 virtio-net-s390: switch to the new API.
 
 Here the virtio-net-s390 is modified for the new API. The device

 virtio-net-s390 extends virtio-s390-device as before. It creates and
 connects a virtio-net-device during the init. The properties are not 
modified.
 
 Signed-off-by: KONRAD Frederic 

 Tested-by: Cornelia Huck 
 Message-id: 1365690602-22729-5-git-send-email-fred.kon...@greensocs.com
 Signed-off-by: Anthony Liguori 

commit e37da3945fa2fde161e1b217f937fc318c4b7639
Author: KONRAD Frederic 
Date:   Thu Apr 11 16:29:58 2013 +0200

 virtio-net-pci: switch to the new API.
 
 Here the virtio-net-pci is modified for the new API. The device

 virtio-net-pci extends virtio-pci. It creates and connects a
 virtio-net-device during the init. The properties are not changed.
 
 Signed-off-by: KONRAD Frederic 

 Tested-by: Cornelia Huck 
 Message-id: 1365690602-22729-4-git-send-email-fred.kon...@greensocs.com
 Signed-off-by: Anthony Liguori 

commit 17ec5a8686143da66208273d355f2eeb09807614
Author: KONRAD Frederic 
Date:   Thu Apr 11 16:29:57 2013 +0200

 virtio-net: add the virtio-net device.
 
 Create virtio-net-device which extends virtio-device, so it can be connected on

 virtio-bus.
 
 Signed-off-by: KONRAD Frederic 

 Tested-b

Re: [Qemu-devel] 'id' assigned to -device could not be set as net-client name (was Re: Nic devices' name are wrongly repeated)

[KONRAD Frédéric]

On 18/04/2013 11:47, Amos Kong wrote:

On Thu, Apr 18, 2013 at 11:12:56AM +0200, KONRAD Frédéric wrote:

On 18/04/2013 10:19, Amos Kong wrote:

On Wed, Apr 10, 2013 at 02:28:40PM +0200, Andreas Färber wrote:

Hi,

Am 10.04.2013 14:05, schrieb Amos Kong:

If we don't assign 'id' for nic device, device name will be $model.$idx. The 
$idx are always 0 if we set nic by new style.

# qemu-upstream -device virtio-net-pci,netdev=h1 -netdev tap,id=h1 -device 
virtio-net-pci,netdev=h2 -netdev tap,id=h2 ...
(qemu) info network
virtio-net-pci.0: 
index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
  \ h1: 
index=0,type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
virtio-net-pci.0: 
index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
  \ h2: 
index=0,type=tap,ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown

it's introduced by commit d33d93b2

I can see that's inconvenient, but...


If we set links down by 'set_link virtio-net-pci.0', the first nic
will be set down. But how to set the second link down by id?

As you would do for all devices? I.e., add ,id=youruniqueid to -device.

Hi KONRAD,

  Your following patch just introduced a regression, 'id' assigned to -device
  could not be set as net-client name.

A regression from "net: make nic name unique" ?

No, regression caused by commit: e37da3945fa2fde161e1b217f937fc318c4b7639


qemu -device virtio-net-pci,netdev=ndev1,id=id1 -netdev tap,id=ndev1 \
   -device e1000,netdev=ndev2,id=id2 -netdev tap,id=ndev2

(qemu) info network
virtio-net-device.0: 
index=0,type=nic,model=virtio-net-device,macaddr=52:54:00:12:34:56
  \ ndev1: 
index=0,type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
id2: index=0,type=nic,model=e1000,macaddr=52:54:00:12:34:57
  \ ndev2: 
index=0,type=tap,ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown

yes :/, that seems to be the side effect of cutting virtio-net-pci in

virtio-net-pci + virtio-net-device.

Here virtio-net-device is the network device as you see in info network.

virtio-net-pci isn't anymore.

I wonder how to solve that as we can't duplicate the id.

If we don't assign 'id' for -device, the net-client name will be auto
generated (not duplicated).

Before your commit e37da394, user assigned 'id' will be record to
(DeviceState *)dev->id, it will be used in qemu_new_nic().


Yes sure, what I mean, is:

virtio-net-pci actually get the id and is not the nic device anymore.

and virtio-net-pci create the new virtio-net-device which has no id
(so it is autogenerated).

That's why you didn't the id in info network.


I will take a look.

Fred

Re: [Qemu-devel] [PATCH v3 6/7] virtio-net: cleanup: use QOM cast.

[KONRAD Frédéric]

On 18/04/2013 10:41, Michael S. Tsirkin wrote:

On Thu, Apr 11, 2013 at 04:30:01PM +0200, fred.kon...@greensocs.com wrote:

From: KONRAD Frederic 

As the virtio-net-pci and virtio-net-s390 are switched to the new API,
we can use QOM casts.

Signed-off-by: KONRAD Frederic 
---
  hw/net/virtio-net.c| 141 +
  include/hw/virtio/virtio-net.h |   2 +-
  2 files changed, 75 insertions(+), 68 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 988fe03..09890c1 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -65,17 +65,9 @@ static int vq2q(int queue_index)
   * - we could suppress RX interrupt if we were so inclined.
   */
  
-/*

- * Moving to QOM later in this serie.
- */
-static VirtIONet *to_virtio_net(VirtIODevice *vdev)
-{
-return (VirtIONet *)vdev;
-}
-
  static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config)
  {
-VirtIONet *n = to_virtio_net(vdev);
+VirtIONet *n = VIRTIO_NET(vdev);
  struct virtio_net_config netcfg;
  
  stw_p(&netcfg.status, n->status);

@@ -86,12 +78,12 @@ static void virtio_net_get_config(VirtIODevice *vdev, 
uint8_t *config)
  
  static void virtio_net_set_config(VirtIODevice *vdev, const uint8_t *config)

  {
-VirtIONet *n = to_virtio_net(vdev);
+VirtIONet *n = VIRTIO_NET(vdev);
  struct virtio_net_config netcfg = {};
  
  memcpy(&netcfg, config, n->config_size);
  
-if (!(n->vdev.guest_features >> VIRTIO_NET_F_CTRL_MAC_ADDR & 1) &&

+if (!(vdev->guest_features >> VIRTIO_NET_F_CTRL_MAC_ADDR & 1) &&
  memcmp(netcfg.mac, n->mac, ETH_ALEN)) {
  memcpy(n->mac, netcfg.mac, ETH_ALEN);
  qemu_format_nic_info_str(qemu_get_queue(n->nic), n->mac);
@@ -100,12 +92,14 @@ static void virtio_net_set_config(VirtIODevice *vdev, 
const uint8_t *config)
  
  static bool virtio_net_started(VirtIONet *n, uint8_t status)

  {
+VirtIODevice *vdev = VIRTIO_DEVICE(n);
  return (status & VIRTIO_CONFIG_S_DRIVER_OK) &&
-(n->status & VIRTIO_NET_S_LINK_UP) && n->vdev.vm_running;
+(n->status & VIRTIO_NET_S_LINK_UP) && vdev->vm_running;
  }
  
  static void virtio_net_vhost_status(VirtIONet *n, uint8_t status)

  {
+VirtIODevice *vdev = VIRTIO_DEVICE(n);
  NetClientState *nc = qemu_get_queue(n->nic);
  int queues = n->multiqueue ? n->max_queues : 1;
  
@@ -126,25 +120,25 @@ static void virtio_net_vhost_status(VirtIONet *n, uint8_t status)

  }
  if (!n->vhost_started) {
  int r;
-if (!vhost_net_query(tap_get_vhost_net(nc->peer), &n->vdev)) {
+if (!vhost_net_query(tap_get_vhost_net(nc->peer), vdev)) {
  return;
  }
  n->vhost_started = 1;
-r = vhost_net_start(&n->vdev, n->nic->ncs, queues);
+r = vhost_net_start(vdev, n->nic->ncs, queues);
  if (r < 0) {
  error_report("unable to start vhost net: %d: "
   "falling back on userspace virtio", -r);
  n->vhost_started = 0;
  }
  } else {
-vhost_net_stop(&n->vdev, n->nic->ncs, queues);
+vhost_net_stop(vdev, n->nic->ncs, queues);
  n->vhost_started = 0;
  }
  }
  
  static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t status)

  {
-VirtIONet *n = to_virtio_net(vdev);
+VirtIONet *n = VIRTIO_NET(vdev);
  VirtIONetQueue *q;
  int i;
  uint8_t queue_status;
@@ -184,6 +178,7 @@ static void virtio_net_set_status(struct VirtIODevice 
*vdev, uint8_t status)
  static void virtio_net_set_link_status(NetClientState *nc)
  {
  VirtIONet *n = qemu_get_nic_opaque(nc);
+VirtIODevice *vdev = VIRTIO_DEVICE(n);
  uint16_t old_status = n->status;
  
  if (nc->link_down)

@@ -192,14 +187,14 @@ static void virtio_net_set_link_status(NetClientState *nc)
  n->status |= VIRTIO_NET_S_LINK_UP;
  
  if (n->status != old_status)

-virtio_notify_config(&n->vdev);
+virtio_notify_config(vdev);
  
-virtio_net_set_status(&n->vdev, n->vdev.status);

+virtio_net_set_status(vdev, vdev->status);
  }
  
  static void virtio_net_reset(VirtIODevice *vdev)

  {
-VirtIONet *n = to_virtio_net(vdev);
+VirtIONet *n = VIRTIO_NET(vdev);
  
  /* Reset back to compatibility mode */

  n->promisc = 1;
@@ -318,7 +313,7 @@ static void virtio_net_set_multiqueue(VirtIONet *n, int 
multiqueue, int ctrl);
  
  static uint32_t virtio_net_get_features(VirtIODevice *vdev, uint32_t features)

  {
-VirtIONet *n = to_virtio_net(vdev);
+VirtIONet *n = VIRTIO_NET(vdev);
  NetClientState *nc = qemu_get_queue(n->nic);
  
  features |= (1 << VIRTIO_NET_F_MAC);

@@ -366,7 +361,7 @@ static uint32_t virtio_net_bad_features(VirtIODevice *vdev)
  
  static void virtio_net_set_features(VirtIODevice *vdev, uint32_t features)

  {
-VirtIONet *n = to_virtio_net(vdev);
+VirtIONet *n = VIRTIO_NET(vdev);
  int i;
  
  virtio_net_set_multiqueue

Re: [Qemu-devel] [PATCH] qdev: Fix device_add bus assumptions

[KONRAD Frédéric]

On 22/04/2013 15:27, Andreas Färber wrote:

Hi,

Am 22.04.2013 13:51, schrieb Libaiqing:

   When I use the config below,an error occurs.Is there anything wrong?

   Qemu-kvm -enable-kvm -name win7 -M pc-0.15 -m 1024 -smp 2 -boot c  -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -chardev 
spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
  -drive file=/home/img/win7.qed,if=virtio,index=0,format=qed  -monitor stdio   
-vga qxl  -vnc :1

Error output:
 -device 
virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0:
 Bus 'virtio-serial0.0' is full
 -device 
virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0:
 Bus 'virtio-serial0.0' not found

Any feedback are appliciated.

This does not sound related to this patch at all...

Instead it sounds as if the virtio refactorings had some effect not only
on virtio-net but also on virtio-serial. Fred?

Andreas

Hi,

Yes, sounds like the same issue as virtio-net:

bus: pci.0
  type PCI
  dev: virtio-serial-pci, id "virtio-serial0"
ioeventfd = off
vectors = 2
class = 0x780
indirect_desc = on
event_idx = on
max_ports = 31
addr = 04.0
romfile = 
rombar = 1
multifunction = off
command_serr_enable = on
class Class 0780, addr 00:04.0, pci id 1af4:1003 (sub 1af4:0003)
bar 0: i/o at 0xc040 [0xc05f]
bar 1: mem at 0xfebf1000 [0xfebf1fff]
bus: virtio-serial0.0
  type virtio-pci-bus
  dev: virtio-serial-device, id ""
max_ports = 31
bus: virtio-serial-bus.0
  type virtio-serial-bus

The autogenerated bus name "deviceid.n" (virtio-serial0.0) became a 
virtio-bus...


virtio-serial-bus.0 is the right bus to connect virtserialport.

Any idea how to fix that?

Sorry for that,
Fred




-Original Message-
From: qemu-devel-bounces+libaiqing=huawei@nongnu.org 
[mailto:qemu-devel-bounces+libaiqing=huawei@nongnu.org] On Behalf Of Igor 
Mammedov
Sent: Thursday, April 18, 2013 5:02 PM
To: Igor Mammedov
Cc: ehabk...@redhat.com; qemu-devel@nongnu.org; arm...@redhat.com; 
anth...@codemonkey.ws; pbonz...@redhat.com; lcapitul...@redhat.com; Andreas 
Färber
Subject: Re: [Qemu-devel] [PATCH] qdev: Fix device_add bus assumptions

On Thu, 18 Apr 2013 10:41:56 +0200
Igor Mammedov  wrote:

[...]

-if (!bus) {
-bus = sysbus_get_default();
-}
-

I've checked all direct childs of TYPE_DEVICE and they all set k->bus_type,
with only one exception of TYPE_CPU. So it should be safe to remove fallback
from qdev_device_add POV.
However  TYPE_CPU breaks assumption that device always has parent_bus set
to not NULL in qdev_unplug() and qdev_print()

Err, qdev_print() is safe since it's called on bus children only, so it has
parent_bus.


It would be better to add something like this:
// untested

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 4eb0134..45009ba 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -207,7 +207,7 @@ void qdev_unplug(DeviceState *dev, Error **errp)
  {
  DeviceClass *dc = DEVICE_GET_CLASS(dev);
  
-if (!dev->parent_bus->allow_hotplug) {

+if (dev->parent_bus && !dev->parent_bus->allow_hotplug) {
  error_set(errp, QERR_BUS_NO_HOTPLUG, dev->parent_bus->name);
  return;
  }
diff --git a/qdev-monitor.c b/qdev-monitor.c
index 9a78ccf..2476e4e 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -557,7 +557,9 @@ static void qdev_print(Monitor *mon, DeviceState *dev,
int indent) qdev_print_props(mon, dev, DEVICE_CLASS(class)->props, indent);
  class = object_class_get_parent(class);
  } while (class != object_class_by_name(TYPE_DEVICE));
-bus_print_dev(dev->parent_bus, mon, dev, indent);
+if (dev->parent_bus) {
+bus_print_dev(dev->parent_bus, mon, dev, indent);
+}
  QLIST_FOREACH(child, &dev->child_bus, sibling) {
  qbus_print(mon, child, indent);
  }


  /* create device, set properties */
  qdev = DEVICE(object_new(driver));
-qdev_set_parent_bus(qdev, bus);
+
+if (bus) {
+qdev_set_parent_bus(qdev, bus);
+}
  
  id = qemu_opts_id(opts);

  if (id) {

Re: [Qemu-devel] [PATCH] qdev: Fix device_add bus assumptions

[KONRAD Frédéric]

On 22/04/2013 16:02, Andreas Färber wrote:

Hi Fred,

Am 22.04.2013 15:54, schrieb KONRAD Frédéric:

On 22/04/2013 15:27, Andreas Färber wrote:

Am 22.04.2013 13:51, schrieb Libaiqing:

When I use the config below,an error occurs.Is there anything wrong?

Qemu-kvm -enable-kvm -name win7 -M pc-0.15 -m 1024 -smp 2 -boot c
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4
-chardev spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
-drive file=/home/img/win7.qed,if=virtio,index=0,format=qed  -monitor
stdio   -vga qxl  -vnc :1

Error output:
  -device
virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0:
Bus 'virtio-serial0.0' is full
  -device
virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0:
Bus 'virtio-serial0.0' not found

Any feedback are appliciated.

This does not sound related to this patch at all...

Instead it sounds as if the virtio refactorings had some effect not only
on virtio-net but also on virtio-serial. Fred?

Yes, sounds like the same issue as virtio-net:

 bus: pci.0
   type PCI
   dev: virtio-serial-pci, id "virtio-serial0"
 ioeventfd = off
 vectors = 2
 class = 0x780
 indirect_desc = on
 event_idx = on
 max_ports = 31
 addr = 04.0
 romfile = 
 rombar = 1
 multifunction = off
 command_serr_enable = on
 class Class 0780, addr 00:04.0, pci id 1af4:1003 (sub 1af4:0003)
 bar 0: i/o at 0xc040 [0xc05f]
 bar 1: mem at 0xfebf1000 [0xfebf1fff]
 bus: virtio-serial0.0
   type virtio-pci-bus
   dev: virtio-serial-device, id ""
 max_ports = 31
 bus: virtio-serial-bus.0
   type virtio-serial-bus

The autogenerated bus name "deviceid.n" (virtio-serial0.0) became a
virtio-bus...

virtio-serial-bus.0 is the right bus to connect virtserialport.

Any idea how to fix that?

The only idea I can come up with right now is to overwrite the bus name
on realize/qdev-init of the containing (virtio-serial-pci) device.

Whether we want that is another question... :) It would fix command line
backwards compatibility but would be inconsistent then; I guess the
former is more important here.

Regards,
Andreas

I'm not sure that only overwriting the bus name will fix the issue.

virtio-serial-device's bus still won't have the right name?

Here with the command line, we expect virtio-serial-pci,id=id0 to create 
a virtio-serial-bus called id0.0 is that right?


Thanks,
Fred




Sorry for that,
Fred


-Original Message-
From: qemu-devel-bounces+libaiqing=huawei@nongnu.org
[mailto:qemu-devel-bounces+libaiqing=huawei@nongnu.org] On Behalf
Of Igor Mammedov
Sent: Thursday, April 18, 2013 5:02 PM
To: Igor Mammedov
Cc: ehabk...@redhat.com; qemu-devel@nongnu.org; arm...@redhat.com;
anth...@codemonkey.ws; pbonz...@redhat.com; lcapitul...@redhat.com;
Andreas Färber
Subject: Re: [Qemu-devel] [PATCH] qdev: Fix device_add bus assumptions

On Thu, 18 Apr 2013 10:41:56 +0200
Igor Mammedov  wrote:

[...]

-if (!bus) {
-bus = sysbus_get_default();
-}
-

I've checked all direct childs of TYPE_DEVICE and they all set
k->bus_type,
with only one exception of TYPE_CPU. So it should be safe to remove
fallback
from qdev_device_add POV.
However  TYPE_CPU breaks assumption that device always has
parent_bus set
to not NULL in qdev_unplug() and qdev_print()

Err, qdev_print() is safe since it's called on bus children only, so
it has
parent_bus.


It would be better to add something like this:
// untested

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 4eb0134..45009ba 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -207,7 +207,7 @@ void qdev_unplug(DeviceState *dev, Error **errp)
   {
   DeviceClass *dc = DEVICE_GET_CLASS(dev);
   -if (!dev->parent_bus->allow_hotplug) {
+if (dev->parent_bus && !dev->parent_bus->allow_hotplug) {
   error_set(errp, QERR_BUS_NO_HOTPLUG, dev->parent_bus->name);
   return;
   }
diff --git a/qdev-monitor.c b/qdev-monitor.c
index 9a78ccf..2476e4e 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -557,7 +557,9 @@ static void qdev_print(Monitor *mon, DeviceState
*dev,
int indent) qdev_print_props(mon, dev, DEVICE_CLASS(class)->props,
indent);
   class = object_class_get_parent(class);
   } while (class != object_class_by_name(TYPE_DEVICE));
-bus_print_dev(dev->parent_bus, mon, dev, indent);
+if (dev->parent_bus) {
+bus_print_dev(dev->parent_bus, mon, dev, indent);
+}
   QLIST_FOREACH(child, &dev->child_bus, sibling) {
   qbus_print(mon, child, indent);
   }


   /* create device, set properties */

Re: [Qemu-devel] [PATCH] qdev: Fix device_add bus assumptions

[KONRAD Frédéric]

On 22/04/2013 16:22, Andreas Färber wrote:

Am 22.04.2013 16:15, schrieb KONRAD Frédéric:

On 22/04/2013 16:02, Andreas Färber wrote:

Hi Fred,

Am 22.04.2013 15:54, schrieb KONRAD Frédéric:

On 22/04/2013 15:27, Andreas Färber wrote:

Am 22.04.2013 13:51, schrieb Libaiqing:

 When I use the config below,an error occurs.Is there anything
wrong?

 Qemu-kvm -enable-kvm -name win7 -M pc-0.15 -m 1024 -smp 2 -boot c
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4
-chardev spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0

-drive file=/home/img/win7.qed,if=virtio,index=0,format=qed  -monitor
stdio   -vga qxl  -vnc :1

Error output:
   -device
virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0:

Bus 'virtio-serial0.0' is full
   -device
virtserialport,bus=virtio-serial0.0,chardev=charchannel0,id=channel0,name=com.redhat.spice.0:

Bus 'virtio-serial0.0' not found

Any feedback are appliciated.

This does not sound related to this patch at all...

Instead it sounds as if the virtio refactorings had some effect not
only
on virtio-net but also on virtio-serial. Fred?

Yes, sounds like the same issue as virtio-net:

  bus: pci.0
type PCI
dev: virtio-serial-pci, id "virtio-serial0"
  ioeventfd = off
  vectors = 2
  class = 0x780
  indirect_desc = on
  event_idx = on
  max_ports = 31
  addr = 04.0
  romfile = 
  rombar = 1
  multifunction = off
  command_serr_enable = on
  class Class 0780, addr 00:04.0, pci id 1af4:1003 (sub
1af4:0003)
  bar 0: i/o at 0xc040 [0xc05f]
  bar 1: mem at 0xfebf1000 [0xfebf1fff]
  bus: virtio-serial0.0
type virtio-pci-bus
dev: virtio-serial-device, id ""
  max_ports = 31
  bus: virtio-serial-bus.0
type virtio-serial-bus

The autogenerated bus name "deviceid.n" (virtio-serial0.0) became a
virtio-bus...

virtio-serial-bus.0 is the right bus to connect virtserialport.

Any idea how to fix that?

The only idea I can come up with right now is to overwrite the bus name
on realize/qdev-init of the containing (virtio-serial-pci) device.

Whether we want that is another question... :) It would fix command line
backwards compatibility but would be inconsistent then; I guess the
former is more important here.

Regards,
Andreas

I'm not sure that only overwriting the bus name will fix the issue.

virtio-serial-device's bus still won't have the right name?

I was talking of virtio-serial-pci overwriting virtio-serial-device's
bus with its own id.0 after it's been created by virtio-serial-device
with NULL argument! Assuming it gets created in instance_init and can't
just access its parent's id in its own realize function to have it
correct from the start.

Andreas


Ok, I'll take a look.

Thanks for help :),
Fred



Here with the command line, we expect virtio-serial-pci,id=id0 to create
a virtio-serial-bus called id0.0 is that right?

Thanks,
Fred

Re: [Qemu-devel] Virtioserial changed behavior after f7f7464afdb9f

[KONRAD Frédéric]

On 25/04/2013 16:41, Michal Privoznik wrote:

I've noticed some strange behavior after the commit from $subj:

$ qemu-system-x86_64 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 \
-device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
qemu-system-x86_64: -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0:
 Bus 'virtio-serial0.0' is full
qemu-system-x86_64: -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0:
 Bus 'virtio-serial0.0' not found


qemu.git $ ./x86_64-softmmu/qemu-system-x86_64 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 \
-device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
 \
-chardev socket,id=charchannel0,path=/tmp/agent.sock,server,nowait

while before this commit it works just fine. Am I missing something (e.g. cmd 
line has changed)?

Michal


Yes, it's a bug, I need to fix that.

Fred

Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

[KONRAD Frédéric]

On 29/04/2013 16:42, Jesse Larrew wrote:

On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:

On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:

Commit 14f9b664 (hw/virtio-net.c: set config size using host features) tries to
calculate config size based on the host features. But it forgets the
VIRTIO_NET_F_MAC were always set for qemu later. This will lead a zero config
len for virtio-net device when both VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ were
disabled form command line. Then qemu will crash when user tries to read the
config of virtio-net.

Fix this by counting VIRTIO_NET_F_MAC and make sure the config at least contains
the mac address.

Cc: Jesse Larrew 
Signed-off-by: Jason Wang 
---
  hw/net/virtio-net.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 70c8fce..33a70ef 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1264,7 +1264,8 @@ static void virtio_net_guest_notifier_mask(VirtIODevice 
*vdev, int idx,
  
  void virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)

  {
-int i, config_size = 0;
+/* VIRTIO_NET_F_MAC can't be disabled from qemu side */
+int i, config_size = feature_sizes[0].end;

This would be cleaner:
host_features |= (1 << VIRTIO_NET_F_MAC);

no need for a comment then.


It seems to me that the real problem here is that host_features isn't
properly populated before virtio_net_set_config_size() is called. Looking
at virtio_device_init(), we can see why:

static int virtio_device_init(DeviceState *qdev)
{
 VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
 VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
 assert(k->init != NULL);
 if (k->init(vdev) < 0) {
 return -1;
 }
 virtio_bus_plug_device(vdev);
 return 0;
}

virtio_net_set_config_size() is currently being called as part of the
k->init call, but the host_features aren't properly setup until the device
is plugged into the bus using virtio_bus_plug_device().

After talking with mdroth, I think the proper way to fix this would be to
extend VirtioDeviceClass to include a calculate_config_size() method that
can be called at the appropriate time during device initialization like so:

static int virtio_device_init(DeviceState *qdev)
{
 VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
 VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
 assert(k->init != NULL);
 if (k->init(vdev) < 0) {
 return -1;
 }
 virtio_bus_plug_device(vdev);
+   if (k->calculate_config_size && k->calculate_config_size(vdev) < 0) {
+   return -1;
+   }
 return 0;
}

This would ensure that host_features contains the proper data before any
devices try to make use of it to calculate the config size.

Good point, I didn't saw that.

but this was not the case with commit 14f9b664 no?




  for (i = 0; feature_sizes[i].flags != 0; i++) {
  if (host_features & feature_sizes[i].flags) {
  config_size = MAX(feature_sizes[i].end, config_size);
--
1.7.1

Jesse Larrew
Software Engineer, KVM Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlar...@linux.vnet.ibm.com

Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

[KONRAD Frédéric]

On 29/04/2013 17:14, Jesse Larrew wrote:

On 04/29/2013 09:55 AM, KONRAD Frédéric wrote:

On 29/04/2013 16:42, Jesse Larrew wrote:

On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:

On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:

Commit 14f9b664 (hw/virtio-net.c: set config size using host features) tries to
calculate config size based on the host features. But it forgets the
VIRTIO_NET_F_MAC were always set for qemu later. This will lead a zero config
len for virtio-net device when both VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ were
disabled form command line. Then qemu will crash when user tries to read the
config of virtio-net.

Fix this by counting VIRTIO_NET_F_MAC and make sure the config at least contains
the mac address.

Cc: Jesse Larrew 
Signed-off-by: Jason Wang 
---
   hw/net/virtio-net.c |3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 70c8fce..33a70ef 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1264,7 +1264,8 @@ static void virtio_net_guest_notifier_mask(VirtIODevice 
*vdev, int idx,
 void virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)
   {
-int i, config_size = 0;
+/* VIRTIO_NET_F_MAC can't be disabled from qemu side */
+int i, config_size = feature_sizes[0].end;

This would be cleaner:
 host_features |= (1 << VIRTIO_NET_F_MAC);

no need for a comment then.


It seems to me that the real problem here is that host_features isn't
properly populated before virtio_net_set_config_size() is called. Looking
at virtio_device_init(), we can see why:

static int virtio_device_init(DeviceState *qdev)
{
  VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
  VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
  assert(k->init != NULL);
  if (k->init(vdev) < 0) {
  return -1;
  }
  virtio_bus_plug_device(vdev);
  return 0;
}

virtio_net_set_config_size() is currently being called as part of the
k->init call, but the host_features aren't properly setup until the device
is plugged into the bus using virtio_bus_plug_device().

After talking with mdroth, I think the proper way to fix this would be to
extend VirtioDeviceClass to include a calculate_config_size() method that
can be called at the appropriate time during device initialization like so:

static int virtio_device_init(DeviceState *qdev)
{
  VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
  VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
  assert(k->init != NULL);
  if (k->init(vdev) < 0) {
  return -1;
  }
  virtio_bus_plug_device(vdev);
+   if (k->calculate_config_size && k->calculate_config_size(vdev) < 0) {
+   return -1;
+   }
  return 0;
}

This would ensure that host_features contains the proper data before any
devices try to make use of it to calculate the config size.

Good point, I didn't saw that.

but this was not the case with commit 14f9b664 no?


I suspect this bug was present in 14f9b664 as well. We just hadn't triggered
it yet. I'll confirm this afternoon.


Ok, I think there is a problem with your patch:

virtio_init(VIRTIO_DEVICE(n), "virtio-net", VIRTIO_ID_NET,
  n->config_size);

is called in virtio_net_device_init (k->init).

Is there a way to resize the config after that?




   for (i = 0; feature_sizes[i].flags != 0; i++) {
   if (host_features & feature_sizes[i].flags) {
   config_size = MAX(feature_sizes[i].end, config_size);
--
1.7.1

Jesse Larrew
Software Engineer, KVM Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlar...@linux.vnet.ibm.com

Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

[KONRAD Frédéric]

On 29/04/2013 18:02, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 10:55:36AM -0500, Jesse Larrew wrote:

On 04/29/2013 10:29 AM, KONRAD Frédéric wrote:

On 29/04/2013 17:14, Jesse Larrew wrote:

On 04/29/2013 09:55 AM, KONRAD Frédéric wrote:

On 29/04/2013 16:42, Jesse Larrew wrote:

On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:

On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:

Commit 14f9b664 (hw/virtio-net.c: set config size using host features) tries to
calculate config size based on the host features. But it forgets the
VIRTIO_NET_F_MAC were always set for qemu later. This will lead a zero config
len for virtio-net device when both VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ were
disabled form command line. Then qemu will crash when user tries to read the
config of virtio-net.

Fix this by counting VIRTIO_NET_F_MAC and make sure the config at least contains
the mac address.

Cc: Jesse Larrew 
Signed-off-by: Jason Wang 
---
hw/net/virtio-net.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 70c8fce..33a70ef 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1264,7 +1264,8 @@ static void virtio_net_guest_notifier_mask(VirtIODevice 
*vdev, int idx,
  void virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)
{
-int i, config_size = 0;
+/* VIRTIO_NET_F_MAC can't be disabled from qemu side */
+int i, config_size = feature_sizes[0].end;

This would be cleaner:
  host_features |= (1 << VIRTIO_NET_F_MAC);

no need for a comment then.


It seems to me that the real problem here is that host_features isn't
properly populated before virtio_net_set_config_size() is called. Looking
at virtio_device_init(), we can see why:

static int virtio_device_init(DeviceState *qdev)
{
   VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
   VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
   assert(k->init != NULL);
   if (k->init(vdev) < 0) {
   return -1;
   }
   virtio_bus_plug_device(vdev);
   return 0;
}

virtio_net_set_config_size() is currently being called as part of the
k->init call, but the host_features aren't properly setup until the device
is plugged into the bus using virtio_bus_plug_device().

After talking with mdroth, I think the proper way to fix this would be to
extend VirtioDeviceClass to include a calculate_config_size() method that
can be called at the appropriate time during device initialization like so:

static int virtio_device_init(DeviceState *qdev)
{
   VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
   VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
   assert(k->init != NULL);
   if (k->init(vdev) < 0) {
   return -1;
   }
   virtio_bus_plug_device(vdev);
+   if (k->calculate_config_size && k->calculate_config_size(vdev) < 0) {
+   return -1;
+   }
   return 0;
}

This would ensure that host_features contains the proper data before any
devices try to make use of it to calculate the config size.

Good point, I didn't saw that.

but this was not the case with commit 14f9b664 no?


I suspect this bug was present in 14f9b664 as well. We just hadn't triggered
it yet. I'll confirm this afternoon.

Ok, I think there is a problem with your patch:

 virtio_init(VIRTIO_DEVICE(n), "virtio-net", VIRTIO_ID_NET,
   n->config_size);

is called in virtio_net_device_init (k->init).

Is there a way to resize the config after that?


Nope. That's definitely a bug. I can send a patch to fix this today. Any
objection to the method suggested above (extending VirtioDeviceClass)?

This needs more thought. All devices expected everything
is setup during the init call. config size is
likely not the only issue.

So we need almost all of virtio_bus_plug_device before init,
and then after init send the signal:

 if (klass->device_plugged != NULL) {
 klass->device_plugged(qbus->parent);
 }


Seems the interesting part is in virtio_pci_device_plugged at the end:

proxy->host_features |= 0x1 << VIRTIO_F_NOTIFY_ON_EMPTY;
proxy->host_features |= 0x1 << VIRTIO_F_BAD_FEATURE;
proxy->host_features = virtio_bus_get_vdev_features(bus,
proxy->host_features);

This is and was called after set_config_size, isn't that the issue?





for (i = 0; feature_sizes[i].flags != 0; i++) {
if (host_features & feature_sizes[i].flags) {
config_size = MAX(feature_sizes[i].end, config_size);
--
1.7.1

Jesse Larrew
Software Engineer, KVM Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlar...@linux.vnet.ibm.com



--

Jesse Larrew
Software Engineer, KVM Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlar...@linux.vnet.ibm.com

Re: [Qemu-devel] [PATCH for-1.5 3/4] scsi: add scsi_named_bus_new().

[KONRAD Frédéric]

On 29/04/2013 17:40, Paolo Bonzini wrote:

Il 29/04/2013 17:12, fred.kon...@greensocs.com ha scritto:

From: KONRAD Frederic 

This add the possibility to create a scsi-bus with a specified name.

Signed-off-by: KONRAD Frederic 
---
  hw/scsi/scsi-bus.c | 12 +---
  include/hw/scsi/scsi.h |  2 ++
  2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index 6239ee1..0364749 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -71,15 +71,21 @@ static void scsi_device_unit_attention_reported(SCSIDevice 
*s)
  }
  }
  
-/* Create a scsi bus, and attach devices to it.  */

-void scsi_bus_new(SCSIBus *bus, DeviceState *host, const SCSIBusInfo *info)
+void scsi_named_bus_new(SCSIBus *bus, DeviceState *host,
+const SCSIBusInfo *info, const char *bus_name)
  {
-qbus_create_inplace(&bus->qbus, TYPE_SCSI_BUS, host, NULL);
+qbus_create_inplace(&bus->qbus, TYPE_SCSI_BUS, host, bus_name);
  bus->busnr = next_scsi_bus++;
  bus->info = info;
  bus->qbus.allow_hotplug = 1;
  }

I'd prefer that you just add the argument to scsi_bus_new and change all
callers.

Paolo


Ok, will do.


+/* Create a scsi bus, and attach devices to it.  */
+void scsi_bus_new(SCSIBus *bus, DeviceState *host, const SCSIBusInfo *info)
+{
+scsi_named_bus_new(bus, host, info, NULL);
+}
+
  static void scsi_dma_restart_bh(void *opaque)
  {
  SCSIDevice *s = opaque;
diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h
index 3bda1c4..ddcb07c 100644
--- a/include/hw/scsi/scsi.h
+++ b/include/hw/scsi/scsi.h
@@ -153,6 +153,8 @@ struct SCSIBus {
  };
  
  void scsi_bus_new(SCSIBus *bus, DeviceState *host, const SCSIBusInfo *info);

+void scsi_named_bus_new(SCSIBus *bus, DeviceState *host,
+const SCSIBusInfo *info, const char *bus_name);
  
  static inline SCSIBus *scsi_bus_from_device(SCSIDevice *d)

  {

Re: [Qemu-devel] [PATCH for-1.5 4/4] virtio-scsi: fix the command line compatibility.

[KONRAD Frédéric]

On 29/04/2013 17:44, Paolo Bonzini wrote:

Il 29/04/2013 17:12, fred.kon...@greensocs.com ha scritto:

From: KONRAD Frederic 

The bus name is wrong since the refactoring.

This keep the behaviour of the command line.

Signed-off-by: KONRAD Frederic 
---
  hw/s390x/s390-virtio-bus.c  |  9 +
  hw/s390x/virtio-ccw.c   |  9 +
  hw/scsi/virtio-scsi.c   | 14 +-
  hw/virtio/virtio-pci.c  |  9 +
  include/hw/virtio/virtio-scsi.h |  7 +++
  5 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
index 6620d29..e1fd937 100644
--- a/hw/s390x/s390-virtio-bus.c
+++ b/hw/s390x/s390-virtio-bus.c
@@ -232,6 +232,15 @@ static int s390_virtio_scsi_init(VirtIOS390Device 
*s390_dev)
  {
  VirtIOSCSIS390 *dev = VIRTIO_SCSI_S390(s390_dev);
  DeviceState *vdev = DEVICE(&dev->vdev);
+DeviceState *qdev = DEVICE(s390_dev);
+
+/*
+ * For command line compatibility, this set the virtio-scsi-device bus
+ * name as before.
+ */
+if (qdev->id) {
+set_virtio_scsi_bus_name(vdev, qdev->id);
+}

Could this be simply a qdev property?


Yes, that can be a good idea.

What about adding a qdev property bus_name and using it in qbus_realize?

Like this:

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 4eb0134..c5d5407 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -421,6 +421,13 @@ static void qbus_realize(BusState *bus, DeviceState 
*parent, const char *name)


 if (name) {
 bus->name = g_strdup(name);
+} else if (bus->parent && bus->parent->bus_name) {
+/* parent device has bus_name -> use it for bus name */
+len = strlen(bus->parent->bus_name) + 16;
+buf = g_malloc(len);
+snprintf(buf, len, "%s.%d", bus->parent->bus_name,
+ bus->parent->num_child_bus);
+bus->name = buf;
 } else if (bus->parent && bus->parent->id) {
 /* parent device has id -> use it for bus name */
 len = strlen(bus->parent->id) + 16;

If so, change to scsi_bus_new is not needed and the two new functions are
not needed.

Is that making sense?

Fred

Consider that qdev will strdup any bus name you pass, so it is perfectly
ok to do:

bus_name = g_strdup_printf("%s.0", vs->bus_name);
scsi_bus_new(..., bus_name);
g_free(bus_name);


+void set_virtio_scsi_bus_name(DeviceState *dev, const char *bus_name)
+{
+VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(dev);
+if (bus_name) {
+vs->bus_name = g_malloc(strlen(bus_name) + 3);
+snprintf(vs->bus_name, strlen(bus_name) + 3, "%s.0", bus_name);

This would use g_strdup_printf, as above.

Paolo


+}
+}
+
  int virtio_scsi_common_init(VirtIOSCSICommon *s)
  {
  VirtIODevice *vdev = VIRTIO_DEVICE(s);
@@ -624,7 +633,7 @@ static int virtio_scsi_device_init(VirtIODevice *vdev)
  return ret;
  }
  
-scsi_bus_new(&s->bus, qdev, &virtio_scsi_scsi_info);

+scsi_named_bus_new(&s->bus, qdev, &virtio_scsi_scsi_info, vs->bus_name);
  if (!qdev->hotplugged) {
  scsi_bus_legacy_handle_cmdline(&s->bus);
  }
@@ -639,6 +648,9 @@ int virtio_scsi_common_exit(VirtIOSCSICommon *vs)
  {
  VirtIODevice *vdev = VIRTIO_DEVICE(vs);
  
+if (vs->bus_name) {

+g_free(vs->bus_name);
+}
  g_free(vs->cmd_vqs);
  virtio_cleanup(vdev);
  return 0;
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 598876f..14fb8dd 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1106,11 +1106,20 @@ static int virtio_scsi_pci_init_pci(VirtIOPCIProxy 
*vpci_dev)
  VirtIOSCSIPCI *dev = VIRTIO_SCSI_PCI(vpci_dev);
  DeviceState *vdev = DEVICE(&dev->vdev);
  VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
+DeviceState *proxy = DEVICE(vpci_dev);
  
  if (vpci_dev->nvectors == DEV_NVECTORS_UNSPECIFIED) {

  vpci_dev->nvectors = vs->conf.num_queues + 3;
  }
  
+/*

+ * For command line compatibility, this set the virtio-scsi-device bus
+ * name as before.
+ */
+if (proxy->id) {
+set_virtio_scsi_bus_name(vdev, proxy->id);
+}
+
  qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
  if (qdev_init(vdev) < 0) {
  return -1;
diff --git a/include/hw/virtio/virtio-scsi.h b/include/hw/virtio/virtio-scsi.h
index 4db346b..c356d54 100644
--- a/include/hw/virtio/virtio-scsi.h
+++ b/include/hw/virtio/virtio-scsi.h
@@ -164,6 +164,9 @@ typedef struct VirtIOSCSICommon {
  VirtQueue *ctrl_vq;
  VirtQueue *event_vq;
  VirtQueue **cmd_vqs;
+
+/* bus_name, for command line compatibility */
+char *bus_name;
  } VirtIOSCSICommon;
  
  typedef struct {

@@ -189,5 +192,9 @@ typedef struct {
  int virtio_scsi_common_init(VirtIOSCSICommon *vs);
  int virtio_scsi_common_exit(VirtIOSCSICommon *vs);
  
+/*

+ * For command line back compatibility, set the bus name before initialisation.
+ */
+void set_virtio_scsi_bus_name

Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

[KONRAD Frédéric]

On 29/04/2013 18:30, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 07:21:06PM +0300, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 06:14:41PM +0200, KONRAD Frédéric wrote:

On 29/04/2013 18:02, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 10:55:36AM -0500, Jesse Larrew wrote:

On 04/29/2013 10:29 AM, KONRAD Frédéric wrote:

On 29/04/2013 17:14, Jesse Larrew wrote:

On 04/29/2013 09:55 AM, KONRAD Frédéric wrote:

On 29/04/2013 16:42, Jesse Larrew wrote:

On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:

On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:

Commit 14f9b664 (hw/virtio-net.c: set config size using host features) tries to
calculate config size based on the host features. But it forgets the
VIRTIO_NET_F_MAC were always set for qemu later. This will lead a zero config
len for virtio-net device when both VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ were
disabled form command line. Then qemu will crash when user tries to read the
config of virtio-net.

Fix this by counting VIRTIO_NET_F_MAC and make sure the config at least contains
the mac address.

Cc: Jesse Larrew 
Signed-off-by: Jason Wang 
---
hw/net/virtio-net.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 70c8fce..33a70ef 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1264,7 +1264,8 @@ static void virtio_net_guest_notifier_mask(VirtIODevice 
*vdev, int idx,
  void virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)
{
-int i, config_size = 0;
+/* VIRTIO_NET_F_MAC can't be disabled from qemu side */
+int i, config_size = feature_sizes[0].end;

This would be cleaner:
  host_features |= (1 << VIRTIO_NET_F_MAC);

no need for a comment then.


It seems to me that the real problem here is that host_features isn't
properly populated before virtio_net_set_config_size() is called. Looking
at virtio_device_init(), we can see why:

static int virtio_device_init(DeviceState *qdev)
{
   VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
   VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
   assert(k->init != NULL);
   if (k->init(vdev) < 0) {
   return -1;
   }
   virtio_bus_plug_device(vdev);
   return 0;
}

virtio_net_set_config_size() is currently being called as part of the
k->init call, but the host_features aren't properly setup until the device
is plugged into the bus using virtio_bus_plug_device().

After talking with mdroth, I think the proper way to fix this would be to
extend VirtioDeviceClass to include a calculate_config_size() method that
can be called at the appropriate time during device initialization like so:

static int virtio_device_init(DeviceState *qdev)
{
   VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
   VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
   assert(k->init != NULL);
   if (k->init(vdev) < 0) {
   return -1;
   }
   virtio_bus_plug_device(vdev);
+   if (k->calculate_config_size && k->calculate_config_size(vdev) < 0) {
+   return -1;
+   }
   return 0;
}

This would ensure that host_features contains the proper data before any
devices try to make use of it to calculate the config size.

Good point, I didn't saw that.

but this was not the case with commit 14f9b664 no?


I suspect this bug was present in 14f9b664 as well. We just hadn't triggered
it yet. I'll confirm this afternoon.

Ok, I think there is a problem with your patch:

 virtio_init(VIRTIO_DEVICE(n), "virtio-net", VIRTIO_ID_NET,
   n->config_size);

is called in virtio_net_device_init (k->init).

Is there a way to resize the config after that?


Nope. That's definitely a bug. I can send a patch to fix this today. Any
objection to the method suggested above (extending VirtioDeviceClass)?

This needs more thought. All devices expected everything
is setup during the init call. config size is
likely not the only issue.

So we need almost all of virtio_bus_plug_device before init,
and then after init send the signal:

 if (klass->device_plugged != NULL) {
 klass->device_plugged(qbus->parent);
 }

Seems the interesting part is in virtio_pci_device_plugged at the end:

 proxy->host_features |= 0x1 << VIRTIO_F_NOTIFY_ON_EMPTY;
 proxy->host_features |= 0x1 << VIRTIO_F_BAD_FEATURE;
 proxy->host_features = virtio_bus_get_vdev_features(bus,
proxy->host_features);

This is and was called after set_config_size, isn't that the issue?

Basically devices expected everything to be setup at
the point where init is called.
We found one bug but let's fix it properly.
There's no reason to delay parts of setup until after init,
if we do, we'll trip on more uses of uninitialized data.




for (i = 0; feature_sizes[i].flags != 0; i++) {
  

Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

[KONRAD Frédéric]

On 29/04/2013 19:01, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 06:41:08PM +0200, KONRAD Frédéric wrote:

On 29/04/2013 18:30, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 07:21:06PM +0300, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 06:14:41PM +0200, KONRAD Frédéric wrote:

On 29/04/2013 18:02, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 10:55:36AM -0500, Jesse Larrew wrote:

On 04/29/2013 10:29 AM, KONRAD Frédéric wrote:

On 29/04/2013 17:14, Jesse Larrew wrote:

On 04/29/2013 09:55 AM, KONRAD Frédéric wrote:

On 29/04/2013 16:42, Jesse Larrew wrote:

On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:

On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:

Commit 14f9b664 (hw/virtio-net.c: set config size using host features) tries to
calculate config size based on the host features. But it forgets the
VIRTIO_NET_F_MAC were always set for qemu later. This will lead a zero config
len for virtio-net device when both VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ were
disabled form command line. Then qemu will crash when user tries to read the
config of virtio-net.

Fix this by counting VIRTIO_NET_F_MAC and make sure the config at least contains
the mac address.

Cc: Jesse Larrew 
Signed-off-by: Jason Wang 
---
hw/net/virtio-net.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 70c8fce..33a70ef 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1264,7 +1264,8 @@ static void virtio_net_guest_notifier_mask(VirtIODevice 
*vdev, int idx,
  void virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)
{
-int i, config_size = 0;
+/* VIRTIO_NET_F_MAC can't be disabled from qemu side */
+int i, config_size = feature_sizes[0].end;

This would be cleaner:
  host_features |= (1 << VIRTIO_NET_F_MAC);

no need for a comment then.


It seems to me that the real problem here is that host_features isn't
properly populated before virtio_net_set_config_size() is called. Looking
at virtio_device_init(), we can see why:

static int virtio_device_init(DeviceState *qdev)
{
   VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
   VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
   assert(k->init != NULL);
   if (k->init(vdev) < 0) {
   return -1;
   }
   virtio_bus_plug_device(vdev);
   return 0;
}

virtio_net_set_config_size() is currently being called as part of the
k->init call, but the host_features aren't properly setup until the device
is plugged into the bus using virtio_bus_plug_device().

After talking with mdroth, I think the proper way to fix this would be to
extend VirtioDeviceClass to include a calculate_config_size() method that
can be called at the appropriate time during device initialization like so:

static int virtio_device_init(DeviceState *qdev)
{
   VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
   VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
   assert(k->init != NULL);
   if (k->init(vdev) < 0) {
   return -1;
   }
   virtio_bus_plug_device(vdev);
+   if (k->calculate_config_size && k->calculate_config_size(vdev) < 0) {
+   return -1;
+   }
   return 0;
}

This would ensure that host_features contains the proper data before any
devices try to make use of it to calculate the config size.

Good point, I didn't saw that.

but this was not the case with commit 14f9b664 no?


I suspect this bug was present in 14f9b664 as well. We just hadn't triggered
it yet. I'll confirm this afternoon.

Ok, I think there is a problem with your patch:

 virtio_init(VIRTIO_DEVICE(n), "virtio-net", VIRTIO_ID_NET,
   n->config_size);

is called in virtio_net_device_init (k->init).

Is there a way to resize the config after that?


Nope. That's definitely a bug. I can send a patch to fix this today. Any
objection to the method suggested above (extending VirtioDeviceClass)?

This needs more thought. All devices expected everything
is setup during the init call. config size is
likely not the only issue.

So we need almost all of virtio_bus_plug_device before init,
and then after init send the signal:

 if (klass->device_plugged != NULL) {
 klass->device_plugged(qbus->parent);
 }

Seems the interesting part is in virtio_pci_device_plugged at the end:

 proxy->host_features |= 0x1 << VIRTIO_F_NOTIFY_ON_EMPTY;
 proxy->host_features |= 0x1 << VIRTIO_F_BAD_FEATURE;
 proxy->host_features = virtio_bus_get_vdev_features(bus,
proxy->host_features);

This is and was called after set_config_size, isn't that the issue?

Basically devices expected everything to be setup at
the point where init is called.
We found one bug but let's fix it properly.
There's no reason to delay parts of setup until after init,
i

Re: [Qemu-devel] [PATCH for-1.5 4/4] virtio-scsi: fix the command line compatibility.

[KONRAD Frédéric]

On 29/04/2013 18:32, Paolo Bonzini wrote:

Il 29/04/2013 18:28, KONRAD Frédéric ha scritto:

Could this be simply a qdev property?

Yes, that can be a good idea.

What about adding a qdev property bus_name and using it in qbus_realize?

Like this:

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 4eb0134..c5d5407 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -421,6 +421,13 @@ static void qbus_realize(BusState *bus, DeviceState
*parent, const char *name)

  if (name) {
  bus->name = g_strdup(name);
+} else if (bus->parent && bus->parent->bus_name) {
+/* parent device has bus_name -> use it for bus name */
+len = strlen(bus->parent->bus_name) + 16;
+buf = g_malloc(len);
+snprintf(buf, len, "%s.%d", bus->parent->bus_name,
+ bus->parent->num_child_bus);
+bus->name = buf;
  } else if (bus->parent && bus->parent->id) {
  /* parent device has id -> use it for bus name */
  len = strlen(bus->parent->id) + 16;

If so, change to scsi_bus_new is not needed and the two new functions are
not needed.

Is that making sense?

Ah, that's a bit more extreme. :)

I think I like it, but I need more input.

Paolo

Well, just for virtio-scsi-pci, something like that:

---
 hw/core/qdev.c | 14 ++
 hw/virtio/virtio-pci.c |  9 +
 include/hw/qdev-core.h |  4 
 3 files changed, 27 insertions(+)

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 4eb0134..3aa0082 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -342,6 +342,13 @@ BusState *qdev_get_child_bus(DeviceState *dev, 
const char *name)

 return NULL;
 }

+void qdev_set_bus_name(DeviceState *dev, const char *bus_name)
+{
+if (bus_name) {
+dev->bus_name = g_strdup(bus_name);
+}
+}
+
 int qbus_walk_children(BusState *bus, qdev_walkerfn *devfn,
qbus_walkerfn *busfn, void *opaque)
 {
@@ -421,6 +428,13 @@ static void qbus_realize(BusState *bus, DeviceState 
*parent, const char *name)


 if (name) {
 bus->name = g_strdup(name);
+} else if (bus->parent && bus->parent->bus_name) {
+/* parent device has bus_name -> use it for bus name */
+len = strlen(bus->parent->bus_name) + 16;
+buf = g_malloc(len);
+snprintf(buf, len, "%s.%d", bus->parent->bus_name,
+ bus->parent->num_child_bus);
+bus->name = buf;
 } else if (bus->parent && bus->parent->id) {
 /* parent device has id -> use it for bus name */
 len = strlen(bus->parent->id) + 16;
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 070df44..8d5d146 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1106,11 +1106,20 @@ static int 
virtio_scsi_pci_init_pci(VirtIOPCIProxy *vpci_dev)

 VirtIOSCSIPCI *dev = VIRTIO_SCSI_PCI(vpci_dev);
 DeviceState *vdev = DEVICE(&dev->vdev);
 VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
+DeviceState *proxy = DEVICE(dev);

 if (vpci_dev->nvectors == DEV_NVECTORS_UNSPECIFIED) {
 vpci_dev->nvectors = vs->conf.num_queues + 3;
 }

+/*
+ * For command line compatibility, this set the virtio-scsi-device bus
+ * name as before.
+ */
+if (proxy->id) {
+qdev_set_bus_name(vdev, proxy->id);
+}
+
 qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
 if (qdev_init(vdev) < 0) {
 return -1;
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index cf83d54..332e11f 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -125,6 +125,7 @@ struct DeviceState {
 int num_child_bus;
 int instance_id_alias;
 int alias_required_for_version;
+const char *bus_name;
 };

 #define TYPE_BUS "bus"
@@ -224,6 +225,9 @@ BusState *qdev_get_child_bus(DeviceState *dev, const 
char *name);

 void qdev_init_gpio_in(DeviceState *dev, qemu_irq_handler handler, int n);
 void qdev_init_gpio_out(DeviceState *dev, qemu_irq *pins, int n);

+/* Set the bus_name property. */
+void qdev_set_bus_name(DeviceState *dev, const char *bus_name);
+
 BusState *qdev_get_parent_bus(DeviceState *dev);

 /*** BUS API. ***/
--
1.8.1.4

Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

[KONRAD Frédéric]

On 29/04/2013 19:52, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 07:23:49PM +0200, KONRAD Frédéric wrote:

On 29/04/2013 19:01, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 06:41:08PM +0200, KONRAD Frédéric wrote:

 On 29/04/2013 18:30, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 07:21:06PM +0300, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 06:14:41PM +0200, KONRAD Frédéric 
wrote:

 On 29/04/2013 18:02, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 10:55:36AM -0500, Jesse Larrew 
wrote:

 On 04/29/2013 10:29 AM, KONRAD Frédéric wrote:

 On 29/04/2013 17:14, Jesse Larrew wrote:

 On 04/29/2013 09:55 AM, KONRAD Frédéric 
wrote:

 On 29/04/2013 16:42, Jesse Larrew 
wrote:

 On 04/25/2013 01:59 AM, Michael S. 
Tsirkin wrote:

 On Thu, Apr 25, 2013 at 02:21:29PM 
+0800, Jason Wang wrote:

 Commit 14f9b664 (hw/virtio-net.c: set 
config size using host features) tries to
 calculate config size based on the 
host features. But it forgets the
 VIRTIO_NET_F_MAC were always set for 
qemu later. This will lead a zero config
 len for virtio-net device when both 
VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ were
 disabled form command line. Then qemu 
will crash when user tries to read the
 config of virtio-net.

 Fix this by counting VIRTIO_NET_F_MAC 
and make sure the config at least contains
 the mac address.

 Cc: Jesse Larrew 

 Signed-off-by: Jason Wang 

 ---
hw/net/virtio-net.c |3 ++-
1 files changed, 2 insertions(+), 1 
deletions(-)

 diff --git a/hw/net/virtio-net.c 
b/hw/net/virtio-net.c
 index 70c8fce..33a70ef 100644
 --- a/hw/net/virtio-net.c
 +++ b/hw/net/virtio-net.c
 @@ -1264,7 +1264,8 @@ static void 
virtio_net_guest_notifier_mask(VirtIODevice *vdev, int idx,
  void 
virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)
{
 -int i, config_size = 0;
 +/* VIRTIO_NET_F_MAC can't be 
disabled from qemu side */
 +int i, config_size = 
feature_sizes[0].end;

 This would be cleaner:
  host_features |= (1 << 
VIRTIO_NET_F_MAC);

 no need for a comment then.


 It seems to me that the real problem 
here is that host_features isn't
 properly populated before 
virtio_net_set_config_size() is called. Looking
 at virtio_device_init(), we can see 
why:

 static int 
virtio_device_init(DeviceState *qdev)
 {
   VirtIODevice *vdev = 
VIRTIO_DEVICE(qdev);
   VirtioDeviceClass *k = 
VIRTIO_DEVICE_GET_CLASS(qdev);
   assert(k->init != NULL);
   if (k->init(vdev) < 0) {
   return -1;
   }
   virtio_bus_plug_device(vdev);
   return 0;
 }

 virtio_net_set_config_size() is 
currently being called as part of the
 k->init call, but the host_features 
aren't properly setup until the device
 is plugged into the bus using 
virtio_bus_plug_device().

 After talking with mdroth, I think the 
proper way to fix this would be to
   

Re: [Qemu-devel] [PATCH for-1.5 4/4] virtio-scsi: fix the command line compatibility.

[KONRAD Frédéric]

On 29/04/2013 19:55, Andreas Färber wrote:

Am 29.04.2013 19:39, schrieb KONRAD Frédéric:

On 29/04/2013 18:32, Paolo Bonzini wrote:

Il 29/04/2013 18:28, KONRAD Frédéric ha scritto:

Could this be simply a qdev property?

Yes, that can be a good idea.

What about adding a qdev property bus_name and using it in qbus_realize?

Like this:

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 4eb0134..c5d5407 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -421,6 +421,13 @@ static void qbus_realize(BusState *bus, DeviceState
*parent, const char *name)

   if (name) {
   bus->name = g_strdup(name);
+} else if (bus->parent && bus->parent->bus_name) {
+/* parent device has bus_name -> use it for bus name */
+len = strlen(bus->parent->bus_name) + 16;
+buf = g_malloc(len);
+snprintf(buf, len, "%s.%d", bus->parent->bus_name,
+ bus->parent->num_child_bus);
+bus->name = buf;
   } else if (bus->parent && bus->parent->id) {
   /* parent device has id -> use it for bus name */
   len = strlen(bus->parent->id) + 16;

If so, change to scsi_bus_new is not needed and the two new functions
are
not needed.

Is that making sense?

Ah, that's a bit more extreme. :)

I think I like it, but I need more input.

Paolo

Well, just for virtio-scsi-pci, something like that:

---
  hw/core/qdev.c | 14 ++
  hw/virtio/virtio-pci.c |  9 +
  include/hw/qdev-core.h |  4 
  3 files changed, 27 insertions(+)

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 4eb0134..3aa0082 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -342,6 +342,13 @@ BusState *qdev_get_child_bus(DeviceState *dev,
const char *name)
  return NULL;
  }

+void qdev_set_bus_name(DeviceState *dev, const char *bus_name)

device_... for new functions please. :)


+{


Might be called multiple times, so better insert:

if (dev->bus_name) {
 g_free(dev->bus_name);
 dev->bus_name = NULL;
}


+if (bus_name) {
+dev->bus_name = g_strdup(bus_name);
+}
+}
+
  int qbus_walk_children(BusState *bus, qdev_walkerfn *devfn,
 qbus_walkerfn *busfn, void *opaque)
  {
@@ -421,6 +428,13 @@ static void qbus_realize(BusState *bus, DeviceState
*parent, const char *name)

  if (name) {
  bus->name = g_strdup(name);
+} else if (bus->parent && bus->parent->bus_name) {
+/* parent device has bus_name -> use it for bus name */

This seems backwards to me. qdev had made sure to have a 1:n
relationship between device and bus, whereas you are making the name
template 1:1 here. Don't you rather want a qbus_set_name() mechanism
operating on the bus?


What do you mean with the relationship 1:n / 1:1 I don't understand?

Note: I did that quickly to ask Paolo if it was worth doing like that or 
like the original

 series.



+len = strlen(bus->parent->bus_name) + 16;

Why 15 decimal digits? Is there any constant we could reuse?


+buf = g_malloc(len);
+snprintf(buf, len, "%s.%d", bus->parent->bus_name,
+ bus->parent->num_child_bus);
+bus->name = buf;
  } else if (bus->parent && bus->parent->id) {
  /* parent device has id -> use it for bus name */
  len = strlen(bus->parent->id) + 16;
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 070df44..8d5d146 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1106,11 +1106,20 @@ static int
virtio_scsi_pci_init_pci(VirtIOPCIProxy *vpci_dev)
  VirtIOSCSIPCI *dev = VIRTIO_SCSI_PCI(vpci_dev);
  DeviceState *vdev = DEVICE(&dev->vdev);
  VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
+DeviceState *proxy = DEVICE(dev);

  if (vpci_dev->nvectors == DEV_NVECTORS_UNSPECIFIED) {
  vpci_dev->nvectors = vs->conf.num_queues + 3;
  }

+/*
+ * For command line compatibility, this set the virtio-scsi-device bus

"sets"


+ * name as before.
+ */
+if (proxy->id) {
+qdev_set_bus_name(vdev, proxy->id);
+}
+
  qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
  if (qdev_init(vdev) < 0) {
  return -1;
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index cf83d54..332e11f 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -125,6 +125,7 @@ struct DeviceState {
  int num_child_bus;
  int instance_id_alias;
  int alias_required_for_version;
+const char *bus_name;
  };

  #define TYPE_BUS "bus"
@@ -224,6 +225,9 @@ BusState *qdev_get_child_bus(DeviceState *dev, const
char *name);
  void qdev_init_gpio_in(DeviceState *dev, qemu_irq_handler handler, int n);
  void qdev_init_gpio_out(DeviceState *dev, qemu_irq *pins, int n);

+/* Set the bus_name property. */
+void qdev_set_bus_name(DeviceState *dev, const char *bus_name);
+
  BusState *qdev_get_parent_bus(DeviceState *dev);

  /*** BUS API. ***/

Andreas

Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

[KONRAD Frédéric]

On 29/04/2013 20:15, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 08:01:52PM +0200, KONRAD Frédéric wrote:

On 29/04/2013 19:52, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 07:23:49PM +0200, KONRAD Frédéric wrote:

On 29/04/2013 19:01, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 06:41:08PM +0200, KONRAD Frédéric wrote:

 On 29/04/2013 18:30, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 07:21:06PM +0300, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 06:14:41PM +0200, KONRAD Frédéric 
wrote:

 On 29/04/2013 18:02, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 10:55:36AM -0500, Jesse Larrew 
wrote:

 On 04/29/2013 10:29 AM, KONRAD Frédéric wrote:

 On 29/04/2013 17:14, Jesse Larrew wrote:

 On 04/29/2013 09:55 AM, KONRAD Frédéric 
wrote:

 On 29/04/2013 16:42, Jesse Larrew 
wrote:

 On 04/25/2013 01:59 AM, Michael S. 
Tsirkin wrote:

 On Thu, Apr 25, 2013 at 02:21:29PM 
+0800, Jason Wang wrote:

 Commit 14f9b664 (hw/virtio-net.c: set 
config size using host features) tries to
 calculate config size based on the 
host features. But it forgets the
 VIRTIO_NET_F_MAC were always set for 
qemu later. This will lead a zero config
 len for virtio-net device when both 
VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ were
 disabled form command line. Then qemu 
will crash when user tries to read the
 config of virtio-net.

 Fix this by counting VIRTIO_NET_F_MAC 
and make sure the config at least contains
 the mac address.

 Cc: Jesse Larrew 

 Signed-off-by: Jason Wang 

 ---
hw/net/virtio-net.c |3 ++-
1 files changed, 2 insertions(+), 1 
deletions(-)

 diff --git a/hw/net/virtio-net.c 
b/hw/net/virtio-net.c
 index 70c8fce..33a70ef 100644
 --- a/hw/net/virtio-net.c
 +++ b/hw/net/virtio-net.c
 @@ -1264,7 +1264,8 @@ static void 
virtio_net_guest_notifier_mask(VirtIODevice *vdev, int idx,
  void 
virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)
{
 -int i, config_size = 0;
 +/* VIRTIO_NET_F_MAC can't be 
disabled from qemu side */
 +int i, config_size = 
feature_sizes[0].end;

 This would be cleaner:
  host_features |= (1 << 
VIRTIO_NET_F_MAC);

 no need for a comment then.


 It seems to me that the real problem 
here is that host_features isn't
 properly populated before 
virtio_net_set_config_size() is called. Looking
 at virtio_device_init(), we can see 
why:

 static int 
virtio_device_init(DeviceState *qdev)
 {
   VirtIODevice *vdev = 
VIRTIO_DEVICE(qdev);
   VirtioDeviceClass *k = 
VIRTIO_DEVICE_GET_CLASS(qdev);
   assert(k->init != NULL);
   if (k->init(vdev) < 0) {
   return -1;
   }
   virtio_bus_plug_device(vdev);
   return 0;
 }

 virtio_net_set_config_size() is 
currently being called as part of the
 k->init call, but the host_features 
aren't properly setup until the device
 is plugged into the bus using 
virtio_bus_plug_device().

 A

Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

[KONRAD Frédéric]

On 29/04/2013 22:09, Michael S. Tsirkin wrote:

On Mon, Apr 29, 2013 at 08:45:50PM +0200, KONRAD Frédéric wrote:

On 29/04/2013 20:15, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 08:01:52PM +0200, KONRAD Frédéric wrote:

 On 29/04/2013 19:52, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 07:23:49PM +0200, KONRAD Frédéric wrote:

 On 29/04/2013 19:01, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 06:41:08PM +0200, KONRAD Frédéric 
wrote:

 On 29/04/2013 18:30, Michael S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 07:21:06PM +0300, Michael 
S. Tsirkin wrote:

 On Mon, Apr 29, 2013 at 06:14:41PM +0200, 
KONRAD Frédéric wrote:

 On 29/04/2013 18:02, Michael S. Tsirkin 
wrote:

 On Mon, Apr 29, 2013 at 10:55:36AM 
-0500, Jesse Larrew wrote:

 On 04/29/2013 10:29 AM, KONRAD 
Frédéric wrote:

 On 29/04/2013 17:14, Jesse 
Larrew wrote:

 On 04/29/2013 09:55 AM, 
KONRAD Frédéric wrote:

 On 29/04/2013 16:42, 
Jesse Larrew wrote:

 On 04/25/2013 01:59 
AM, Michael S. Tsirkin wrote:

 On Thu, Apr 25, 2013 
at 02:21:29PM +0800, Jason Wang wrote:

 Commit 14f9b664 
(hw/virtio-net.c: set config size using host features) tries to
 calculate config size 
based on the host features. But it forgets the
 VIRTIO_NET_F_MAC were 
always set for qemu later. This will lead a zero config
 len for virtio-net 
device when both VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ were
 disabled form command 
line. Then qemu will crash when user tries to read the
 config of virtio-net.

 Fix this by counting 
VIRTIO_NET_F_MAC and make sure the config at least contains
 the mac address.

 Cc: Jesse Larrew 

 Signed-off-by: Jason Wang 

 ---
hw/net/virtio-net.c 
|3 ++-
1 files changed, 2 
insertions(+), 1 deletions(-)

 diff --git 
a/hw/net/virtio-net.c b/hw/net/virtio-net.c
 index 70c8fce..33a70ef 
100644
 --- 
a/hw/net/virtio-net.c
 +++ 
b/hw/net/virtio-net.c
 @@ -1264,7 +1264,8 @@ 
static void virtio_net_guest_notifier_mask(VirtIODevice *vdev, int idx,
  void 
virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)
{
 -int i, 
config_size = 0;
 +/* 
VIRTIO_NET_F_MAC can't be disabled from qemu side */
 +int i, 
config_size = feature_sizes[0].end;

 This would be cleaner:
  host_features |= (1 
<< VIRTIO_NET_F_MAC);

 no need for a comment 
then.


 It seems to me that 
the real problem here is that host_features isn't
 properly populated 
before virtio_net_set_config_size() is called. Looking
 at 
virtio_device_init(), we can see why:

 static int 
virtio_device_init(DeviceState *qdev)
 {
   VirtIODevice 
*vdev = VI

Re: [Qemu-devel] [PATCH for-1.5 4/4] virtio-scsi: fix the command line compatibility.

[KONRAD Frédéric]

On 29/04/2013 17:44, Paolo Bonzini wrote:

Il 29/04/2013 17:12, fred.kon...@greensocs.com ha scritto:

From: KONRAD Frederic 

The bus name is wrong since the refactoring.

This keep the behaviour of the command line.

Signed-off-by: KONRAD Frederic 
---
  hw/s390x/s390-virtio-bus.c  |  9 +
  hw/s390x/virtio-ccw.c   |  9 +
  hw/scsi/virtio-scsi.c   | 14 +-
  hw/virtio/virtio-pci.c  |  9 +
  include/hw/virtio/virtio-scsi.h |  7 +++
  5 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
index 6620d29..e1fd937 100644
--- a/hw/s390x/s390-virtio-bus.c
+++ b/hw/s390x/s390-virtio-bus.c
@@ -232,6 +232,15 @@ static int s390_virtio_scsi_init(VirtIOS390Device 
*s390_dev)
  {
  VirtIOSCSIS390 *dev = VIRTIO_SCSI_S390(s390_dev);
  DeviceState *vdev = DEVICE(&dev->vdev);
+DeviceState *qdev = DEVICE(s390_dev);
+
+/*
+ * For command line compatibility, this set the virtio-scsi-device bus
+ * name as before.
+ */
+if (qdev->id) {
+set_virtio_scsi_bus_name(vdev, qdev->id);
+}

Could this be simply a qdev property?


Well, maybe my solution is too extreme.

Maybe I can put bus_name in struct VirtIODevice instead to avoid the
set_virtio_x_bus_name code duplication?


Consider that qdev will strdup any bus name you pass, so it is perfectly
ok to do:

bus_name = g_strdup_printf("%s.0", vs->bus_name);
scsi_bus_new(..., bus_name);
g_free(bus_name);


+void set_virtio_scsi_bus_name(DeviceState *dev, const char *bus_name)
+{
+VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(dev);
+if (bus_name) {
+vs->bus_name = g_malloc(strlen(bus_name) + 3);
+snprintf(vs->bus_name, strlen(bus_name) + 3, "%s.0", bus_name);

This would use g_strdup_printf, as above.

Paolo


+}
+}
+
  int virtio_scsi_common_init(VirtIOSCSICommon *s)
  {
  VirtIODevice *vdev = VIRTIO_DEVICE(s);
@@ -624,7 +633,7 @@ static int virtio_scsi_device_init(VirtIODevice *vdev)
  return ret;
  }
  
-scsi_bus_new(&s->bus, qdev, &virtio_scsi_scsi_info);

+scsi_named_bus_new(&s->bus, qdev, &virtio_scsi_scsi_info, vs->bus_name);
  if (!qdev->hotplugged) {
  scsi_bus_legacy_handle_cmdline(&s->bus);
  }
@@ -639,6 +648,9 @@ int virtio_scsi_common_exit(VirtIOSCSICommon *vs)
  {
  VirtIODevice *vdev = VIRTIO_DEVICE(vs);
  
+if (vs->bus_name) {

+g_free(vs->bus_name);
+}
  g_free(vs->cmd_vqs);
  virtio_cleanup(vdev);
  return 0;
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 598876f..14fb8dd 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1106,11 +1106,20 @@ static int virtio_scsi_pci_init_pci(VirtIOPCIProxy 
*vpci_dev)
  VirtIOSCSIPCI *dev = VIRTIO_SCSI_PCI(vpci_dev);
  DeviceState *vdev = DEVICE(&dev->vdev);
  VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
+DeviceState *proxy = DEVICE(vpci_dev);
  
  if (vpci_dev->nvectors == DEV_NVECTORS_UNSPECIFIED) {

  vpci_dev->nvectors = vs->conf.num_queues + 3;
  }
  
+/*

+ * For command line compatibility, this set the virtio-scsi-device bus
+ * name as before.
+ */
+if (proxy->id) {
+set_virtio_scsi_bus_name(vdev, proxy->id);
+}
+
  qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
  if (qdev_init(vdev) < 0) {
  return -1;
diff --git a/include/hw/virtio/virtio-scsi.h b/include/hw/virtio/virtio-scsi.h
index 4db346b..c356d54 100644
--- a/include/hw/virtio/virtio-scsi.h
+++ b/include/hw/virtio/virtio-scsi.h
@@ -164,6 +164,9 @@ typedef struct VirtIOSCSICommon {
  VirtQueue *ctrl_vq;
  VirtQueue *event_vq;
  VirtQueue **cmd_vqs;
+
+/* bus_name, for command line compatibility */
+char *bus_name;
  } VirtIOSCSICommon;
  
  typedef struct {

@@ -189,5 +192,9 @@ typedef struct {
  int virtio_scsi_common_init(VirtIOSCSICommon *vs);
  int virtio_scsi_common_exit(VirtIOSCSICommon *vs);
  
+/*

+ * For command line back compatibility, set the bus name before initialisation.
+ */
+void set_virtio_scsi_bus_name(DeviceState *dev, const char *bus_name);
  
  #endif /* _QEMU_VIRTIO_SCSI_H */

Re: [Qemu-devel] [PATCH for-1.5 4/4] virtio-scsi: fix the command line compatibility.

[KONRAD Frédéric]

On 30/04/2013 16:01, Paolo Bonzini wrote:

Il 30/04/2013 15:06, KONRAD Frédéric ha scritto:

Could this be simply a qdev property?

Well, maybe my solution is too extreme.

Maybe I can put bus_name in struct VirtIODevice instead to avoid the
set_virtio_x_bus_name code duplication?

No, I think it should be either DeviceState or single devices.

Paolo


oops, just sent the fix with bus_name in VirtIODevice..

I think it's not necessary to put bus_name in DeviceState as it is only 
needed for these two devices.


But it may be better for it to be in VirtIODevice no?

Re: [Qemu-devel] [PATCH for-1.5 v2 0/5] virtio: fix bus command line compatibility.

[KONRAD Frédéric]

On 02/05/2013 15:40, Cornelia Huck wrote:

On Tue, 30 Apr 2013 16:08:46 +0200
fred.kon...@greensocs.com wrote:


From: KONRAD Frederic 

Cc: Libaiqing 
Cc: Michal Privoznik 

This fixes the bus name for virtio-serial-device and virtio-scsi-device.

The bus name for virtio-serial-device and virtio-scsi-device is not "id.0" as it
was the case before the refactoring.

This trigger the error:

qemu-system-xxx -device virtio-serial-pci,id=virtio-serial0
 -device virtserialport,bus=virtio-serial0.0

Bus 'virtio-serial0.0' is full
Bus 'virtio-serial0.0' not found

Seems to look sane on s390-virtio and virtio-ccw.

Tested-by: Cornelia Huck 


Thanks for that :).

Fred



So this sets the name of those bus before the virtio-device's init.

KONRAD Frederic (5):
   virtio-x-bus: force bus name to virtio-bus.
   virtio: add virtio_device_set_child_bus_name.
   scsi: add bus_name parameter to scsi_bus_new.
   virtio-serial: fix command line compatibility.
   virtio-scsi: fix the command line compatibility.

  hw/char/virtio-serial-bus.c |  3 ++-
  hw/s390x/s390-virtio-bus.c  | 28 +++-
  hw/s390x/virtio-ccw.c   | 28 +++-
  hw/scsi/esp-pci.c   |  2 +-
  hw/scsi/esp.c   |  2 +-
  hw/scsi/lsi53c895a.c|  2 +-
  hw/scsi/megasas.c   |  2 +-
  hw/scsi/scsi-bus.c  |  5 +++--
  hw/scsi/spapr_vscsi.c   |  2 +-
  hw/scsi/virtio-scsi.c   |  3 ++-
  hw/scsi/vmw_pvscsi.c|  2 +-
  hw/usb/dev-storage.c|  4 ++--
  hw/usb/dev-uas.c|  2 +-
  hw/virtio/virtio-pci.c  | 29 -
  hw/virtio/virtio.c  | 24 
  include/hw/scsi/scsi.h  |  3 ++-
  include/hw/virtio/virtio-scsi.h |  1 -
  include/hw/virtio/virtio.h  |  4 
  18 files changed, 128 insertions(+), 18 deletions(-)

Re: [Qemu-devel] [PATCH for-1.5] virtio-pci: bugfix

[KONRAD Frédéric]

On 06/05/2013 22:51, Anthony Liguori wrote:

"Michael S. Tsirkin"  writes:


mask notifiers are never called without msix,
so devices with backend masking like vhost don't work.
Call mask notifiers explicitly at
startup/cleanup to make it work.

Signed-off-by: Michael S. Tsirkin 
Tested-by: Alexander Graf 

/home/aliguori/git/qemu/hw/virtio/virtio-pci.c: In function 
‘virtio_pci_set_guest_notifier’:
/home/aliguori/git/qemu/hw/virtio/virtio-pci.c:761:54: error: ‘VirtIODevice’ 
has no member named ‘guest_notifier_mask’
/home/aliguori/git/qemu/hw/virtio/virtio-pci.c:762:20: error: ‘VirtIODevice’ 
has no member named ‘guest_notifier_mask’
   CChw/virtio/dataplane/hostmem.o
make: *** [hw/virtio/virtio-pci.o] Error 1

Regards,

Anthony Liguori


---
  hw/virtio/virtio-pci.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 8bba0f3..d0fcc6c 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -758,6 +758,10 @@ static int virtio_pci_set_guest_notifier(DeviceState *d, 
int n, bool assign,
  event_notifier_cleanup(notifier);
  }
  
+if (!msix_enabled(&proxy->pci_dev) && proxy->vdev->guest_notifier_mask) {

+proxy->vdev->guest_notifier_mask(proxy->vdev, n, !assign);
+}
+
  return 0;
  }
  
--

MST

You need to use, VirtioDeviceClass to use guest_notifier_mask:

VirtIODevice *vdev = proxy->vdev;
VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(vdev);

then:

if (!msix_enabled(&proxy->pci_dev) && k->guest_notifier_mask) {
k->guest_notifier_mask(vdev, n, !assign);
}


Fred

Re: [Qemu-devel] [PATCHv2 for-1.5] virtio-pci: fix level interrupts

[KONRAD Frédéric]

On 07/05/2013 12:20, Michael S. Tsirkin wrote:

mask notifiers are never called without msix,
so devices with backend masking like vhost don't work.
Call mask notifiers explicitly at
startup/cleanup to make it work.

Signed-off-by: Michael S. Tsirkin 
Tested-by: Alexander Graf 
---

Changes from v1:
 - rebase to master

  hw/virtio/virtio-pci.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index d8708c1..c97aee1 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -744,6 +744,7 @@ static int virtio_pci_set_guest_notifier(DeviceState *d, 
int n, bool assign,
   bool with_irqfd)
  {
  VirtIOPCIProxy *proxy = to_virtio_pci_proxy(d);
+VirtioDeviceClass *vdc = VIRTIO_DEVICE_GET_CLASS(d);


I think there is a mistake here.
VIRTIO_DEVICE_GET_CLASS(proxy->vdev) should be used.

  VirtQueue *vq = virtio_get_queue(proxy->vdev, n);
  EventNotifier *notifier = virtio_queue_get_guest_notifier(vq);
  
@@ -758,6 +759,10 @@ static int virtio_pci_set_guest_notifier(DeviceState *d, int n, bool assign,

  event_notifier_cleanup(notifier);
  }
  
+if (!msix_enabled(&proxy->pci_dev) && vdc->guest_notifier_mask) {

+vdc->guest_notifier_mask(proxy->vdev, n, !assign);
+}
+
  return 0;
  }
  

Re: [Qemu-devel] [PATCH] virtio-net: require that config size is initialized

[KONRAD Frédéric]

Hi,

I think it is not a good idea, as we wanted to make VirtIODevice 
hot-pluggable for virtio-mmio.


Maybe we can use a callback which is called by virtio-bus before 
plugging, to ensure that this

config size is computed?

On 07/05/2013 12:22, Michael S. Tsirkin wrote:

All buses do this, and if they don't they get subtle
bugs related to cross version migration.
Let's add an assert to catch these bugs early.

Signed-off-by: Michael S. Tsirkin 
---

Just a cleanup so not 1.5 material.
Seems to work fine here - any opinions?

  hw/net/virtio-net.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 908e7b8..f0a9272 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1282,6 +1282,8 @@ static int virtio_net_device_init(VirtIODevice *vdev)
  DeviceState *qdev = DEVICE(vdev);
  VirtIONet *n = VIRTIO_NET(vdev);
  
+/* Verify that config size has been initialized */

+assert(n->config_size != (size_t)-1);
  virtio_init(VIRTIO_DEVICE(n), "virtio-net", VIRTIO_ID_NET,
n->config_size);
  
@@ -1386,10 +1388,9 @@ static void virtio_net_instance_init(Object *obj)

  VirtIONet *n = VIRTIO_NET(obj);
  
  /*

- * The default config_size is sizeof(struct virtio_net_config).
- * Can be overriden with virtio_net_set_config_size.
+ * The config_size must be set later with virtio_net_set_config_size.
   */
-n->config_size = sizeof(struct virtio_net_config);
+n->config_size = (size_t)-1;
  }
  
  static Property virtio_net_properties[] = {

Re: [Qemu-devel] [PATCH] virtio-net: require that config size is initialized

[KONRAD Frédéric]

On 07/05/2013 14:33, Michael S. Tsirkin wrote:

On Tue, May 07, 2013 at 02:29:38PM +0200, KONRAD Frédéric wrote:

Hi,

I think it is not a good idea, as we wanted to make VirtIODevice
hot-pluggable for virtio-mmio.

And then this hack will break cross version migration.


Why?

virtio_net_set_config_size is called by each "proxy" devices no?




Maybe we can use a callback which is called by virtio-bus before
plugging, to ensure that this
config size is computed?

OK, will you post such a patch?



The issue is as we said in the last thread, host_feature is part of the 
proxy.


And if we want to move it to the devices, we must have a kind of 
property forwarding mechanism.


Anthony said he had something about that.


On 07/05/2013 12:22, Michael S. Tsirkin wrote:

All buses do this, and if they don't they get subtle
bugs related to cross version migration.
Let's add an assert to catch these bugs early.

Signed-off-by: Michael S. Tsirkin 
---

Just a cleanup so not 1.5 material.
Seems to work fine here - any opinions?

  hw/net/virtio-net.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 908e7b8..f0a9272 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1282,6 +1282,8 @@ static int virtio_net_device_init(VirtIODevice *vdev)
  DeviceState *qdev = DEVICE(vdev);
  VirtIONet *n = VIRTIO_NET(vdev);
+/* Verify that config size has been initialized */
+assert(n->config_size != (size_t)-1);
  virtio_init(VIRTIO_DEVICE(n), "virtio-net", VIRTIO_ID_NET,
n->config_size);
@@ -1386,10 +1388,9 @@ static void virtio_net_instance_init(Object *obj)
  VirtIONet *n = VIRTIO_NET(obj);
  /*
- * The default config_size is sizeof(struct virtio_net_config).
- * Can be overriden with virtio_net_set_config_size.
+ * The config_size must be set later with virtio_net_set_config_size.
   */
-n->config_size = sizeof(struct virtio_net_config);
+n->config_size = (size_t)-1;
  }
  static Property virtio_net_properties[] = {

Re: [Qemu-devel] [PATCH] virtio-net: require that config size is initialized

[KONRAD Frédéric]

On 07/05/2013 16:00, Michael S. Tsirkin wrote:

On Tue, May 07, 2013 at 02:54:38PM +0200, KONRAD Frédéric wrote:

On 07/05/2013 14:33, Michael S. Tsirkin wrote:

On Tue, May 07, 2013 at 02:29:38PM +0200, KONRAD Frédéric wrote:

Hi,

I think it is not a good idea, as we wanted to make VirtIODevice
hot-pluggable for virtio-mmio.

And then this hack will break cross version migration.

Why?

virtio_net_set_config_size is called by each "proxy" devices no?

If it's called then there's no need for a default,
so this patch should be fine.


True but as I told you, we made this refactoring to be able to hot-plug
VirtIODevice on a virtio-bus, so calling this function won't be possible.

But you are right this must be fixed.




Maybe we can use a callback which is called by virtio-bus before
plugging, to ensure that this
config size is computed?

OK, will you post such a patch?


The issue is as we said in the last thread, host_feature is part of
the proxy.

Maybe you could add documentation on how initialization works?
If I could fiure it out I would maybe suggest some solutions.


Yes, where do you think I can add this?




And if we want to move it to the devices, we must have a kind of
property forwarding mechanism.

Anthony said he had something about that.

All buses do this, and if they don't they get subtle
bugs related to cross version migration.
Let's add an assert to catch these bugs early.

Signed-off-by: Michael S. Tsirkin 
---

Just a cleanup so not 1.5 material.
Seems to work fine here - any opinions?

  hw/net/virtio-net.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 908e7b8..f0a9272 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1282,6 +1282,8 @@ static int virtio_net_device_init(VirtIODevice *vdev)
  DeviceState *qdev = DEVICE(vdev);
  VirtIONet *n = VIRTIO_NET(vdev);
+/* Verify that config size has been initialized */
+assert(n->config_size != (size_t)-1);
  virtio_init(VIRTIO_DEVICE(n), "virtio-net", VIRTIO_ID_NET,
n->config_size);
@@ -1386,10 +1388,9 @@ static void virtio_net_instance_init(Object *obj)
  VirtIONet *n = VIRTIO_NET(obj);
  /*
- * The default config_size is sizeof(struct virtio_net_config).
- * Can be overriden with virtio_net_set_config_size.
+ * The config_size must be set later with virtio_net_set_config_size.
   */
-n->config_size = sizeof(struct virtio_net_config);
+n->config_size = (size_t)-1;
  }
  static Property virtio_net_properties[] = {

[Qemu-devel] [RFC] reverse execution.

[KONRAD Frédéric]

Hi,

We are trying to find a way to do reverse execution happen with QEMU.

Actually, it is possible to debug the guest through the gdbstub, we want to
make the reverse execution possible with GDB as well.

How we are trying to make that working (basically without optimisation):

-QEMU takes regular snapshot of the VM:
   that can be done with the save vm code without optimisation first.

-When the VM is stopped and GDB requests a reverse-step:
   load the last snapshot and replay to one instruction before the 
current PC.


There are one issue with that for now (for a basic running reverse 
execution):

-How to stop one instruction before the actual PC.

We though that using "-icount" and stop the guest a little time before the
actual position would give us the right behavior (We use a qemu_timer with
vm_clock to stop the vm at the good time), but it seems that it is not
deterministic, and not reproducable.

Is that normal?

We don't make any input during the replay, and we though that it can be 
caused

by some timer interruption but "-icount" is using a virtual timer as I
understand?

We have two other ideas:

-Using TCI and count each instruction executed by the processor, 
then stop

one instruction before the actual position. This seems slower.

-Using single-step to count each instruction, then stop one instruction
before the actual position.

Would that be better?

For now we can restore the VM from the last snapshot, when we do a 
reverse-step

but we can't stop at the exact position.

Thanks,
Fred

[Qemu-devel] [RFC] save/restore with icount enabled.

[KONRAD Frédéric]

Hi,

We are trying to do a simple save/restore on the VM with icount enabled.

We saw that qemu_icount_bias and qemu_icount in cpus.c are not 
saved/restored,

and icount_extra, icount_decr in CPUState neither, so the vm_clock is just
growing normally after restoring the VM is that normal?

We think that this is making the "replay" undeterminastic, which is bad for
reverse execution.

Is there a good reason for them not being saved?

Thanks,
Fred

Re: [Qemu-devel] [PATCH for-1.5 1/2] virtio-net: add virtio_net_set_netclient_name.

[KONRAD Frédéric]

On 15/05/2013 15:16, Stefan Hajnoczi wrote:

On Wed, May 15, 2013 at 02:12:49PM +0200, fred.kon...@greensocs.com wrote:

@@ -1315,8 +1338,17 @@ static int virtio_net_device_init(VirtIODevice *vdev)
  memcpy(&n->mac[0], &n->nic_conf.macaddr, sizeof(n->mac));
  n->status = VIRTIO_NET_S_LINK_UP;
  
-n->nic = qemu_new_nic(&net_virtio_info, &n->nic_conf,

-  object_get_typename(OBJECT(qdev)), qdev->id, n);
+if (n->netclient_type) {
+/*
+ * Happen when virtio_net_set_netclient_name has been called.
+ */
+n->nic = qemu_new_nic(&net_virtio_info, &n->nic_conf,
+  n->netclient_type, n->netclient_name, n);
+} else {
+n->nic = qemu_new_nic(&net_virtio_info, &n->nic_conf,
+  object_get_typename(OBJECT(qdev)), qdev->id, n);
+}

Does the 'else' case ever happen?  In the next patch you update all
callers to invoke virtio_net_set_netclient_name().



Yes, we made virtio-bus hot-plugguable for virtio-mmio, which won't work 
like pci, s390 or CCW.

So virtio_net_set_netclient_name will not be called in that case.

Maybe worth to remove it and push it with virtio-mmio series? Peter?

Thanks,
Fred

Re: [Qemu-devel] [RFC] save/restore with icount enabled.

[KONRAD Frédéric]

On 15/05/2013 14:50, Paolo Bonzini wrote:

Il 15/05/2013 11:31, KONRAD Frédéric ha scritto:

Hi,

We are trying to do a simple save/restore on the VM with icount enabled.

We saw that qemu_icount_bias and qemu_icount in cpus.c are not
saved/restored,
and icount_extra, icount_decr in CPUState neither, so the vm_clock is just
growing normally after restoring the VM is that normal?

We think that this is making the "replay" undeterminastic, which is bad for
reverse execution.

Is there a good reason for them not being saved?

No.  You can probably move icount to timers_state.  Something like
zeroing qemu_icount in cpu_disable_ticks() is required in order to save
qemu_icount_bias like the other members of timers_state.  There is even
a dummy field that you can reuse to avoid the pain of adding a
subsection to vmstate_timers. :)

Paolo


Yes nice point :).

What about icount_extra and icount_decr defined in CPU_COMMON? in 
cpu-defs.h?


int64_t icount_extra; /* Instructions until next timer event. */   \
/* Number of cycles left, with interrupt flag in high bit.  \
   This allows a single read-compare-cbranch-write sequence to test \
   for both decrementer underflow and exceptions. */   \
union { \
uint32_t u32;   \
icount_decr_u16 u16;\
} icount_decr;  \

Thanks,
Fred

Thanks,
Fred

Re: [Qemu-devel] [ANNOUNCE] QEMU 1.5.0-rc2 is now available

[KONRAD Frédéric]

On 16/05/2013 16:21, mdroth wrote:

On Wed, May 15, 2013 at 06:53:47PM -0500, Anthony Liguori wrote:

Hi,

On behalf of the QEMU Team, I'd like to announce the availability of the
third release candidate for the QEMU 1.5 release.  This release is meant
for testing purposes and should not be used in a production environment.

http://wiki.qemu.org/download/qemu-1.5.0-rc2.tar.bz2

You can help improve the quality of the QEMU 1.5 release by testing this
release and reporting bugs on Launchpad:


Sorry to chime in on this so late in the cycle, but I just noticed what
seems to be a pretty serious problem with migration to/from 1.4. This is
the failure for 1.4 -> 1.5-rc2

(qemu) migrate unix:/tmp/migrate.sock
Unknown savevm section or instance ':00:03.0/virtio-net' 0

Configuration:

source: v14/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -L v14-bios -M
pc-i440fx-1.4 -m 512M -kernel boot/vmlinuz-x86_64 -initrd
boot/test-initramfs-x86_64.img.gz -vga std -append seed=1234 -drive
file=disk1.img,if=virtio -drive file=disk2.img,if=virtio -net
nic,model=virtio -net user -monitor unix:/tmp/vm-hmp.sock,server,nowait
-qmp unix:/tmp/vm-qmp.sock,server,nowait -vnc :100

target: v15rc2/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -L temp-bios
-M pc-i440fx-1.4 -m 512M -kernel boot/vmlinuz-x86_64 -initrd
boot/test-initramfs-x86_64.img.gz -vga std -append seed=1234 -drive
file=disk1.img,if=virtio -drive file=disk2.img,if=virtio -net
nic,model=virtio -net user -incoming unix:/tmp/migrate.sock -monitor
unix:/tmp/vm-hmp-incoming.sock,server,nowait -qmp
unix:/tmp/vm-qmp-incoming.sock,server,nowait -vnc :101
QEMU 1.4.0 monitor - type 'help' for more information

This seems to have been introduced with the virtio refactoring:

commit e37da3945fa2fde161e1b217f937fc318c4b7639
Author: KONRAD Frederic 
Date:   Thu Apr 11 16:29:58 2013 +0200

 virtio-net-pci: switch to the new API.
 
 Here the virtio-net-pci is modified for the new API. The device

 virtio-net-pci extends virtio-pci. It creates and connects a
 virtio-net-device during the init. The properties are not changed.
 
 Signed-off-by: KONRAD Frederic 

 Tested-by: Cornelia Huck 
 Message-id: 1365690602-22729-4-git-send-email-fred.kon...@greensocs.com
 Signed-off-by: Anthony Liguori 

And if we roll that back, we have similar failures for virtio-blk, and most
likely the other virtio devices touched by the refactoring.

The issue seems to be a change the way section id strings are generated in
vmstate_register(). In v1.4.x we had:

se->instance_id: 0, se->idstr: :00:03.0/virtio-net

In v1.5.0-rc2 we have:

se->instance_id: 0, se->idstr: virtio-net

This seems to be due to the fact that these devices now sit on a
TYPE_VIRTIO_BUS that has no implementation of TYPE_BUS's get_dev_path()
interface, which is what savevm uses to calculate the id prefix for
se->idstr.

Prior to the refactoring, the device sat on a TYPE_PCI_BUS which used
pcibus_get_dev_path() to calculate this.

I'm not sure what the best fix is for this. I looking at implementing
get_dev_path() for TYPE_VIRTIO_BUS, but to maintain migration
compatibility we'd end up baking in PCI-specific stuff which from what
I gather is exactly what we were trying to avoid there.

I think adding a compat string property to TYPE_VIRTIO_DEVICE and having
that get set somewhere like virtio_bus_plug_device() is a better
approach, but vmstate_register() gets call during TYPE_VIRTIO_DEVICE
init which I think happens before then.

Still looking at it but if someone more familiar with this code has
some ideas or wants to whip up a patch please jump right in.


Sorry for that.
Have you made progress?

I'm trying to add get_dev_path function to virtio-pci-bus in 
virtio-pci.c as Paolo suggests.


How do you get those instance_id to check It's working?

Fred

Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE] QEMU 1.5.0-rc2 is now available

[KONRAD Frédéric]

On 16/05/2013 16:51, Paolo Bonzini wrote:

Il 16/05/2013 16:21, mdroth ha scritto:

commit e37da3945fa2fde161e1b217f937fc318c4b7639
Author: KONRAD Frederic 
Date:   Thu Apr 11 16:29:58 2013 +0200

 virtio-net-pci: switch to the new API.
 
 Here the virtio-net-pci is modified for the new API. The device

 virtio-net-pci extends virtio-pci. It creates and connects a
 virtio-net-device during the init. The properties are not changed.
 
 Signed-off-by: KONRAD Frederic 

 Tested-by: Cornelia Huck 
 Message-id: 1365690602-22729-4-git-send-email-fred.kon...@greensocs.com
 Signed-off-by: Anthony Liguori 

And if we roll that back, we have similar failures for virtio-blk, and most
likely the other virtio devices touched by the refactoring.

The issue seems to be a change the way section id strings are generated in
vmstate_register(). In v1.4.x we had:

se->instance_id: 0, se->idstr: :00:03.0/virtio-net

In v1.5.0-rc2 we have:

se->instance_id: 0, se->idstr: virtio-net

This seems to be due to the fact that these devices now sit on a
TYPE_VIRTIO_BUS that has no implementation of TYPE_BUS's get_dev_path()
interface, which is what savevm uses to calculate the id prefix for
se->idstr.

Prior to the refactoring, the device sat on a TYPE_PCI_BUS which used
pcibus_get_dev_path() to calculate this.

I'm not sure what the best fix is for this. I looking at implementing
get_dev_path() for TYPE_VIRTIO_BUS, but to maintain migration
compatibility we'd end up baking in PCI-specific stuff which from what
I gather is exactly what we were trying to avoid there.

I think get_dev_path for TYPE_VIRTIO_BUS could simply forward to the
parent device's parent bus.

Paolo


I think this can do the job, any better idea?

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index d5257ed..e033b53 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -43,7 +43,6 @@
 #endif

 static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
-static char *pcibus_get_dev_path(DeviceState *dev);
 static char *pcibus_get_fw_dev_path(DeviceState *dev);
 static int pcibus_reset(BusState *qbus);

@@ -2129,7 +2128,7 @@ static char *pcibus_get_fw_dev_path(DeviceState *dev)
 return g_strdup(path);
 }

-static char *pcibus_get_dev_path(DeviceState *dev)
+char *pcibus_get_dev_path(DeviceState *dev)
 {
 PCIDevice *d = container_of(dev, PCIDevice, qdev);
 PCIDevice *t;
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 70d2c6b..0241223 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1514,11 +1514,19 @@ static void virtio_pci_bus_new(VirtioBusState 
*bus, VirtIOPCIProxy *dev)

 qbus->allow_hotplug = 1;
 }

+static char *virtio_pci_bus_get_dev_path(DeviceState *dev)
+{
+BusState *bus = qdev_get_parent_bus(dev);
+DeviceState *proxy = DEVICE(bus->parent);
+return g_strdup(pcibus_get_dev_path(proxy));
+}
+
 static void virtio_pci_bus_class_init(ObjectClass *klass, void *data)
 {
 BusClass *bus_class = BUS_CLASS(klass);
 VirtioBusClass *k = VIRTIO_BUS_CLASS(klass);
 bus_class->max_dev = 1;
+bus_class->get_dev_path = virtio_pci_bus_get_dev_path;
 k->notify = virtio_pci_notify;
 k->save_config = virtio_pci_save_config;
 k->load_config = virtio_pci_load_config;
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 8d075ab..fb5723c 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -708,6 +708,8 @@ static inline void pci_dma_sglist_init(QEMUSGList 
*qsg, PCIDevice *dev,


 extern const VMStateDescription vmstate_pci_device;

+char *pcibus_get_dev_path(DeviceState *dev);
+
 #define VMSTATE_PCI_DEVICE(_field, _state) { \
 .name   = (stringify(_field)),   \
 .size   = sizeof(PCIDevice), \
--
1.7.11.7

Re: [Qemu-devel] [ANNOUNCE] QEMU 1.5.0-rc2 is now available

[KONRAD Frédéric]

On 16/05/2013 18:07, Paolo Bonzini wrote:

Il 16/05/2013 17:54, KONRAD Frédéric ha scritto:

I think this can do the job, any better idea?

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index d5257ed..e033b53 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -43,7 +43,6 @@
  #endif

  static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
-static char *pcibus_get_dev_path(DeviceState *dev);
  static char *pcibus_get_fw_dev_path(DeviceState *dev);
  static int pcibus_reset(BusState *qbus);

@@ -2129,7 +2128,7 @@ static char *pcibus_get_fw_dev_path(DeviceState *dev)
  return g_strdup(path);
  }

-static char *pcibus_get_dev_path(DeviceState *dev)
+char *pcibus_get_dev_path(DeviceState *dev)
  {
  PCIDevice *d = container_of(dev, PCIDevice, qdev);
  PCIDevice *t;
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 70d2c6b..0241223 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1514,11 +1514,19 @@ static void virtio_pci_bus_new(VirtioBusState
*bus, VirtIOPCIProxy *dev)
  qbus->allow_hotplug = 1;
  }

+static char *virtio_pci_bus_get_dev_path(DeviceState *dev)
+{
+BusState *bus = qdev_get_parent_bus(dev);
+DeviceState *proxy = DEVICE(bus->parent);
+return g_strdup(pcibus_get_dev_path(proxy));

You do not need to export pcibus_get_dev_path.  This should just return
qdev_get_dev_path(proxy) and should be in TYPE_VIRTIO_BUS, not in the
PCI-specific subclass.

(The g_strdup is not needed, either).

Paolo


True, I avoided it because of CCW and S390, but as they don't have there 
get_dev_path, it seems

not to change anything for them.

I think that's better and I get :00:04.0/virtio-net for idstr.

diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index aab72ff..ea2e11a 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -154,12 +154,26 @@ void virtio_bus_set_vdev_config(VirtioBusState 
*bus, uint8_t *config)

 }
 }

+static char *virtio_bus_get_dev_path(DeviceState *dev)
+{
+BusState *bus = qdev_get_parent_bus(dev);
+DeviceState *proxy = DEVICE(bus->parent);
+return qdev_get_dev_path(proxy);
+}
+
+static void virtio_bus_class_init(ObjectClass *klass, void *data)
+{
+BusClass *bus_class = BUS_CLASS(klass);
+bus_class->get_dev_path = virtio_bus_get_dev_path;
+}
+
 static const TypeInfo virtio_bus_info = {
 .name = TYPE_VIRTIO_BUS,
 .parent = TYPE_BUS,
 .instance_size = sizeof(VirtioBusState),
 .abstract = true,
 .class_size = sizeof(VirtioBusClass),
+.class_init = virtio_bus_class_init
 };

 static void virtio_register_types(void)
--
1.7.11.7

Re: [Qemu-devel] [ANNOUNCE] QEMU 1.5.0-rc2 is now available

[KONRAD Frédéric]

On 16/05/2013 18:33, Anthony Liguori wrote:

KONRAD Frédéric  writes:


On 16/05/2013 16:51, Paolo Bonzini wrote:

Il 16/05/2013 16:21, mdroth ha scritto:

commit e37da3945fa2fde161e1b217f937fc318c4b7639
Author: KONRAD Frederic 
Date:   Thu Apr 11 16:29:58 2013 +0200

  virtio-net-pci: switch to the new API.
  
  Here the virtio-net-pci is modified for the new API. The device

  virtio-net-pci extends virtio-pci. It creates and connects a
  virtio-net-device during the init. The properties are not changed.
  
  Signed-off-by: KONRAD Frederic 

  Tested-by: Cornelia Huck 
  Message-id: 1365690602-22729-4-git-send-email-fred.kon...@greensocs.com
  Signed-off-by: Anthony Liguori 

And if we roll that back, we have similar failures for virtio-blk, and most
likely the other virtio devices touched by the refactoring.

The issue seems to be a change the way section id strings are generated in
vmstate_register(). In v1.4.x we had:

se->instance_id: 0, se->idstr: :00:03.0/virtio-net

In v1.5.0-rc2 we have:

se->instance_id: 0, se->idstr: virtio-net

This seems to be due to the fact that these devices now sit on a
TYPE_VIRTIO_BUS that has no implementation of TYPE_BUS's get_dev_path()
interface, which is what savevm uses to calculate the id prefix for
se->idstr.

Prior to the refactoring, the device sat on a TYPE_PCI_BUS which used
pcibus_get_dev_path() to calculate this.

I'm not sure what the best fix is for this. I looking at implementing
get_dev_path() for TYPE_VIRTIO_BUS, but to maintain migration
compatibility we'd end up baking in PCI-specific stuff which from what
I gather is exactly what we were trying to avoid there.

I think get_dev_path for TYPE_VIRTIO_BUS could simply forward to the
parent device's parent bus.

Paolo

I think this can do the job, any better idea?

Monkey patching is a little ugly but it is a concise way of fixing the
problem.

Mike, can you confirm the patch?

Fred, can you add a Signed-off-by and send as a top-level?

Regards,

Anthony Liguori


I just send a better way.



diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index d5257ed..e033b53 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -43,7 +43,6 @@
   #endif

   static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
-static char *pcibus_get_dev_path(DeviceState *dev);
   static char *pcibus_get_fw_dev_path(DeviceState *dev);
   static int pcibus_reset(BusState *qbus);

@@ -2129,7 +2128,7 @@ static char *pcibus_get_fw_dev_path(DeviceState *dev)
   return g_strdup(path);
   }

-static char *pcibus_get_dev_path(DeviceState *dev)
+char *pcibus_get_dev_path(DeviceState *dev)
   {
   PCIDevice *d = container_of(dev, PCIDevice, qdev);
   PCIDevice *t;
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 70d2c6b..0241223 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1514,11 +1514,19 @@ static void virtio_pci_bus_new(VirtioBusState
*bus, VirtIOPCIProxy *dev)
   qbus->allow_hotplug = 1;
   }

+static char *virtio_pci_bus_get_dev_path(DeviceState *dev)
+{
+BusState *bus = qdev_get_parent_bus(dev);
+DeviceState *proxy = DEVICE(bus->parent);
+return g_strdup(pcibus_get_dev_path(proxy));
+}
+
   static void virtio_pci_bus_class_init(ObjectClass *klass, void *data)
   {
   BusClass *bus_class = BUS_CLASS(klass);
   VirtioBusClass *k = VIRTIO_BUS_CLASS(klass);
   bus_class->max_dev = 1;
+bus_class->get_dev_path = virtio_pci_bus_get_dev_path;
   k->notify = virtio_pci_notify;
   k->save_config = virtio_pci_save_config;
   k->load_config = virtio_pci_load_config;
diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index 8d075ab..fb5723c 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -708,6 +708,8 @@ static inline void pci_dma_sglist_init(QEMUSGList
*qsg, PCIDevice *dev,

   extern const VMStateDescription vmstate_pci_device;

+char *pcibus_get_dev_path(DeviceState *dev);
+
   #define VMSTATE_PCI_DEVICE(_field, _state) { \
   .name   = (stringify(_field)),   \
   .size   = sizeof(PCIDevice), \
--
1.7.11.7

Re: [Qemu-devel] [ANNOUNCE] QEMU 1.5.0-rc2 is now available

[KONRAD Frédéric]

On 16/05/2013 18:49, mdroth wrote:

On Thu, May 16, 2013 at 06:34:09PM +0200, KONRAD Frédéric wrote:

On 16/05/2013 18:07, Paolo Bonzini wrote:

Il 16/05/2013 17:54, KONRAD Frédéric ha scritto:

I think this can do the job, any better idea?

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index d5257ed..e033b53 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -43,7 +43,6 @@
  #endif

  static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
-static char *pcibus_get_dev_path(DeviceState *dev);
  static char *pcibus_get_fw_dev_path(DeviceState *dev);
  static int pcibus_reset(BusState *qbus);

@@ -2129,7 +2128,7 @@ static char *pcibus_get_fw_dev_path(DeviceState *dev)
  return g_strdup(path);
  }

-static char *pcibus_get_dev_path(DeviceState *dev)
+char *pcibus_get_dev_path(DeviceState *dev)
  {
  PCIDevice *d = container_of(dev, PCIDevice, qdev);
  PCIDevice *t;
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 70d2c6b..0241223 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1514,11 +1514,19 @@ static void virtio_pci_bus_new(VirtioBusState
*bus, VirtIOPCIProxy *dev)
  qbus->allow_hotplug = 1;
  }

+static char *virtio_pci_bus_get_dev_path(DeviceState *dev)
+{
+BusState *bus = qdev_get_parent_bus(dev);
+DeviceState *proxy = DEVICE(bus->parent);
+return g_strdup(pcibus_get_dev_path(proxy));

You do not need to export pcibus_get_dev_path.  This should just return
qdev_get_dev_path(proxy) and should be in TYPE_VIRTIO_BUS, not in the
PCI-specific subclass.

(The g_strdup is not needed, either).

Paolo

True, I avoided it because of CCW and S390, but as they don't have
there get_dev_path, it seems
not to change anything for them.

I think that's better and I get :00:04.0/virtio-net for idstr.

Sorry, my email seems to be malfunctioning this morning and I didn't see
this before sending mine. Not sure which one is better but I'll be happy
to test whatever we decide on.


Well, seems our patches are sent at the same moment.

diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index aab72ff..ea2e11a 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -154,12 +154,26 @@ void virtio_bus_set_vdev_config(VirtioBusState
*bus, uint8_t *config)
  }
  }

+static char *virtio_bus_get_dev_path(DeviceState *dev)
+{
+BusState *bus = qdev_get_parent_bus(dev);
+DeviceState *proxy = DEVICE(bus->parent);
+return qdev_get_dev_path(proxy);
+}
+
+static void virtio_bus_class_init(ObjectClass *klass, void *data)
+{
+BusClass *bus_class = BUS_CLASS(klass);
+bus_class->get_dev_path = virtio_bus_get_dev_path;
+}
+
  static const TypeInfo virtio_bus_info = {
  .name = TYPE_VIRTIO_BUS,
  .parent = TYPE_BUS,
  .instance_size = sizeof(VirtioBusState),
  .abstract = true,
  .class_size = sizeof(VirtioBusClass),
+.class_init = virtio_bus_class_init
  };

  static void virtio_register_types(void)
--
1.7.11.7

Re: [Qemu-devel] [RFC] reverse execution.

[KONRAD Frédéric]

On 09/05/2013 19:54, Blue Swirl wrote:

On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric
 wrote:

Hi,

We are trying to find a way to do reverse execution happen with QEMU.

Actually, it is possible to debug the guest through the gdbstub, we want to
make the reverse execution possible with GDB as well.

How we are trying to make that working (basically without optimisation):

-QEMU takes regular snapshot of the VM:
that can be done with the save vm code without optimisation first.

-When the VM is stopped and GDB requests a reverse-step:
load the last snapshot and replay to one instruction before the current
PC.

There are one issue with that for now (for a basic running reverse
execution):
 -How to stop one instruction before the actual PC.

Add a special translation mode for reverse execution where the next PC
is checked after each instruction. Alternatively, you could make
temporary snapshots during this mode (first 1s intervals, then 0.1s
etc) which could be used to find the location. I think this way was
discussed briefly earlier in the list, please check the archives.



Hi, thanks for your answer!

I didn't find the discussion in the archive.. Do you have a clue? (Title 
or sender?)


For now we tried some other things which are not working very well,

It appeared that the replay is not deterministic even with icount:
- the whole icount mechanism is not saved with save_vm (which can 
be achieved by moving qemu_icount to TimerState according to Paolo)
- replaying two times the same thing and stopping at a specific 
breakpoint show two differents vmclock, so replaying the

same amount of time don't work, and we abandoned this idea.

We tried to count the amount of time tcg_qemu_tb_exec exited with having 
executed some TB and we stopped one before for the replay.

This is nearly working but:
- tcg_qemu_tb_exec exits a little more time during the first 
replay, seems the TB linked list is split dynamically?
- this works with the next replay (reverse-stepi) but we can't stop 
at the exact PC instruction with this method.


So we will try to add an instruction counter in the CPUState and 
increments it after each instruction in the translation code,

which I think is approximately what you suggest.
Then when replaying the code from the snapshot, we will check the amount 
of executed instruction and stop one instruction before.
Maybe we can re-use icount mechanism but this might be a lot more 
complicated as it is a de-counter?


Can this be working?

Maybe we will need to trace the PC from the snapshot to the exact 
location? Or use both mechanism to get the right location?


Thanks,
Fred


We though that using "-icount" and stop the guest a little time before the
actual position would give us the right behavior (We use a qemu_timer with
vm_clock to stop the vm at the good time), but it seems that it is not
deterministic, and not reproducable.

Is that normal?

We don't make any input during the replay, and we though that it can be
caused
by some timer interruption but "-icount" is using a virtual timer as I
understand?

We have two other ideas:

 -Using TCI and count each instruction executed by the processor, then
stop
 one instruction before the actual position. This seems slower.

 -Using single-step to count each instruction, then stop one instruction
 before the actual position.

Would that be better?

For now we can restore the VM from the last snapshot, when we do a
reverse-step
but we can't stop at the exact position.

Thanks,
Fred

Re: [Qemu-devel] [RFC] reverse execution.

[KONRAD Frédéric]

On 18/05/2013 20:52, Blue Swirl wrote:

On Fri, May 17, 2013 at 5:23 PM, KONRAD Frédéric
 wrote:

On 09/05/2013 19:54, Blue Swirl wrote:

On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric
 wrote:

Hi,

We are trying to find a way to do reverse execution happen with QEMU.

Actually, it is possible to debug the guest through the gdbstub, we want
to
make the reverse execution possible with GDB as well.

How we are trying to make that working (basically without optimisation):

-QEMU takes regular snapshot of the VM:
 that can be done with the save vm code without optimisation first.

-When the VM is stopped and GDB requests a reverse-step:
 load the last snapshot and replay to one instruction before the
current
PC.

There are one issue with that for now (for a basic running reverse
execution):
  -How to stop one instruction before the actual PC.

Add a special translation mode for reverse execution where the next PC
is checked after each instruction. Alternatively, you could make
temporary snapshots during this mode (first 1s intervals, then 0.1s
etc) which could be used to find the location. I think this way was
discussed briefly earlier in the list, please check the archives.


Hi, thanks for your answer!

I didn't find the discussion in the archive.. Do you have a clue? (Title or
sender?)

Paul Brook (long time QEMU developer) made a paper about this together
with Daniel Jacobowitz:
http://www.linuxsymposium.org/archives/GCC/Reprints-2007/jacobowitz-reprint.pdf

IIRC Paul also mentioned some techniques on the list at that time but
I couldn't find that in the archives.

Other related discussions:
http://article.gmane.org/gmane.comp.emulators.qemu/88447
http://article.gmane.org/gmane.comp.emulators.qemu/94861
http://article.gmane.org/gmane.comp.emulators.qemu/154572

Also this site contains some overview of reverse debugging:
http://jakob.engbloms.se/archives/1554



Thanks for your help :).

For now we tried some other things which are not working very well,

It appeared that the replay is not deterministic even with icount:
 - the whole icount mechanism is not saved with save_vm (which can be
achieved by moving qemu_icount to TimerState according to Paolo)
 - replaying two times the same thing and stopping at a specific
breakpoint show two differents vmclock, so replaying the
 same amount of time don't work, and we abandoned this idea.

We tried to count the amount of time tcg_qemu_tb_exec exited with having
executed some TB and we stopped one before for the replay.
This is nearly working but:
 - tcg_qemu_tb_exec exits a little more time during the first replay,
seems the TB linked list is split dynamically?
 - this works with the next replay (reverse-stepi) but we can't stop at
the exact PC instruction with this method.

So we will try to add an instruction counter in the CPUState and increments
it after each instruction in the translation code,
which I think is approximately what you suggest.
Then when replaying the code from the snapshot, we will check the amount of
executed instruction and stop one instruction before.
Maybe we can re-use icount mechanism but this might be a lot more
complicated as it is a de-counter?

Can this be working?

Maybe we will need to trace the PC from the snapshot to the exact location?

That should be easy, but not the fastest way.


Or use both mechanism to get the right location?

Yes, you could load VM from previous snapshot and then use icount or
just host timer to get approximately halfway. Make a new snapshot and
then try again, starting from that snapshot. When you get close
enough, singlestep to the final instruction.


Well, finally we plan to do approximately this way:

We added a translation block counter, which is incremented by TCG code
the same way as icount, and raise a debug exception when we are at the
right location.

Unfortunately this is not sufficient in term of precision, we can jump 
back 1 TB.


We have two choices:
a/ keep this "executed translation block" counter and "step by 
step" go to the right location.
b/ transform this counter in a "executed instruction" counter like 
icount and do

"step by step" execution when we are replaying.

The first is a bit difficult, as we don't have the exact PC location 
where to stop, and the second can

be really slow (I don't have performance measure at the moment).

Maybe we can try mixing both: replaying to the start of the right TB, 
then step by step going to the

right PC.

Fred

Thanks,
Fred



We though that using "-icount" and stop the guest a little time before
the
actual position would give us the right behavior (We use a qemu_timer
with
vm_clock to stop the vm at the good time), but it seems that it is not
deterministic, and not reproducable.

Is that normal?

We don't make any input during the replay, and we though that it can be
caused
by some timer interrup

[Qemu-devel] Virtio refactoring.

[KONRAD Frédéric]

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

Re: [Qemu-devel] Virtio refactoring.

[KONRAD Frédéric]

On 13/11/2012 16:32, Cornelia Huck wrote:

On Tue, 13 Nov 2012 15:27:57 +0100
KONRAD Frédéric  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--xxx)

to

system bus
-> virtio transport bridge dev (virtio-bridge-xxx)
-> virtio bus (virtio-bus-xxx)
   -> virtio dev (virtio--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).

Re: [Qemu-devel] Virtio refactoring.

[KONRAD Frédéric]

Hi,

On 13/11/2012 19:09, Cornelia Huck wrote:

On Tue, 13 Nov 2012 17:31:40 +0100
KONRAD Frédéric  wrote:


We'd go from

system bus
-> virtio transport bridge dev (virtio-xxx-bridge)
 -> virtio transport bus (virtio-xxx-bus)
-> virtio transport dev (virtio--xxx)

to

system bus
-> virtio transport bridge dev (virtio-bridge-xxx)
 -> virtio bus (virtio-bus-xxx)
-> virtio dev (virtio--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-- or virtio-.


So it would break the alias, we must find a solution for that.

Fred

Re: [Qemu-devel] [RFC PATCH 1/3] virtio-bus : Introduce VirtioBus.

[KONRAD Frédéric]

On 20/11/2012 15:12, Cornelia Huck wrote:

On Mon, 19 Nov 2012 17:33:01 +
Peter Maydell  wrote:


On 16 November 2012 15:35,   wrote:

From: KONRAD Frederic 

You forgot to CC enough people...


This patch create a new VirtioBus, which can be added to Virtio transports like
virtio-pci, virtio-mmio,...

One VirtIODevice can be connected to this device, like virtio-blk in the 3rd
patch.

The VirtioBus shares through a VirtioBusInfo structure :

 * two callbacks with the transport : init_cb and exit_cb, which must be
   called by the VirtIODevice, after the initialization and before the
   destruction, to put the right PCI IDs and/or stop the event fd.

Can we specify the general purpose of the {init,exit}_cb a bit better?
Is it analogous to any of the functions performed by the transport
busses today?
For example, look at the function static int 
virtio_blk_init_pci(PCIDevice *pci_dev) in virtio-pci.c,


it creates the VirtIODevice and then call virtio_init_pci(proxy, vdev);

It is what I tryed to reproduce, and abstract it from the new device.

eg : for the new virtio-blk I add, in the function static int 
virtio_blk_qdev_init(DeviceState *qdev) in virtio-blk.c :


it creates the VirtIODevice, create the virtiobus and call the 
virtio_bus_init_cb(bus, vdev)

 which call the virtio_init_pci callback when virtio-pci bridge is used.

it is the same thing for the exit.

Is it making sense ?




 * a VirtIOBindings structure.

Signed-off-by: KONRAD Frederic 
---
  hw/Makefile.objs |   1 +
  hw/virtio-bus.c  | 111 +++
  hw/virtio-bus.h  |  49 
  3 files changed, 161 insertions(+)
  create mode 100644 hw/virtio-bus.c
  create mode 100644 hw/virtio-bus.h

diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index af4ab0c..1b25d77 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -1,6 +1,7 @@
  common-obj-y = usb/ ide/
  common-obj-y += loader.o
  common-obj-$(CONFIG_VIRTIO) += virtio-console.o
+common-obj-$(CONFIG_VIRTIO) += virtio-bus.o
  common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
  common-obj-y += fw_cfg.o
  common-obj-$(CONFIG_PCI) += pci.o pci_bridge.o pci_bridge_dev.o
diff --git a/hw/virtio-bus.c b/hw/virtio-bus.c
new file mode 100644
index 000..b2e7e9c
--- /dev/null
+++ b/hw/virtio-bus.c
@@ -0,0 +1,111 @@
+/*
+ * VirtioBus
+ *
+ *  Copyright (C) 2012 : GreenSocs Ltd
+ *  http://www.greensocs.com/ , email: i...@greensocs.com
+ *
+ *  Developed by :
+ *  Frederic Konrad   
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.

Unless you copied this code from an existing v2-only file, preferred
license for new code is v2-or-any-later-version.


+ */
+
+#include "hw.h"
+#include "qemu-error.h"
+#include "qdev.h"
+#include "virtio-bus.h"
+#include "virtio.h"
+
+#define DEBUG_VIRTIO_BUS
+
+#ifdef DEBUG_VIRTIO_BUS
+
+#define DPRINTF(fmt, ...) \
+do { printf("virtio_bus: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+static char *virtio_bus_get_fw_dev_path(DeviceState *dev);

Is this function necessary? I think your implementation
is doing the same as the default.


+static void virtio_bus_class_init(ObjectClass *klass, void *data)
+{
+BusClass *k = BUS_CLASS(klass);
+k->get_fw_dev_path = virtio_bus_get_fw_dev_path;
+}
+
+static const TypeInfo virtio_bus_info = {
+.name = TYPE_VIRTIO_BUS,
+.parent = TYPE_BUS,
+.instance_size = sizeof(VirtioBus),
+.class_init = virtio_bus_class_init,
+};
+
+/* VirtioBus */
+
+static int next_virtio_bus;
+
+/* Create a virtio bus, and attach to transport.  */
+void virtio_bus_new(VirtioBus *bus, DeviceState *host,
+const VirtioBusInfo *info)
+{
+/*
+ * Setting name to NULL return always "virtio.0"
+ * as bus name in info qtree.
+ */
+char *bus_name = g_strdup_printf("%s.%d", BUS_NAME, next_virtio_bus);
+qbus_create_inplace(&bus->qbus, TYPE_VIRTIO_BUS, host, bus_name);
+bus->busnr = next_virtio_bus++;

This looks suspicious to me -- is keeping a count of the global
bus number really the right way to do this?

If we want an unique number, we need to track usage of numbers, else we
end up with duplicates on wraparound.
I put that because the number was all identical in "info qtree", is it 
the right thing to do ?



+bus->info = info;
+/* no hotplug for the moment ? */
+bus->qbus.allow_hotplug = 0;

Correct -- we don't need to hotplug the virtio backend.


+bus->bus_in_use = false;
+DPRINTF("bus %s created\n", bus_name);
+}
+
+/* Bind the VirtIODevice to the VirtioBus. */
+void virtio_bus_bind_device(VirtioBus *bus)
+{
+assert(bus != NULL);
+assert(bus->vdev != NULL);
+virtio_bind_device(bus->vdev, &(bus->info->virtio_bindings),
+   bus->qbus.parent);

This looks wrong -- virtio_bind_device() is part of the
old-style transport API.

Re: [Qemu-devel] [RFC PATCH 1/3] virtio-bus : Introduce VirtioBus.

[KONRAD Frédéric]

On 20/11/2012 17:15, Cornelia Huck wrote:

On Tue, 20 Nov 2012 15:30:35 +0100
KONRAD Frédéric  wrote:


On 20/11/2012 15:12, Cornelia Huck wrote:

On Mon, 19 Nov 2012 17:33:01 +
Peter Maydell  wrote:


On 16 November 2012 15:35,   wrote:

From: KONRAD Frederic 

You forgot to CC enough people...


This patch create a new VirtioBus, which can be added to Virtio transports like
virtio-pci, virtio-mmio,...

One VirtIODevice can be connected to this device, like virtio-blk in the 3rd
patch.

The VirtioBus shares through a VirtioBusInfo structure :

  * two callbacks with the transport : init_cb and exit_cb, which must be
called by the VirtIODevice, after the initialization and before the
destruction, to put the right PCI IDs and/or stop the event fd.

Can we specify the general purpose of the {init,exit}_cb a bit better?
Is it analogous to any of the functions performed by the transport
busses today?

For example, look at the function static int
virtio_blk_init_pci(PCIDevice *pci_dev) in virtio-pci.c,

it creates the VirtIODevice and then call virtio_init_pci(proxy, vdev);

It is what I tryed to reproduce, and abstract it from the new device.

eg : for the new virtio-blk I add, in the function static int
virtio_blk_qdev_init(DeviceState *qdev) in virtio-blk.c :

it creates the VirtIODevice, create the virtiobus and call the
virtio_bus_init_cb(bus, vdev)
   which call the virtio_init_pci callback when virtio-pci bridge is used.

it is the same thing for the exit.

Is it making sense ?

Yes, I think I understand. It would probably make sense to add a
comment like "transport specific, device type independent
initialization" or so.

Ok, good idea I'll add that.


  * a VirtIOBindings structure.

Signed-off-by: KONRAD Frederic 
---
   hw/Makefile.objs |   1 +
   hw/virtio-bus.c  | 111 
+++
   hw/virtio-bus.h  |  49 
   3 files changed, 161 insertions(+)
   create mode 100644 hw/virtio-bus.c
   create mode 100644 hw/virtio-bus.h

diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index af4ab0c..1b25d77 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -1,6 +1,7 @@
   common-obj-y = usb/ ide/
   common-obj-y += loader.o
   common-obj-$(CONFIG_VIRTIO) += virtio-console.o
+common-obj-$(CONFIG_VIRTIO) += virtio-bus.o
   common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
   common-obj-y += fw_cfg.o
   common-obj-$(CONFIG_PCI) += pci.o pci_bridge.o pci_bridge_dev.o
diff --git a/hw/virtio-bus.c b/hw/virtio-bus.c
new file mode 100644
index 000..b2e7e9c
--- /dev/null
+++ b/hw/virtio-bus.c
@@ -0,0 +1,111 @@
+/*
+ * VirtioBus
+ *
+ *  Copyright (C) 2012 : GreenSocs Ltd
+ *  http://www.greensocs.com/ , email: i...@greensocs.com
+ *
+ *  Developed by :
+ *  Frederic Konrad   
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.

Unless you copied this code from an existing v2-only file, preferred
license for new code is v2-or-any-later-version.


+ */
+
+#include "hw.h"
+#include "qemu-error.h"
+#include "qdev.h"
+#include "virtio-bus.h"
+#include "virtio.h"
+
+#define DEBUG_VIRTIO_BUS
+
+#ifdef DEBUG_VIRTIO_BUS
+
+#define DPRINTF(fmt, ...) \
+do { printf("virtio_bus: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+static char *virtio_bus_get_fw_dev_path(DeviceState *dev);

Is this function necessary? I think your implementation
is doing the same as the default.


+static void virtio_bus_class_init(ObjectClass *klass, void *data)
+{
+BusClass *k = BUS_CLASS(klass);
+k->get_fw_dev_path = virtio_bus_get_fw_dev_path;
+}
+
+static const TypeInfo virtio_bus_info = {
+.name = TYPE_VIRTIO_BUS,
+.parent = TYPE_BUS,
+.instance_size = sizeof(VirtioBus),
+.class_init = virtio_bus_class_init,
+};
+
+/* VirtioBus */
+
+static int next_virtio_bus;
+
+/* Create a virtio bus, and attach to transport.  */
+void virtio_bus_new(VirtioBus *bus, DeviceState *host,
+const VirtioBusInfo *info)
+{
+/*
+ * Setting name to NULL return always "virtio.0"
+ * as bus name in info qtree.
+ */
+char *bus_name = g_strdup_printf("%s.%d", BUS_NAME, next_virtio_bus);
+qbus_create_inplace(&bus->qbus, TYPE_VIRTIO_BUS, host, bus_name);
+bus->busnr = next_virtio_bus++;

This looks suspicious to me -- is keeping a count of the global
bus number really the right way to do this?

If we want an unique number, we need to track usage of numbers, else we
end up with duplicates on wraparound.

I put that because the number was all identical in "info qtree", is it
the right thing to do ?

Not sure whether we need a unique name for each bus as each proxy
device will have only one bus beneath it - but if we need it, it must
stay unique when hot(un)plugging d

Re: [Qemu-devel] [RFC PATCH 1/3] virtio-bus : Introduce VirtioBus.

[KONRAD Frédéric]

On 19/11/2012 18:33, Peter Maydell wrote:

On 16 November 2012 15:35,   wrote:

From: KONRAD Frederic 

You forgot to CC enough people...


This patch create a new VirtioBus, which can be added to Virtio transports like
virtio-pci, virtio-mmio,...

One VirtIODevice can be connected to this device, like virtio-blk in the 3rd
patch.

The VirtioBus shares through a VirtioBusInfo structure :

 * two callbacks with the transport : init_cb and exit_cb, which must be
   called by the VirtIODevice, after the initialization and before the
   destruction, to put the right PCI IDs and/or stop the event fd.

 * a VirtIOBindings structure.

Signed-off-by: KONRAD Frederic 
---
  hw/Makefile.objs |   1 +
  hw/virtio-bus.c  | 111 +++
  hw/virtio-bus.h  |  49 
  3 files changed, 161 insertions(+)
  create mode 100644 hw/virtio-bus.c
  create mode 100644 hw/virtio-bus.h

diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index af4ab0c..1b25d77 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -1,6 +1,7 @@
  common-obj-y = usb/ ide/
  common-obj-y += loader.o
  common-obj-$(CONFIG_VIRTIO) += virtio-console.o
+common-obj-$(CONFIG_VIRTIO) += virtio-bus.o
  common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
  common-obj-y += fw_cfg.o
  common-obj-$(CONFIG_PCI) += pci.o pci_bridge.o pci_bridge_dev.o
diff --git a/hw/virtio-bus.c b/hw/virtio-bus.c
new file mode 100644
index 000..b2e7e9c
--- /dev/null
+++ b/hw/virtio-bus.c
@@ -0,0 +1,111 @@
+/*
+ * VirtioBus
+ *
+ *  Copyright (C) 2012 : GreenSocs Ltd
+ *  http://www.greensocs.com/ , email: i...@greensocs.com
+ *
+ *  Developed by :
+ *  Frederic Konrad   
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.

Unless you copied this code from an existing v2-only file, preferred
license for new code is v2-or-any-later-version.


+ */
+
+#include "hw.h"
+#include "qemu-error.h"
+#include "qdev.h"
+#include "virtio-bus.h"
+#include "virtio.h"
+
+#define DEBUG_VIRTIO_BUS
+
+#ifdef DEBUG_VIRTIO_BUS
+
+#define DPRINTF(fmt, ...) \
+do { printf("virtio_bus: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+static char *virtio_bus_get_fw_dev_path(DeviceState *dev);

Is this function necessary? I think your implementation
is doing the same as the default.


+static void virtio_bus_class_init(ObjectClass *klass, void *data)
+{
+BusClass *k = BUS_CLASS(klass);
+k->get_fw_dev_path = virtio_bus_get_fw_dev_path;
+}
+
+static const TypeInfo virtio_bus_info = {
+.name = TYPE_VIRTIO_BUS,
+.parent = TYPE_BUS,
+.instance_size = sizeof(VirtioBus),
+.class_init = virtio_bus_class_init,
+};
+
+/* VirtioBus */
+
+static int next_virtio_bus;
+
+/* Create a virtio bus, and attach to transport.  */
+void virtio_bus_new(VirtioBus *bus, DeviceState *host,
+const VirtioBusInfo *info)
+{
+/*
+ * Setting name to NULL return always "virtio.0"
+ * as bus name in info qtree.
+ */
+char *bus_name = g_strdup_printf("%s.%d", BUS_NAME, next_virtio_bus);
+qbus_create_inplace(&bus->qbus, TYPE_VIRTIO_BUS, host, bus_name);
+bus->busnr = next_virtio_bus++;

This looks suspicious to me -- is keeping a count of the global
bus number really the right way to do this?


+bus->info = info;
+/* no hotplug for the moment ? */
+bus->qbus.allow_hotplug = 0;

Correct -- we don't need to hotplug the virtio backend.


+bus->bus_in_use = false;
+DPRINTF("bus %s created\n", bus_name);
+}
+
+/* Bind the VirtIODevice to the VirtioBus. */
+void virtio_bus_bind_device(VirtioBus *bus)
+{
+assert(bus != NULL);
+assert(bus->vdev != NULL);
+virtio_bind_device(bus->vdev, &(bus->info->virtio_bindings),
+   bus->qbus.parent);

This looks wrong -- virtio_bind_device() is part of the
old-style transport API.
it is part of the virtiodevice API, I don't think It is a good idea to 
modify it ?



+}
+
+/* This must be called to when the VirtIODevice init */
+int virtio_bus_init_cb(VirtioBus *bus, VirtIODevice *vdev)
+{
+if (bus->bus_in_use == true) {
+error_report("%s in use.\n", bus->qbus.name);
+return -1;
+}
+assert(bus->info->init_cb != NULL);
+/* keep the VirtIODevice in the VirtioBus */
+bus->vdev = vdev;

This shouldn't be happening here, it should happen as
part of plugging the device into the bus.

What do you mean by plugging the device into the bus ?

I think that the device is already plugged when I call this function, I 
don't find an

other idea to set maximum device per bus to 1.




+bus->info->init_cb(bus->qbus.parent);
+
+bus->bus_in_use = true;
+return 0;
+}
+
+/* This must be called when the VirtIODevice exit */
+void virtio_bus_exit_cb(VirtioBus *bus)
+{
+assert(bus->info->exit_cb != NULL);
+bus->info->exit_cb(bus->qbus.parent);
+bus->

Re: [Qemu-devel] [RFC PATCH 1/3] virtio-bus : Introduce VirtioBus.

[KONRAD Frédéric]

On 21/11/2012 14:04, Andreas Färber wrote:

Am 16.11.2012 16:35, schrieb fred.kon...@greensocs.com:

From: KONRAD Frederic 

This patch create a new VirtioBus, which can be added to Virtio transports like
virtio-pci, virtio-mmio,...

One VirtIODevice can be connected to this device, like virtio-blk in the 3rd
patch.

The VirtioBus shares through a VirtioBusInfo structure :

 * two callbacks with the transport : init_cb and exit_cb, which must be
   called by the VirtIODevice, after the initialization and before the
   destruction, to put the right PCI IDs and/or stop the event fd.

 * a VirtIOBindings structure.

Signed-off-by: KONRAD Frederic 
---
  hw/Makefile.objs |   1 +
  hw/virtio-bus.c  | 111 +++
  hw/virtio-bus.h  |  49 
  3 files changed, 161 insertions(+)
  create mode 100644 hw/virtio-bus.c
  create mode 100644 hw/virtio-bus.h

diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index af4ab0c..1b25d77 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -1,6 +1,7 @@
  common-obj-y = usb/ ide/
  common-obj-y += loader.o
  common-obj-$(CONFIG_VIRTIO) += virtio-console.o
+common-obj-$(CONFIG_VIRTIO) += virtio-bus.o
  common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
  common-obj-y += fw_cfg.o
  common-obj-$(CONFIG_PCI) += pci.o pci_bridge.o pci_bridge_dev.o
diff --git a/hw/virtio-bus.c b/hw/virtio-bus.c
new file mode 100644
index 000..b2e7e9c
--- /dev/null
+++ b/hw/virtio-bus.c
@@ -0,0 +1,111 @@
+/*
+ * VirtioBus
+ *
+ *  Copyright (C) 2012 : GreenSocs Ltd
+ *  http://www.greensocs.com/ , email: i...@greensocs.com
+ *
+ *  Developed by :
+ *  Frederic Konrad   
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.

Any chance to use GPLv2 "or (at your option) any later version"? If not,
please mention in the commit message why.


Yes, I made the change.

+ */
+
+#include "hw.h"
+#include "qemu-error.h"
+#include "qdev.h"
+#include "virtio-bus.h"
+#include "virtio.h"
+
+#define DEBUG_VIRTIO_BUS
+
+#ifdef DEBUG_VIRTIO_BUS
+
+#define DPRINTF(fmt, ...) \
+do { printf("virtio_bus: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif

We recently had a discussion about bitrotting DPRINTF() statements where
I suggested to use if (0) instead of a no-op macro like this that
doesn't reference fmt and the varargs.

I don't understand what you suggested, can you point me to an example ?


+
+static char *virtio_bus_get_fw_dev_path(DeviceState *dev);
+
+static void virtio_bus_class_init(ObjectClass *klass, void *data)
+{
+BusClass *k = BUS_CLASS(klass);
+k->get_fw_dev_path = virtio_bus_get_fw_dev_path;
+}
+
+static const TypeInfo virtio_bus_info = {
+.name = TYPE_VIRTIO_BUS,
+.parent = TYPE_BUS,
+.instance_size = sizeof(VirtioBus),
+.class_init = virtio_bus_class_init,
+};
+
+/* VirtioBus */
+
+static int next_virtio_bus;
+
+/* Create a virtio bus, and attach to transport.  */
+void virtio_bus_new(VirtioBus *bus, DeviceState *host,
+const VirtioBusInfo *info)
+{
+/*
+ * Setting name to NULL return always "virtio.0"
+ * as bus name in info qtree.
+ */
+char *bus_name = g_strdup_printf("%s.%d", BUS_NAME, next_virtio_bus);
+qbus_create_inplace(&bus->qbus, TYPE_VIRTIO_BUS, host, bus_name);

Accessing the qbus field directly is considered old-style. Please use
the BUS() macro to cast to a new BusState* variable and pass that here...

Ok, I'll look.


+bus->busnr = next_virtio_bus++;
+bus->info = info;
+/* no hotplug for the moment ? */
+bus->qbus.allow_hotplug = 0;

...and access its fields through it. More cases below.


+bus->bus_in_use = false;
+DPRINTF("bus %s created\n", bus_name);
+}
+
+/* Bind the VirtIODevice to the VirtioBus. */
+void virtio_bus_bind_device(VirtioBus *bus)
+{
+assert(bus != NULL);
+assert(bus->vdev != NULL);
+virtio_bind_device(bus->vdev, &(bus->info->virtio_bindings),
+   bus->qbus.parent);
+}
+
+/* This must be called to when the VirtIODevice init */

"called when the ...Device inits" or "called during ...Device init"

oops sorry for that.


+int virtio_bus_init_cb(VirtioBus *bus, VirtIODevice *vdev)
+{
+if (bus->bus_in_use == true) {

Even if bus_in_use is of bool type, doing an explicit "true" comparison
is not a good idea in C since everything non-zero is to be considered
true, not just the "true" constant.

sure.

+error_report("%s in use.\n", bus->qbus.name);
+return -1;
+}
+assert(bus->info->init_cb != NULL);
+/* keep the VirtIODevice in the VirtioBus */
+bus->vdev = vdev;
+bus->info->init_cb(bus->qbus.parent);
+
+bus->bus_in_use = true;
+return 0;
+}
+
+/* This must be called when the VirtIODevice exit */

Similar grammar issue as above.


+void virtio_bus_exit_cb(VirtioBus *bus)
+{
+assert(bus->inf

Re: [Qemu-devel] [RFC PATCH 1/3] virtio-bus : Introduce VirtioBus.

[KONRAD Frédéric]

On 21/11/2012 15:13, Andreas Färber wrote:

Am 21.11.2012 15:05, schrieb KONRAD Frédéric:

On 21/11/2012 14:04, Andreas Färber wrote:

Am 16.11.2012 16:35, schrieb fred.kon...@greensocs.com:

+#define DEBUG_VIRTIO_BUS
+
+#ifdef DEBUG_VIRTIO_BUS
+
+#define DPRINTF(fmt, ...) \
+do { printf("virtio_bus: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif

We recently had a discussion about bitrotting DPRINTF() statements where
I suggested to use if (0) instead of a no-op macro like this that
doesn't reference fmt and the varargs.

I don't understand what you suggested, can you point me to an example ?

I don't have a link at hand, maybe Evgeny does. It was along the lines of:

#define DEBUG_VIRTIO_BUS 0

#define DPRINTF(fmt, ...) if (DEBUG_VIRTIO_BUS) { \
 printf("virtio_bus: " fmt , ## __VA_ARGS__); \
 }

The officially preferred alternative is to use tracepoints. ;)

Cheers,
Andreas


ok, thanks.

Fred

Re: [Qemu-devel] [RFC PATCH v2 0/3] Virtio-refactoring.

[KONRAD Frédéric]

Did you get the full patchset ? The 01 and 02 seems to be lost on
the mailing list. :s.

On 22/11/2012 16:08, Peter Maydell wrote:

On 22 November 2012 14:50,   wrote:

There are still two issues with the command line :

 * When I use ./qemu* -device virtio-blk -device virtio-pci
   It is said that no virtio-bus are present.

Does it work if you create the devices in the other order?

Yes the other order works.




 * The virtio-blk is plugged in the last created virtio-bus if no "bus="
   option is present. It's an issue as we can only plug one virtio-device.

Anthony said this might Just Work (ie that we should find the
first non-full bus rather than just the first one), and if it
doesn't work it should be fairly straightforward to make it work.

Yes, maybe it is implemented in the QOM ? Because when I use
qdev_get_parent_bus(qdev) in virtio_blk_qdev_init, it gives me
the last created Virtiobus.

Fred.