All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription
@ 2016-10-13 17:45 Stefan Weil
  2016-10-14  8:25 ` Dr. David Alan Gilbert
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Weil @ 2016-10-13 17:45 UTC (permalink / raw)
  To: QEMU Developer; +Cc: Jason Wang, Li Qiang, Stefan Weil

Instead of allocating a VMStateDescription for each NIC instance,
the code now uses a single constant VMStateDescription for all
instances. That implies that the name field is always the same.

Reported-by: Li Qiang <liqiang6-s@360.cn>
Signed-off-by: Stefan Weil <sw@weilnetz.de>
---
 hw/net/eepro100.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index bab4dbf..6f9777d 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -269,9 +269,6 @@ typedef struct {
     /* Configuration bytes. */
     uint8_t configuration[22];
 
-    /* vmstate for each particular nic */
-    VMStateDescription *vmstate;
-
     /* Quasi static device properties (no need to save them). */
     uint16_t stats_size;
     bool has_extended_tcb_support;
@@ -1787,7 +1784,8 @@ static ssize_t nic_receive(NetClientState *nc, const uint8_t * buf, size_t size)
     return size;
 }
 
-static const VMStateDescription vmstate_eepro100 = {
+static const VMStateDescription vmstate_e100 = {
+    .name = "e100",
     .version_id = 3,
     .minimum_version_id = 2,
     .fields = (VMStateField[]) {
@@ -1842,7 +1840,6 @@ static void pci_nic_uninit(PCIDevice *pci_dev)
 {
     EEPRO100State *s = DO_UPCAST(EEPRO100State, dev, pci_dev);
 
-    vmstate_unregister(&pci_dev->qdev, s->vmstate, s);
     eeprom93xx_free(&pci_dev->qdev, s->eeprom);
     qemu_del_nic(s->nic);
 }
@@ -1892,11 +1889,6 @@ static void e100_nic_realize(PCIDevice *pci_dev, Error **errp)
     TRACE(OTHER, logout("%s\n", qemu_get_queue(s->nic)->info_str));
 
     qemu_register_reset(nic_reset, s);
-
-    s->vmstate = g_malloc(sizeof(vmstate_eepro100));
-    memcpy(s->vmstate, &vmstate_eepro100, sizeof(vmstate_eepro100));
-    s->vmstate->name = qemu_get_queue(s->nic)->model;
-    vmstate_register(&pci_dev->qdev, -1, s->vmstate, s);
 }
 
 static void eepro100_instance_init(Object *obj)
@@ -2083,6 +2075,7 @@ static void eepro100_class_init(ObjectClass *klass, void *data)
     set_bit(DEVICE_CATEGORY_NETWORK, dc->categories);
     dc->props = e100_properties;
     dc->desc = info->desc;
+    dc->vmsd = &vmstate_e100;
     k->vendor_id = PCI_VENDOR_ID_INTEL;
     k->class_id = PCI_CLASS_NETWORK_ETHERNET;
     k->romfile = "pxe-eepro100.rom";
-- 
2.1.4

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription
  2016-10-13 17:45 [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription Stefan Weil
@ 2016-10-14  8:25 ` Dr. David Alan Gilbert
  2016-10-15  5:35   ` Stefan Weil
  0 siblings, 1 reply; 7+ messages in thread
From: Dr. David Alan Gilbert @ 2016-10-14  8:25 UTC (permalink / raw)
  To: Stefan Weil; +Cc: QEMU Developer, amit.shah, Jason Wang, Li Qiang

* Stefan Weil (sw@weilnetz.de) wrote:
> Instead of allocating a VMStateDescription for each NIC instance,
> the code now uses a single constant VMStateDescription for all
> instances. That implies that the name field is always the same.

Doesn't this break migration compatibility?

You might be able to get around that (in the forward direction only)
by adding an entry to qdev_alias_table but I'm not sure.

Dave

> Reported-by: Li Qiang <liqiang6-s@360.cn>
> Signed-off-by: Stefan Weil <sw@weilnetz.de>
> ---
>  hw/net/eepro100.c | 13 +++----------
>  1 file changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
> index bab4dbf..6f9777d 100644
> --- a/hw/net/eepro100.c
> +++ b/hw/net/eepro100.c
> @@ -269,9 +269,6 @@ typedef struct {
>      /* Configuration bytes. */
>      uint8_t configuration[22];
>  
> -    /* vmstate for each particular nic */
> -    VMStateDescription *vmstate;
> -
>      /* Quasi static device properties (no need to save them). */
>      uint16_t stats_size;
>      bool has_extended_tcb_support;
> @@ -1787,7 +1784,8 @@ static ssize_t nic_receive(NetClientState *nc, const uint8_t * buf, size_t size)
>      return size;
>  }
>  
> -static const VMStateDescription vmstate_eepro100 = {
> +static const VMStateDescription vmstate_e100 = {
> +    .name = "e100",
>      .version_id = 3,
>      .minimum_version_id = 2,
>      .fields = (VMStateField[]) {
> @@ -1842,7 +1840,6 @@ static void pci_nic_uninit(PCIDevice *pci_dev)
>  {
>      EEPRO100State *s = DO_UPCAST(EEPRO100State, dev, pci_dev);
>  
> -    vmstate_unregister(&pci_dev->qdev, s->vmstate, s);
>      eeprom93xx_free(&pci_dev->qdev, s->eeprom);
>      qemu_del_nic(s->nic);
>  }
> @@ -1892,11 +1889,6 @@ static void e100_nic_realize(PCIDevice *pci_dev, Error **errp)
>      TRACE(OTHER, logout("%s\n", qemu_get_queue(s->nic)->info_str));
>  
>      qemu_register_reset(nic_reset, s);
> -
> -    s->vmstate = g_malloc(sizeof(vmstate_eepro100));
> -    memcpy(s->vmstate, &vmstate_eepro100, sizeof(vmstate_eepro100));
> -    s->vmstate->name = qemu_get_queue(s->nic)->model;
> -    vmstate_register(&pci_dev->qdev, -1, s->vmstate, s);
>  }
>  
>  static void eepro100_instance_init(Object *obj)
> @@ -2083,6 +2075,7 @@ static void eepro100_class_init(ObjectClass *klass, void *data)
>      set_bit(DEVICE_CATEGORY_NETWORK, dc->categories);
>      dc->props = e100_properties;
>      dc->desc = info->desc;
> +    dc->vmsd = &vmstate_e100;
>      k->vendor_id = PCI_VENDOR_ID_INTEL;
>      k->class_id = PCI_CLASS_NETWORK_ETHERNET;
>      k->romfile = "pxe-eepro100.rom";
> -- 
> 2.1.4
> 
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription
  2016-10-14  8:25 ` Dr. David Alan Gilbert
