Re: [RFC 2/2] virtio-net: use post load hook
On Fri, Oct 11, 2019 at 12:34:59PM +0200, Mikhail Sennikovsky wrote:
> I still wonder though if this approach is really cleaner than my
> original one of having an extra argument in set_features callback,
> saying whether the device settings (offloads in case of virtio-net)
> need to be reset.
>
> Mikhail
I prefer this approach as I think it's generally a saner
way to restore the device state: first the virtio core,
then the device specific state.
We should consider not invoking set features callback
during load at all: its real purpose is to validate
the features, the _nocheck variant makes no sense to me.
But that's a bigger change.
>
> Am Fr., 11. Okt. 2019 um 12:30 Uhr schrieb Mikhail Sennikovsky
> :
> >
> > Am Fr., 11. Okt. 2019 um 12:08 Uhr schrieb Michael S. Tsirkin
> > :
> > >...
> > > And pre save hook can do n->saved_guest_offloads = n->curr_guest_offloads.
> > Would you want to have the saved_guest_offloads as part of the saved state?
> > The curr_guest_offloads info is already there, so why would you want
> > to duplicate that?
> > Wouldn't it be better to just do n->saved_guest_offloads =
> > n->curr_guest_offloads in virtio_net_post_load_device,
> > and then do
> > n->curr_guest_offloads = n->saved_guest_offloads;
> > if (peer_has_vnet_hdr(n)) {
> > virtio_net_apply_guest_offloads(n);
> > in the new post load hook (virtio_net_post_load_virtio) exactly like you
> > say?
> >
> > Mikhail
> >
> > >
> > >
> > > On Fri, Oct 11, 2019 at 11:58:38AM +0200, Mikhail Sennikovsky wrote:
> > > > Note that the virtio_net_set_features gets also called from the
> > > > virtio_pci_common_write when guest does virtio device configuration.
> > > > In that case the curr_guest_offloads are still expected to be reset.
> > > >
> > > > Mikhail
> > > >
> > > > Am Fr., 11. Okt. 2019 um 11:51 Uhr schrieb Michael S. Tsirkin
> > > > :
> > > > >
> > > > > On Fri, Oct 11, 2019 at 11:46:22AM +0200, Mikhail Sennikovsky wrote:
> > > > > > Hi Michael,
> > > > > >
> > > > > > Unfortunately your approach will not work, because the
> > > > > > VirtIONet::curr_guest_offloads would still be reset in
> > > > > > virtio_net_set_features:
> > > > > > --
> > > > > > if (n->has_vnet_hdr) {
> > > > > > n->curr_guest_offloads =
> > > > > > virtio_net_guest_offloads_by_features(features);
> > > > >
> > > > > So let's move that part to the new hook too.
> > > > >
> > > > > > --
> > > > > > ( https://github.com/qemu/qemu/blob/master/hw/net/virtio-net.c#L774
> > > > > > )
> > > > > >
> > > > > > I.e. although virtio_net_apply_guest_offloads would now be called
> > > > > > after the virtio_net_set_features, by the time it is called the
> > > > > > VirtIONet::curr_guest_offloads would be reset to a full list of
> > > > > > features.
> > > > > >
> > > > > > Regards,
> > > > > > Mikhail
> > > > > >
> > > > > > Am Do., 10. Okt. 2019 um 20:04 Uhr schrieb Michael S. Tsirkin
> > > > > > :
> > > > > > >
> > > > > > > Currently offloads disabled by guest via the
> > > > > > > VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
> > > > > > > command are not preserved on VM migration.
> > > > > > > Instead all offloads reported by guest features (via
> > > > > > > VIRTIO_PCI_GUEST_FEATURES)
> > > > > > > get enabled.
> > > > > > > What happens is: first the VirtIONet::curr_guest_offloads gets
> > > > > > > restored
> > > > > > > and offloads are getting set correctly:
> > > > > > >
> > > > > > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=0, tso6=0,
> > > > > > > ecn=0, ufo=0) at net/net.c:474
> > > > > > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > > > > > hw/net/virtio-net.c:720
> > > > > > > #2 virtio_net_post_load_device (opaque=0x57701ca0,
> > > > > > > version_id=11) at hw/net/virtio-net.c:2334
> > > > > > > #3 vmstate_load_state (f=0x569dc010, vmsd=0x56577c80
> > > > > > > , opaque=0x57701ca0, version_id=11)
> > > > > > > at migration/vmstate.c:168
> > > > > > > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010,
> > > > > > > version_id=11) at hw/virtio/virtio.c:2197
> > > > > > > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0,
> > > > > > > size=0, field=0x5668cd00 <__compound_literal.5>) at
> > > > > > > hw/virtio/virtio.c:2036
> > > > > > > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > > > > > > , opaque=0x57701ca0, version_id=11) at
> > > > > > > migration/vmstate.c:143
> > > > > > > #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> > > > > > > migration/savevm.c:829
> > > > > > > #8 qemu_loadvm_section_start_full (f=0x569dc010,
> > > > > > > mis=0x569eee20) at migration/savevm.c:2211
> > > > > > > #9 qemu_loadvm_state_main (f=0x569dc010,
> > > > > > > mis=0x569eee20) at migration/savevm.c:2395
> > > > > > > #10 qemu_loadvm_state (f=0x569dc010) at
> > > > > > > migration/savevm.c:2467
> > > > > > > #11 process_incoming_migration_co (opaque=0x0) at
> > > > > >
Re: [RFC 2/2] virtio-net: use post load hook
On Fri, Oct 11, 2019 at 12:30:07PM +0200, Mikhail Sennikovsky wrote:
> Am Fr., 11. Okt. 2019 um 12:08 Uhr schrieb Michael S. Tsirkin
> :
> >...
> > And pre save hook can do n->saved_guest_offloads = n->curr_guest_offloads.
> Would you want to have the saved_guest_offloads as part of the saved state?
> The curr_guest_offloads info is already there, so why would you want
> to duplicate that?
> Wouldn't it be better to just do n->saved_guest_offloads =
> n->curr_guest_offloads in virtio_net_post_load_device,
> and then do
> n->curr_guest_offloads = n->saved_guest_offloads;
> if (peer_has_vnet_hdr(n)) {
> virtio_net_apply_guest_offloads(n);
> in the new post load hook (virtio_net_post_load_virtio) exactly like you say?
>
> Mikhail
Fine by me, too.
> >
> >
> > On Fri, Oct 11, 2019 at 11:58:38AM +0200, Mikhail Sennikovsky wrote:
> > > Note that the virtio_net_set_features gets also called from the
> > > virtio_pci_common_write when guest does virtio device configuration.
> > > In that case the curr_guest_offloads are still expected to be reset.
> > >
> > > Mikhail
> > >
> > > Am Fr., 11. Okt. 2019 um 11:51 Uhr schrieb Michael S. Tsirkin
> > > :
> > > >
> > > > On Fri, Oct 11, 2019 at 11:46:22AM +0200, Mikhail Sennikovsky wrote:
> > > > > Hi Michael,
> > > > >
> > > > > Unfortunately your approach will not work, because the
> > > > > VirtIONet::curr_guest_offloads would still be reset in
> > > > > virtio_net_set_features:
> > > > > --
> > > > > if (n->has_vnet_hdr) {
> > > > > n->curr_guest_offloads =
> > > > > virtio_net_guest_offloads_by_features(features);
> > > >
> > > > So let's move that part to the new hook too.
> > > >
> > > > > --
> > > > > ( https://github.com/qemu/qemu/blob/master/hw/net/virtio-net.c#L774 )
> > > > >
> > > > > I.e. although virtio_net_apply_guest_offloads would now be called
> > > > > after the virtio_net_set_features, by the time it is called the
> > > > > VirtIONet::curr_guest_offloads would be reset to a full list of
> > > > > features.
> > > > >
> > > > > Regards,
> > > > > Mikhail
> > > > >
> > > > > Am Do., 10. Okt. 2019 um 20:04 Uhr schrieb Michael S. Tsirkin
> > > > > :
> > > > > >
> > > > > > Currently offloads disabled by guest via the
> > > > > > VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
> > > > > > command are not preserved on VM migration.
> > > > > > Instead all offloads reported by guest features (via
> > > > > > VIRTIO_PCI_GUEST_FEATURES)
> > > > > > get enabled.
> > > > > > What happens is: first the VirtIONet::curr_guest_offloads gets
> > > > > > restored
> > > > > > and offloads are getting set correctly:
> > > > > >
> > > > > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=0, tso6=0,
> > > > > > ecn=0, ufo=0) at net/net.c:474
> > > > > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > > > > hw/net/virtio-net.c:720
> > > > > > #2 virtio_net_post_load_device (opaque=0x57701ca0,
> > > > > > version_id=11) at hw/net/virtio-net.c:2334
> > > > > > #3 vmstate_load_state (f=0x569dc010, vmsd=0x56577c80
> > > > > > , opaque=0x57701ca0, version_id=11)
> > > > > > at migration/vmstate.c:168
> > > > > > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010,
> > > > > > version_id=11) at hw/virtio/virtio.c:2197
> > > > > > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0,
> > > > > > size=0, field=0x5668cd00 <__compound_literal.5>) at
> > > > > > hw/virtio/virtio.c:2036
> > > > > > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > > > > > , opaque=0x57701ca0, version_id=11) at
> > > > > > migration/vmstate.c:143
> > > > > > #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> > > > > > migration/savevm.c:829
> > > > > > #8 qemu_loadvm_section_start_full (f=0x569dc010,
> > > > > > mis=0x569eee20) at migration/savevm.c:2211
> > > > > > #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20)
> > > > > > at migration/savevm.c:2395
> > > > > > #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> > > > > > #11 process_incoming_migration_co (opaque=0x0) at
> > > > > > migration/migration.c:449
> > > > > >
> > > > > > However later on the features are getting restored, and offloads
> > > > > > get reset to
> > > > > > everything supported by features:
> > > > > >
> > > > > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=1, tso6=1,
> > > > > > ecn=0, ufo=0) at net/net.c:474
> > > > > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > > > > hw/net/virtio-net.c:720
> > > > > > #2 virtio_net_set_features (vdev=0x57701ca0,
> > > > > > features=5104441767) at hw/net/virtio-net.c:773
> > > > > > #3 virtio_set_features_nocheck (vdev=0x57701ca0,
> > > > > > val=5104441767) at hw/virtio/virtio.c:2052
> > > > > > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010,
> > > > > > version_id=11) at hw/virtio/virtio.c:2220
> > > > > > #5 virtio_device_get (f=0x569dc010,
Re: [RFC 2/2] virtio-net: use post load hook
I still wonder though if this approach is really cleaner than my
original one of having an extra argument in set_features callback,
saying whether the device settings (offloads in case of virtio-net)
need to be reset.
Mikhail
Am Fr., 11. Okt. 2019 um 12:30 Uhr schrieb Mikhail Sennikovsky
:
>
> Am Fr., 11. Okt. 2019 um 12:08 Uhr schrieb Michael S. Tsirkin
> :
> >...
> > And pre save hook can do n->saved_guest_offloads = n->curr_guest_offloads.
> Would you want to have the saved_guest_offloads as part of the saved state?
> The curr_guest_offloads info is already there, so why would you want
> to duplicate that?
> Wouldn't it be better to just do n->saved_guest_offloads =
> n->curr_guest_offloads in virtio_net_post_load_device,
> and then do
> n->curr_guest_offloads = n->saved_guest_offloads;
> if (peer_has_vnet_hdr(n)) {
> virtio_net_apply_guest_offloads(n);
> in the new post load hook (virtio_net_post_load_virtio) exactly like you say?
>
> Mikhail
>
> >
> >
> > On Fri, Oct 11, 2019 at 11:58:38AM +0200, Mikhail Sennikovsky wrote:
> > > Note that the virtio_net_set_features gets also called from the
> > > virtio_pci_common_write when guest does virtio device configuration.
> > > In that case the curr_guest_offloads are still expected to be reset.
> > >
> > > Mikhail
> > >
> > > Am Fr., 11. Okt. 2019 um 11:51 Uhr schrieb Michael S. Tsirkin
> > > :
> > > >
> > > > On Fri, Oct 11, 2019 at 11:46:22AM +0200, Mikhail Sennikovsky wrote:
> > > > > Hi Michael,
> > > > >
> > > > > Unfortunately your approach will not work, because the
> > > > > VirtIONet::curr_guest_offloads would still be reset in
> > > > > virtio_net_set_features:
> > > > > --
> > > > > if (n->has_vnet_hdr) {
> > > > > n->curr_guest_offloads =
> > > > > virtio_net_guest_offloads_by_features(features);
> > > >
> > > > So let's move that part to the new hook too.
> > > >
> > > > > --
> > > > > ( https://github.com/qemu/qemu/blob/master/hw/net/virtio-net.c#L774 )
> > > > >
> > > > > I.e. although virtio_net_apply_guest_offloads would now be called
> > > > > after the virtio_net_set_features, by the time it is called the
> > > > > VirtIONet::curr_guest_offloads would be reset to a full list of
> > > > > features.
> > > > >
> > > > > Regards,
> > > > > Mikhail
> > > > >
> > > > > Am Do., 10. Okt. 2019 um 20:04 Uhr schrieb Michael S. Tsirkin
> > > > > :
> > > > > >
> > > > > > Currently offloads disabled by guest via the
> > > > > > VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
> > > > > > command are not preserved on VM migration.
> > > > > > Instead all offloads reported by guest features (via
> > > > > > VIRTIO_PCI_GUEST_FEATURES)
> > > > > > get enabled.
> > > > > > What happens is: first the VirtIONet::curr_guest_offloads gets
> > > > > > restored
> > > > > > and offloads are getting set correctly:
> > > > > >
> > > > > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=0, tso6=0,
> > > > > > ecn=0, ufo=0) at net/net.c:474
> > > > > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > > > > hw/net/virtio-net.c:720
> > > > > > #2 virtio_net_post_load_device (opaque=0x57701ca0,
> > > > > > version_id=11) at hw/net/virtio-net.c:2334
> > > > > > #3 vmstate_load_state (f=0x569dc010, vmsd=0x56577c80
> > > > > > , opaque=0x57701ca0, version_id=11)
> > > > > > at migration/vmstate.c:168
> > > > > > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010,
> > > > > > version_id=11) at hw/virtio/virtio.c:2197
> > > > > > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0,
> > > > > > size=0, field=0x5668cd00 <__compound_literal.5>) at
> > > > > > hw/virtio/virtio.c:2036
> > > > > > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > > > > > , opaque=0x57701ca0, version_id=11) at
> > > > > > migration/vmstate.c:143
> > > > > > #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> > > > > > migration/savevm.c:829
> > > > > > #8 qemu_loadvm_section_start_full (f=0x569dc010,
> > > > > > mis=0x569eee20) at migration/savevm.c:2211
> > > > > > #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20)
> > > > > > at migration/savevm.c:2395
> > > > > > #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> > > > > > #11 process_incoming_migration_co (opaque=0x0) at
> > > > > > migration/migration.c:449
> > > > > >
> > > > > > However later on the features are getting restored, and offloads
> > > > > > get reset to
> > > > > > everything supported by features:
> > > > > >
> > > > > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=1, tso6=1,
> > > > > > ecn=0, ufo=0) at net/net.c:474
> > > > > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > > > > hw/net/virtio-net.c:720
> > > > > > #2 virtio_net_set_features (vdev=0x57701ca0,
> > > > > > features=5104441767) at hw/net/virtio-net.c:773
> > > > > > #3 virtio_set_features_nocheck (vdev=0x57701ca0,
> > > > > >
Re: [RFC 2/2] virtio-net: use post load hook
Am Fr., 11. Okt. 2019 um 12:08 Uhr schrieb Michael S. Tsirkin :
>...
> And pre save hook can do n->saved_guest_offloads = n->curr_guest_offloads.
Would you want to have the saved_guest_offloads as part of the saved state?
The curr_guest_offloads info is already there, so why would you want
to duplicate that?
Wouldn't it be better to just do n->saved_guest_offloads =
n->curr_guest_offloads in virtio_net_post_load_device,
and then do
n->curr_guest_offloads = n->saved_guest_offloads;
if (peer_has_vnet_hdr(n)) {
virtio_net_apply_guest_offloads(n);
in the new post load hook (virtio_net_post_load_virtio) exactly like you say?
Mikhail
>
>
> On Fri, Oct 11, 2019 at 11:58:38AM +0200, Mikhail Sennikovsky wrote:
> > Note that the virtio_net_set_features gets also called from the
> > virtio_pci_common_write when guest does virtio device configuration.
> > In that case the curr_guest_offloads are still expected to be reset.
> >
> > Mikhail
> >
> > Am Fr., 11. Okt. 2019 um 11:51 Uhr schrieb Michael S. Tsirkin
> > :
> > >
> > > On Fri, Oct 11, 2019 at 11:46:22AM +0200, Mikhail Sennikovsky wrote:
> > > > Hi Michael,
> > > >
> > > > Unfortunately your approach will not work, because the
> > > > VirtIONet::curr_guest_offloads would still be reset in
> > > > virtio_net_set_features:
> > > > --
> > > > if (n->has_vnet_hdr) {
> > > > n->curr_guest_offloads =
> > > > virtio_net_guest_offloads_by_features(features);
> > >
> > > So let's move that part to the new hook too.
> > >
> > > > --
> > > > ( https://github.com/qemu/qemu/blob/master/hw/net/virtio-net.c#L774 )
> > > >
> > > > I.e. although virtio_net_apply_guest_offloads would now be called
> > > > after the virtio_net_set_features, by the time it is called the
> > > > VirtIONet::curr_guest_offloads would be reset to a full list of
> > > > features.
> > > >
> > > > Regards,
> > > > Mikhail
> > > >
> > > > Am Do., 10. Okt. 2019 um 20:04 Uhr schrieb Michael S. Tsirkin
> > > > :
> > > > >
> > > > > Currently offloads disabled by guest via the
> > > > > VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
> > > > > command are not preserved on VM migration.
> > > > > Instead all offloads reported by guest features (via
> > > > > VIRTIO_PCI_GUEST_FEATURES)
> > > > > get enabled.
> > > > > What happens is: first the VirtIONet::curr_guest_offloads gets
> > > > > restored
> > > > > and offloads are getting set correctly:
> > > > >
> > > > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=0, tso6=0,
> > > > > ecn=0, ufo=0) at net/net.c:474
> > > > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > > > hw/net/virtio-net.c:720
> > > > > #2 virtio_net_post_load_device (opaque=0x57701ca0,
> > > > > version_id=11) at hw/net/virtio-net.c:2334
> > > > > #3 vmstate_load_state (f=0x569dc010, vmsd=0x56577c80
> > > > > , opaque=0x57701ca0, version_id=11)
> > > > > at migration/vmstate.c:168
> > > > > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010,
> > > > > version_id=11) at hw/virtio/virtio.c:2197
> > > > > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0,
> > > > > size=0, field=0x5668cd00 <__compound_literal.5>) at
> > > > > hw/virtio/virtio.c:2036
> > > > > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > > > > , opaque=0x57701ca0, version_id=11) at
> > > > > migration/vmstate.c:143
> > > > > #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> > > > > migration/savevm.c:829
> > > > > #8 qemu_loadvm_section_start_full (f=0x569dc010,
> > > > > mis=0x569eee20) at migration/savevm.c:2211
> > > > > #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
> > > > > migration/savevm.c:2395
> > > > > #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> > > > > #11 process_incoming_migration_co (opaque=0x0) at
> > > > > migration/migration.c:449
> > > > >
> > > > > However later on the features are getting restored, and offloads get
> > > > > reset to
> > > > > everything supported by features:
> > > > >
> > > > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=1, tso6=1,
> > > > > ecn=0, ufo=0) at net/net.c:474
> > > > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > > > hw/net/virtio-net.c:720
> > > > > #2 virtio_net_set_features (vdev=0x57701ca0,
> > > > > features=5104441767) at hw/net/virtio-net.c:773
> > > > > #3 virtio_set_features_nocheck (vdev=0x57701ca0,
> > > > > val=5104441767) at hw/virtio/virtio.c:2052
> > > > > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010,
> > > > > version_id=11) at hw/virtio/virtio.c:2220
> > > > > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0,
> > > > > size=0, field=0x5668cd00 <__compound_literal.5>) at
> > > > > hw/virtio/virtio.c:2036
> > > > > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > > > > , opaque=0x57701ca0, version_id=11) at
> > > > > migration/vmstate.c:143
> > > > > #7
Re: [RFC 2/2] virtio-net: use post load hook
Ugh. Okay.
So let's add a new field saved_guest_offloads and have
vmstate use that instead of curr_guest_offloads.
Now the new post load hook can do
n->curr_guest_offloads = n->saved_guest_offloads
and apply that.
And pre save hook can do n->saved_guest_offloads = n->curr_guest_offloads.
On Fri, Oct 11, 2019 at 11:58:38AM +0200, Mikhail Sennikovsky wrote:
> Note that the virtio_net_set_features gets also called from the
> virtio_pci_common_write when guest does virtio device configuration.
> In that case the curr_guest_offloads are still expected to be reset.
>
> Mikhail
>
> Am Fr., 11. Okt. 2019 um 11:51 Uhr schrieb Michael S. Tsirkin
> :
> >
> > On Fri, Oct 11, 2019 at 11:46:22AM +0200, Mikhail Sennikovsky wrote:
> > > Hi Michael,
> > >
> > > Unfortunately your approach will not work, because the
> > > VirtIONet::curr_guest_offloads would still be reset in
> > > virtio_net_set_features:
> > > --
> > > if (n->has_vnet_hdr) {
> > > n->curr_guest_offloads =
> > > virtio_net_guest_offloads_by_features(features);
> >
> > So let's move that part to the new hook too.
> >
> > > --
> > > ( https://github.com/qemu/qemu/blob/master/hw/net/virtio-net.c#L774 )
> > >
> > > I.e. although virtio_net_apply_guest_offloads would now be called
> > > after the virtio_net_set_features, by the time it is called the
> > > VirtIONet::curr_guest_offloads would be reset to a full list of
> > > features.
> > >
> > > Regards,
> > > Mikhail
> > >
> > > Am Do., 10. Okt. 2019 um 20:04 Uhr schrieb Michael S. Tsirkin
> > > :
> > > >
> > > > Currently offloads disabled by guest via the
> > > > VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
> > > > command are not preserved on VM migration.
> > > > Instead all offloads reported by guest features (via
> > > > VIRTIO_PCI_GUEST_FEATURES)
> > > > get enabled.
> > > > What happens is: first the VirtIONet::curr_guest_offloads gets restored
> > > > and offloads are getting set correctly:
> > > >
> > > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=0, tso6=0,
> > > > ecn=0, ufo=0) at net/net.c:474
> > > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > > hw/net/virtio-net.c:720
> > > > #2 virtio_net_post_load_device (opaque=0x57701ca0, version_id=11)
> > > > at hw/net/virtio-net.c:2334
> > > > #3 vmstate_load_state (f=0x569dc010, vmsd=0x56577c80
> > > > , opaque=0x57701ca0, version_id=11)
> > > > at migration/vmstate.c:168
> > > > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010, version_id=11)
> > > > at hw/virtio/virtio.c:2197
> > > > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0,
> > > > size=0, field=0x5668cd00 <__compound_literal.5>) at
> > > > hw/virtio/virtio.c:2036
> > > > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > > > , opaque=0x57701ca0, version_id=11) at
> > > > migration/vmstate.c:143
> > > > #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> > > > migration/savevm.c:829
> > > > #8 qemu_loadvm_section_start_full (f=0x569dc010,
> > > > mis=0x569eee20) at migration/savevm.c:2211
> > > > #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
> > > > migration/savevm.c:2395
> > > > #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> > > > #11 process_incoming_migration_co (opaque=0x0) at
> > > > migration/migration.c:449
> > > >
> > > > However later on the features are getting restored, and offloads get
> > > > reset to
> > > > everything supported by features:
> > > >
> > > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=1, tso6=1,
> > > > ecn=0, ufo=0) at net/net.c:474
> > > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > > hw/net/virtio-net.c:720
> > > > #2 virtio_net_set_features (vdev=0x57701ca0, features=5104441767)
> > > > at hw/net/virtio-net.c:773
> > > > #3 virtio_set_features_nocheck (vdev=0x57701ca0, val=5104441767)
> > > > at hw/virtio/virtio.c:2052
> > > > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010, version_id=11)
> > > > at hw/virtio/virtio.c:2220
> > > > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0,
> > > > size=0, field=0x5668cd00 <__compound_literal.5>) at
> > > > hw/virtio/virtio.c:2036
> > > > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > > > , opaque=0x57701ca0, version_id=11) at
> > > > migration/vmstate.c:143
> > > > #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> > > > migration/savevm.c:829
> > > > #8 qemu_loadvm_section_start_full (f=0x569dc010,
> > > > mis=0x569eee20) at migration/savevm.c:2211
> > > > #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
> > > > migration/savevm.c:2395
> > > > #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> > > > #11 process_incoming_migration_co (opaque=0x0) at
> > > > migration/migration.c:449
> > > >
> > > > Fix this by pushing out offload initialization to
Re: [RFC 2/2] virtio-net: use post load hook
Note that the virtio_net_set_features gets also called from the
virtio_pci_common_write when guest does virtio device configuration.
In that case the curr_guest_offloads are still expected to be reset.
Mikhail
Am Fr., 11. Okt. 2019 um 11:51 Uhr schrieb Michael S. Tsirkin :
>
> On Fri, Oct 11, 2019 at 11:46:22AM +0200, Mikhail Sennikovsky wrote:
> > Hi Michael,
> >
> > Unfortunately your approach will not work, because the
> > VirtIONet::curr_guest_offloads would still be reset in
> > virtio_net_set_features:
> > --
> > if (n->has_vnet_hdr) {
> > n->curr_guest_offloads =
> > virtio_net_guest_offloads_by_features(features);
>
> So let's move that part to the new hook too.
>
> > --
> > ( https://github.com/qemu/qemu/blob/master/hw/net/virtio-net.c#L774 )
> >
> > I.e. although virtio_net_apply_guest_offloads would now be called
> > after the virtio_net_set_features, by the time it is called the
> > VirtIONet::curr_guest_offloads would be reset to a full list of
> > features.
> >
> > Regards,
> > Mikhail
> >
> > Am Do., 10. Okt. 2019 um 20:04 Uhr schrieb Michael S. Tsirkin
> > :
> > >
> > > Currently offloads disabled by guest via the
> > > VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
> > > command are not preserved on VM migration.
> > > Instead all offloads reported by guest features (via
> > > VIRTIO_PCI_GUEST_FEATURES)
> > > get enabled.
> > > What happens is: first the VirtIONet::curr_guest_offloads gets restored
> > > and offloads are getting set correctly:
> > >
> > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=0, tso6=0, ecn=0,
> > > ufo=0) at net/net.c:474
> > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > hw/net/virtio-net.c:720
> > > #2 virtio_net_post_load_device (opaque=0x57701ca0, version_id=11)
> > > at hw/net/virtio-net.c:2334
> > > #3 vmstate_load_state (f=0x569dc010, vmsd=0x56577c80
> > > , opaque=0x57701ca0, version_id=11)
> > > at migration/vmstate.c:168
> > > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010, version_id=11)
> > > at hw/virtio/virtio.c:2197
> > > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0, size=0,
> > > field=0x5668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036
> > > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > > , opaque=0x57701ca0, version_id=11) at
> > > migration/vmstate.c:143
> > > #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> > > migration/savevm.c:829
> > > #8 qemu_loadvm_section_start_full (f=0x569dc010,
> > > mis=0x569eee20) at migration/savevm.c:2211
> > > #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
> > > migration/savevm.c:2395
> > > #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> > > #11 process_incoming_migration_co (opaque=0x0) at
> > > migration/migration.c:449
> > >
> > > However later on the features are getting restored, and offloads get
> > > reset to
> > > everything supported by features:
> > >
> > > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=1, tso6=1, ecn=0,
> > > ufo=0) at net/net.c:474
> > > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > > hw/net/virtio-net.c:720
> > > #2 virtio_net_set_features (vdev=0x57701ca0, features=5104441767)
> > > at hw/net/virtio-net.c:773
> > > #3 virtio_set_features_nocheck (vdev=0x57701ca0, val=5104441767) at
> > > hw/virtio/virtio.c:2052
> > > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010, version_id=11)
> > > at hw/virtio/virtio.c:2220
> > > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0, size=0,
> > > field=0x5668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036
> > > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > > , opaque=0x57701ca0, version_id=11) at
> > > migration/vmstate.c:143
> > > #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> > > migration/savevm.c:829
> > > #8 qemu_loadvm_section_start_full (f=0x569dc010,
> > > mis=0x569eee20) at migration/savevm.c:2211
> > > #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
> > > migration/savevm.c:2395
> > > #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> > > #11 process_incoming_migration_co (opaque=0x0) at
> > > migration/migration.c:449
> > >
> > > Fix this by pushing out offload initialization to the new post load hook.
> > >
> > > Reported-by: Mikhail Sennikovsky
> > > Signed-off-by: Michael S. Tsirkin
> > > ---
> > > hw/net/virtio-net.c | 14 ++
> > > 1 file changed, 10 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > > index 9f11422337..62fb858e2d 100644
> > > --- a/hw/net/virtio-net.c
> > > +++ b/hw/net/virtio-net.c
> > > @@ -2333,10 +2333,6 @@ static int virtio_net_post_load_device(void
> > > *opaque, int version_id)
> > > n->curr_guest_offloads = virtio_net_supported_guest_offloads(n);
> > >
Re: [RFC 2/2] virtio-net: use post load hook
On Fri, Oct 11, 2019 at 11:46:22AM +0200, Mikhail Sennikovsky wrote:
> Hi Michael,
>
> Unfortunately your approach will not work, because the
> VirtIONet::curr_guest_offloads would still be reset in
> virtio_net_set_features:
> --
> if (n->has_vnet_hdr) {
> n->curr_guest_offloads =
> virtio_net_guest_offloads_by_features(features);
So let's move that part to the new hook too.
> --
> ( https://github.com/qemu/qemu/blob/master/hw/net/virtio-net.c#L774 )
>
> I.e. although virtio_net_apply_guest_offloads would now be called
> after the virtio_net_set_features, by the time it is called the
> VirtIONet::curr_guest_offloads would be reset to a full list of
> features.
>
> Regards,
> Mikhail
>
> Am Do., 10. Okt. 2019 um 20:04 Uhr schrieb Michael S. Tsirkin
> :
> >
> > Currently offloads disabled by guest via the
> > VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
> > command are not preserved on VM migration.
> > Instead all offloads reported by guest features (via
> > VIRTIO_PCI_GUEST_FEATURES)
> > get enabled.
> > What happens is: first the VirtIONet::curr_guest_offloads gets restored
> > and offloads are getting set correctly:
> >
> > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=0, tso6=0, ecn=0,
> > ufo=0) at net/net.c:474
> > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > hw/net/virtio-net.c:720
> > #2 virtio_net_post_load_device (opaque=0x57701ca0, version_id=11) at
> > hw/net/virtio-net.c:2334
> > #3 vmstate_load_state (f=0x569dc010, vmsd=0x56577c80
> > , opaque=0x57701ca0, version_id=11)
> > at migration/vmstate.c:168
> > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010, version_id=11) at
> > hw/virtio/virtio.c:2197
> > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0, size=0,
> > field=0x5668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036
> > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > , opaque=0x57701ca0, version_id=11) at
> > migration/vmstate.c:143
> > #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> > migration/savevm.c:829
> > #8 qemu_loadvm_section_start_full (f=0x569dc010, mis=0x569eee20)
> > at migration/savevm.c:2211
> > #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
> > migration/savevm.c:2395
> > #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> > #11 process_incoming_migration_co (opaque=0x0) at migration/migration.c:449
> >
> > However later on the features are getting restored, and offloads get reset
> > to
> > everything supported by features:
> >
> > #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=1, tso6=1, ecn=0,
> > ufo=0) at net/net.c:474
> > #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> > hw/net/virtio-net.c:720
> > #2 virtio_net_set_features (vdev=0x57701ca0, features=5104441767) at
> > hw/net/virtio-net.c:773
> > #3 virtio_set_features_nocheck (vdev=0x57701ca0, val=5104441767) at
> > hw/virtio/virtio.c:2052
> > #4 virtio_load (vdev=0x57701ca0, f=0x569dc010, version_id=11) at
> > hw/virtio/virtio.c:2220
> > #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0, size=0,
> > field=0x5668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036
> > #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> > , opaque=0x57701ca0, version_id=11) at
> > migration/vmstate.c:143
> > #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> > migration/savevm.c:829
> > #8 qemu_loadvm_section_start_full (f=0x569dc010, mis=0x569eee20)
> > at migration/savevm.c:2211
> > #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
> > migration/savevm.c:2395
> > #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> > #11 process_incoming_migration_co (opaque=0x0) at migration/migration.c:449
> >
> > Fix this by pushing out offload initialization to the new post load hook.
> >
> > Reported-by: Mikhail Sennikovsky
> > Signed-off-by: Michael S. Tsirkin
> > ---
> > hw/net/virtio-net.c | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 9f11422337..62fb858e2d 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -2333,10 +2333,6 @@ static int virtio_net_post_load_device(void *opaque,
> > int version_id)
> > n->curr_guest_offloads = virtio_net_supported_guest_offloads(n);
> > }
> >
> > -if (peer_has_vnet_hdr(n)) {
> > -virtio_net_apply_guest_offloads(n);
> > -}
> > -
> > virtio_net_set_queues(n);
> >
> > /* Find the first multicast entry in the saved MAC filter */
> > @@ -2370,6 +2366,15 @@ static int virtio_net_post_load_device(void *opaque,
> > int version_id)
> > return 0;
> > }
> >
> > +static int virtio_net_post_load_virtio(VirtIODevice *vdev)
> > +{
> > +if (peer_has_vnet_hdr(n)) {
> > +
Re: [RFC 2/2] virtio-net: use post load hook
Hi Michael,
Unfortunately your approach will not work, because the
VirtIONet::curr_guest_offloads would still be reset in
virtio_net_set_features:
--
if (n->has_vnet_hdr) {
n->curr_guest_offloads =
virtio_net_guest_offloads_by_features(features);
--
( https://github.com/qemu/qemu/blob/master/hw/net/virtio-net.c#L774 )
I.e. although virtio_net_apply_guest_offloads would now be called
after the virtio_net_set_features, by the time it is called the
VirtIONet::curr_guest_offloads would be reset to a full list of
features.
Regards,
Mikhail
Am Do., 10. Okt. 2019 um 20:04 Uhr schrieb Michael S. Tsirkin :
>
> Currently offloads disabled by guest via the
> VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
> command are not preserved on VM migration.
> Instead all offloads reported by guest features (via
> VIRTIO_PCI_GUEST_FEATURES)
> get enabled.
> What happens is: first the VirtIONet::curr_guest_offloads gets restored
> and offloads are getting set correctly:
>
> #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=0, tso6=0, ecn=0,
> ufo=0) at net/net.c:474
> #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> hw/net/virtio-net.c:720
> #2 virtio_net_post_load_device (opaque=0x57701ca0, version_id=11) at
> hw/net/virtio-net.c:2334
> #3 vmstate_load_state (f=0x569dc010, vmsd=0x56577c80
> , opaque=0x57701ca0, version_id=11)
> at migration/vmstate.c:168
> #4 virtio_load (vdev=0x57701ca0, f=0x569dc010, version_id=11) at
> hw/virtio/virtio.c:2197
> #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0, size=0,
> field=0x5668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036
> #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> , opaque=0x57701ca0, version_id=11) at
> migration/vmstate.c:143
> #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> migration/savevm.c:829
> #8 qemu_loadvm_section_start_full (f=0x569dc010, mis=0x569eee20) at
> migration/savevm.c:2211
> #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
> migration/savevm.c:2395
> #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> #11 process_incoming_migration_co (opaque=0x0) at migration/migration.c:449
>
> However later on the features are getting restored, and offloads get reset to
> everything supported by features:
>
> #0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=1, tso6=1, ecn=0,
> ufo=0) at net/net.c:474
> #1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
> hw/net/virtio-net.c:720
> #2 virtio_net_set_features (vdev=0x57701ca0, features=5104441767) at
> hw/net/virtio-net.c:773
> #3 virtio_set_features_nocheck (vdev=0x57701ca0, val=5104441767) at
> hw/virtio/virtio.c:2052
> #4 virtio_load (vdev=0x57701ca0, f=0x569dc010, version_id=11) at
> hw/virtio/virtio.c:2220
> #5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0, size=0,
> field=0x5668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036
> #6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
> , opaque=0x57701ca0, version_id=11) at
> migration/vmstate.c:143
> #7 vmstate_load (f=0x569dc010, se=0x578189e0) at
> migration/savevm.c:829
> #8 qemu_loadvm_section_start_full (f=0x569dc010, mis=0x569eee20) at
> migration/savevm.c:2211
> #9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
> migration/savevm.c:2395
> #10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
> #11 process_incoming_migration_co (opaque=0x0) at migration/migration.c:449
>
> Fix this by pushing out offload initialization to the new post load hook.
>
> Reported-by: Mikhail Sennikovsky
> Signed-off-by: Michael S. Tsirkin
> ---
> hw/net/virtio-net.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 9f11422337..62fb858e2d 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -2333,10 +2333,6 @@ static int virtio_net_post_load_device(void *opaque,
> int version_id)
> n->curr_guest_offloads = virtio_net_supported_guest_offloads(n);
> }
>
> -if (peer_has_vnet_hdr(n)) {
> -virtio_net_apply_guest_offloads(n);
> -}
> -
> virtio_net_set_queues(n);
>
> /* Find the first multicast entry in the saved MAC filter */
> @@ -2370,6 +2366,15 @@ static int virtio_net_post_load_device(void *opaque,
> int version_id)
> return 0;
> }
>
> +static int virtio_net_post_load_virtio(VirtIODevice *vdev)
> +{
> +if (peer_has_vnet_hdr(n)) {
> +virtio_net_apply_guest_offloads(n);
> +}
> +
> +return 0;
> +}
> +
> /* tx_waiting field of a VirtIONetQueue */
> static const VMStateDescription vmstate_virtio_net_queue_tx_waiting = {
> .name = "virtio-net-queue-tx_waiting",
> @@ -2912,6 +2917,7 @@ static void virtio_net_class_init(ObjectClass *klass,
> void *data)
> vdc->guest_notifier_mask =
Re: [RFC 2/2] virtio-net: use post load hook
On 2019/10/11 上午2:04, Michael S. Tsirkin wrote:
Currently offloads disabled by guest via the VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET
command are not preserved on VM migration.
Instead all offloads reported by guest features (via VIRTIO_PCI_GUEST_FEATURES)
get enabled.
What happens is: first the VirtIONet::curr_guest_offloads gets restored
and offloads are getting set correctly:
#0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=0, tso6=0, ecn=0,
ufo=0) at net/net.c:474
#1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
hw/net/virtio-net.c:720
#2 virtio_net_post_load_device (opaque=0x57701ca0, version_id=11) at
hw/net/virtio-net.c:2334
#3 vmstate_load_state (f=0x569dc010, vmsd=0x56577c80
, opaque=0x57701ca0, version_id=11)
at migration/vmstate.c:168
#4 virtio_load (vdev=0x57701ca0, f=0x569dc010, version_id=11) at
hw/virtio/virtio.c:2197
#5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0, size=0,
field=0x5668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036
#6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
, opaque=0x57701ca0, version_id=11) at
migration/vmstate.c:143
#7 vmstate_load (f=0x569dc010, se=0x578189e0) at
migration/savevm.c:829
#8 qemu_loadvm_section_start_full (f=0x569dc010, mis=0x569eee20) at
migration/savevm.c:2211
#9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
migration/savevm.c:2395
#10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
#11 process_incoming_migration_co (opaque=0x0) at migration/migration.c:449
However later on the features are getting restored, and offloads get reset to
everything supported by features:
#0 qemu_set_offload (nc=0x56a11400, csum=1, tso4=1, tso6=1, ecn=0,
ufo=0) at net/net.c:474
#1 virtio_net_apply_guest_offloads (n=0x57701ca0) at
hw/net/virtio-net.c:720
#2 virtio_net_set_features (vdev=0x57701ca0, features=5104441767) at
hw/net/virtio-net.c:773
#3 virtio_set_features_nocheck (vdev=0x57701ca0, val=5104441767) at
hw/virtio/virtio.c:2052
#4 virtio_load (vdev=0x57701ca0, f=0x569dc010, version_id=11) at
hw/virtio/virtio.c:2220
#5 virtio_device_get (f=0x569dc010, opaque=0x57701ca0, size=0,
field=0x5668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036
#6 vmstate_load_state (f=0x569dc010, vmsd=0x56577ce0
, opaque=0x57701ca0, version_id=11) at
migration/vmstate.c:143
#7 vmstate_load (f=0x569dc010, se=0x578189e0) at
migration/savevm.c:829
#8 qemu_loadvm_section_start_full (f=0x569dc010, mis=0x569eee20) at
migration/savevm.c:2211
#9 qemu_loadvm_state_main (f=0x569dc010, mis=0x569eee20) at
migration/savevm.c:2395
#10 qemu_loadvm_state (f=0x569dc010) at migration/savevm.c:2467
#11 process_incoming_migration_co (opaque=0x0) at migration/migration.c:449
Fix this by pushing out offload initialization to the new post load hook.
Reported-by: Mikhail Sennikovsky
Signed-off-by: Michael S. Tsirkin
---
hw/net/virtio-net.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 9f11422337..62fb858e2d 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -2333,10 +2333,6 @@ static int virtio_net_post_load_device(void *opaque, int
version_id)
n->curr_guest_offloads = virtio_net_supported_guest_offloads(n);
}
-if (peer_has_vnet_hdr(n)) {
-virtio_net_apply_guest_offloads(n);
-}
-
virtio_net_set_queues(n);
/* Find the first multicast entry in the saved MAC filter */
@@ -2370,6 +2366,15 @@ static int virtio_net_post_load_device(void *opaque, int
version_id)
return 0;
}
+static int virtio_net_post_load_virtio(VirtIODevice *vdev)
+{
+if (peer_has_vnet_hdr(n)) {
+virtio_net_apply_guest_offloads(n);
+}
+
+return 0;
+}
+
/* tx_waiting field of a VirtIONetQueue */
static const VMStateDescription vmstate_virtio_net_queue_tx_waiting = {
.name = "virtio-net-queue-tx_waiting",
@@ -2912,6 +2917,7 @@ static void virtio_net_class_init(ObjectClass *klass,
void *data)
vdc->guest_notifier_mask = virtio_net_guest_notifier_mask;
vdc->guest_notifier_pending = virtio_net_guest_notifier_pending;
vdc->legacy_features |= (0x1 << VIRTIO_NET_F_GSO);
+vdc->post_load = virtio_net_post_load_virtio;
vdc->vmsd = _virtio_net_device;
}
Looks good to me.
Thanks