@ 2016-10-15  5:35   ` Stefan Weil
  2016-10-17  9:01     ` Dr. David Alan Gilbert
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Weil @ 2016-10-15  5:35 UTC (permalink / raw)
  To: Dr. David Alan Gilbert
  Cc: QEMU Developer, amit.shah, Jason Wang, Li Qiang, Juan Quintela

On 10/14/16 10:25, Dr. David Alan Gilbert wrote:
> * Stefan Weil (sw@weilnetz.de) wrote:
>> Instead of allocating a VMStateDescription for each NIC instance,
>> the code now uses a single constant VMStateDescription for all
>> instances. That implies that the name field is always the same.
>
> Doesn't this break migration compatibility?
>
> You might be able to get around that (in the forward direction only)
> by adding an entry to qdev_alias_table but I'm not sure.
>
> Dave

I'm not an expert for migration (never used it myself).

Is migration compatibility a must, even for non default settings
like the NICs implemented by eepro100.c? I assume that applications
which use migration will usually run with an e1000 NIC.

Or can we break migration compatibility and add that information
to the release notes?

How does e1000 handle migration if QEMU was started with a
e1000-82544gc NIC and migrated to a e1000-82545em NIC?

Stefan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription
  2016-10-15  5:35   ` Stefan Weil
@ 2016-10-17  9:01     ` Dr. David Alan Gilbert
  2016-10-21  1:53       ` Jason Wang
  0 siblings, 1 reply; 7+ messages in thread
From: Dr. David Alan Gilbert @ 2016-10-17  9:01 UTC (permalink / raw)
  To: Stefan Weil
  Cc: QEMU Developer, amit.shah, Jason Wang, Li Qiang, Juan Quintela

* Stefan Weil (sw@weilnetz.de) wrote:
> On 10/14/16 10:25, Dr. David Alan Gilbert wrote:
> > * Stefan Weil (sw@weilnetz.de) wrote:
> > > Instead of allocating a VMStateDescription for each NIC instance,
> > > the code now uses a single constant VMStateDescription for all
> > > instances. That implies that the name field is always the same.
> > 
> > Doesn't this break migration compatibility?
> > 
> > You might be able to get around that (in the forward direction only)
> > by adding an entry to qdev_alias_table but I'm not sure.
> > 
> > Dave
> 
> I'm not an expert for migration (never used it myself).
> 
> Is migration compatibility a must, even for non default settings
> like the NICs implemented by eepro100.c? I assume that applications
> which use migration will usually run with an e1000 NIC.
> 
> Or can we break migration compatibility and add that information
> to the release notes?

We normally keep migration compatibility for all devices
in the forward direction unless it's something really obscure;
I don't think an e100 is.

> How does e1000 handle migration if QEMU was started with a
> e1000-82544gc NIC and migrated to a e1000-82545em NIC?

That's not required to work; you're required to have the same device
configuration on the destination as the source.

$ qemu-system-x86_64 -nographic -device e1000-82544gc
(qemu) migrate "exec:cat > t.mig"

$ qemu-system-x86_64 -nographic -device e1000-82545em -incoming "exec:cat t.mig"
qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x2 read: c device: f cmask: ff wmask: 0 w1cmask:0
qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/e1000'
qemu-system-x86_64: load of migration failed: Invalid argument

Now, note that what's happening here is that e1000 is doing a similar
trick to what you're doing - i.e. all devices end up getting
migrated as 'e1000' in the device string (0000:00:04.0/e1000).

The scheme you end up with is OK, but the problem is it's just
different from what we have now, so existing streams
with device names like '0000:00:04.0/i82550' won't load.

Dave

> 
> Stefan
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription
  2016-10-17  9:01     ` Dr. David Alan Gilbert
@ 2016-10-21  1:53       ` Jason Wang
  2016-10-21  8:06         ` Dr. David Alan Gilbert
  0 siblings, 1 reply; 7+ messages in thread
From: Jason Wang @ 2016-10-21  1:53 UTC (permalink / raw)
  To: Dr. David Alan Gilbert, Stefan Weil
  Cc: QEMU Developer, amit.shah, Li Qiang, Juan Quintela



On 2016年10月17日 17:01, Dr. David Alan Gilbert wrote:
> * Stefan Weil (sw@weilnetz.de) wrote:
>> On 10/14/16 10:25, Dr. David Alan Gilbert wrote:
>>> * Stefan Weil (sw@weilnetz.de) wrote:
>>>> Instead of allocating a VMStateDescription for each NIC instance,
>>>> the code now uses a single constant VMStateDescription for all
>>>> instances. That implies that the name field is always the same.
>>> Doesn't this break migration compatibility?
>>>
>>> You might be able to get around that (in the forward direction only)
>>> by adding an entry to qdev_alias_table but I'm not sure.
>>>
>>> Dave
>> I'm not an expert for migration (never used it myself).
>>
>> Is migration compatibility a must, even for non default settings
>> like the NICs implemented by eepro100.c? I assume that applications
>> which use migration will usually run with an e1000 NIC.
>>
>> Or can we break migration compatibility and add that information
>> to the release notes?
> We normally keep migration compatibility for all devices
> in the forward direction unless it's something really obscure;
> I don't think an e100 is.
>
>> How does e1000 handle migration if QEMU was started with a
>> e1000-82544gc NIC and migrated to a e1000-82545em NIC?
> That's not required to work; you're required to have the same device
> configuration on the destination as the source.
>
> $ qemu-system-x86_64 -nographic -device e1000-82544gc
> (qemu) migrate "exec:cat > t.mig"
>
> $ qemu-system-x86_64 -nographic -device e1000-82545em -incoming "exec:cat t.mig"
> qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x2 read: c device: f cmask: ff wmask: 0 w1cmask:0
> qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/e1000'
> qemu-system-x86_64: load of migration failed: Invalid argument
>
> Now, note that what's happening here is that e1000 is doing a similar
> trick to what you're doing - i.e. all devices end up getting
> migrated as 'e1000' in the device string (0000:00:04.0/e1000).
>
> The scheme you end up with is OK, but the problem is it's just
> different from what we have now, so existing streams
> with device names like '0000:00:04.0/i82550' won't load.
>
> Dave
>

Can we bump the version here? Or just use v1 for the fixing.

Thanks

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription
  2016-10-21  1:53       ` Jason Wang
@ 2016-10-21  8:06         ` Dr. David Alan Gilbert
  2016-10-21 19:25           ` Stefan Weil
  0 siblings, 1 reply; 7+ messages in thread
From: Dr. David Alan Gilbert @ 2016-10-21  8:06 UTC (permalink / raw)
  To: Jason Wang
  Cc: Stefan Weil, QEMU Developer, amit.shah, Li Qiang, Juan Quintela

* Jason Wang (jasowang@redhat.com) wrote:
> 
> 
> On 2016年10月17日 17:01, Dr. David Alan Gilbert wrote:
> > * Stefan Weil (sw@weilnetz.de) wrote:
> > > On 10/14/16 10:25, Dr. David Alan Gilbert wrote:
> > > > * Stefan Weil (sw@weilnetz.de) wrote:
> > > > > Instead of allocating a VMStateDescription for each NIC instance,
> > > > > the code now uses a single constant VMStateDescription for all
> > > > > instances. That implies that the name field is always the same.
> > > > Doesn't this break migration compatibility?
> > > > 
> > > > You might be able to get around that (in the forward direction only)
> > > > by adding an entry to qdev_alias_table but I'm not sure.
> > > > 
> > > > Dave
> > > I'm not an expert for migration (never used it myself).
> > > 
> > > Is migration compatibility a must, even for non default settings
> > > like the NICs implemented by eepro100.c? I assume that applications
> > > which use migration will usually run with an e1000 NIC.
> > > 
> > > Or can we break migration compatibility and add that information
> > > to the release notes?
> > We normally keep migration compatibility for all devices
> > in the forward direction unless it's something really obscure;
> > I don't think an e100 is.
> > 
> > > How does e1000 handle migration if QEMU was started with a
> > > e1000-82544gc NIC and migrated to a e1000-82545em NIC?
> > That's not required to work; you're required to have the same device
> > configuration on the destination as the source.
> > 
> > $ qemu-system-x86_64 -nographic -device e1000-82544gc
> > (qemu) migrate "exec:cat > t.mig"
> > 
> > $ qemu-system-x86_64 -nographic -device e1000-82545em -incoming "exec:cat t.mig"
> > qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x2 read: c device: f cmask: ff wmask: 0 w1cmask:0
> > qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/e1000'
> > qemu-system-x86_64: load of migration failed: Invalid argument
> > 
> > Now, note that what's happening here is that e1000 is doing a similar
> > trick to what you're doing - i.e. all devices end up getting
> > migrated as 'e1000' in the device string (0000:00:04.0/e1000).
> > 
> > The scheme you end up with is OK, but the problem is it's just
> > different from what we have now, so existing streams
> > with device names like '0000:00:04.0/i82550' won't load.
> > 
> > Dave
> > 
> 
> Can we bump the version here? Or just use v1 for the fixing.

The problem isn't the version of the contents of the section, it's
the naming of the devices.
I think you can work around it by adding aliases for the old names.

Dave

> Thanks
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription
  2016-10-21  8:06         ` Dr. David Alan Gilbert
@ 2016-10-21 19:25           ` Stefan Weil
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Weil @ 2016-10-21 19:25 UTC (permalink / raw)
  To: Dr. David Alan Gilbert
  Cc: Jason Wang, QEMU Developer, amit.shah, Li Qiang, Juan Quintela

Am 21.10.2016 um 10:06 schrieb Dr. David Alan Gilbert:

> The problem isn't the version of the contents of the section, it's
> the naming of the devices.
> I think you can work around it by adding aliases for the old names.
>
> Dave

How should I add such aliases? Are there other devices
with vmstate aliases, so I can see how it is done?

Stefan

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2016-10-21 19:25 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-13 17:45 [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription Stefan Weil
2016-10-14  8:25 ` Dr. David Alan Gilbert
2016-10-15  5:35   ` Stefan Weil
2016-10-17  9:01     ` Dr. David Alan Gilbert
2016-10-21  1:53       ` Jason Wang
2016-10-21  8:06         ` Dr. David Alan Gilbert
2016-10-21 19:25           ` Stefan Weil

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.