From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: qemu-devel@nongnu.org, anthony@codemonkey.ws, kvm@vger.kernel.org
Subject: Re: [RFC PATCH 0/4] Model specific function for nic announcement
Date: Mon, 27 Sep 2010 16:25:13 +0200 [thread overview]
Message-ID: <20100927142513.GA6910@redhat.com> (raw)
In-Reply-To: <20100927124606.12060.66912.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
On Mon, Sep 27, 2010 at 08:50:44PM +0800, Jason Wang wrote:
> This series of patch tries to solve the problem of migration with nics who have
> multiple mac addresses or vlans. Qemu currently only send gratuitous packet for
> first mac address, so after migration other mac addresses or vlans were broken.
>
> The information of mac addresses and vlans were often stored in model specific
> structure, so a model specific function were introduced and used after
> migration during self announcement. A sample announcing function for virtio-net
> is also implemented in this series. Other model could be also done in this
> way. The previous method is kept for the model who does not implement model
> specific function.
>
> While there's still issues which need your comments and need to be solved.
>
> 1 Virtio specification allows filtering any number of destination mac addresses
> which looks impossible for the migration. Then we need to record an unlimited
> numbers of mac address which is not safe.
>
> 2 Virtio specification allows filtering of vlan and mac address but neither the
> spec nor the implementation could decide the mappings between vlans and mac
> addresses. This could make it impossible to send correct tagged gratuitous
> packet.
> For issue 1, the number of mac addresses were limited in this series.
> For issue 2, I suspect it needs the modification of guest drivers to send the
> mappings in order to make migration work. Or is there any method to get this
> without touching guest drivers? For safety, all the mac addresses were only
> announced when there's no vlan in guest which means the vlan after migration is
> still broken.
>
> This patchset is just an RFC and need your suggestions and comments.
>
> Thanks.
For 1, all guests actually do is on error status is print
a warning. This does not sound all that useful, does it?
I note that we also have a similar issue with promisc mode.
For 2, we could at least make it work for a common case of 1 mac,
which would already cover many users.
> ---
>
> Jason Wang (4):
> net: move announce_self_create to net.c
> net: Introduce model specific nic announce function
> virtio-net: Limit the num of uni/multicast mac addresses
> virtio-net: implement virtio-net specific announce function
>
>
> hw/virtio-net.c | 47 ++++++++++++++++++++++++++++++++++++++++++-----
> net.c | 31 +++++++++++++++++++++++++++++++
> net.h | 3 +++
> savevm.c | 42 ++++++++----------------------------------
> 4 files changed, 84 insertions(+), 39 deletions(-)
>
> --
> Jason Wang
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: [Qemu-devel] Re: [RFC PATCH 0/4] Model specific function for nic announcement
Date: Mon, 27 Sep 2010 16:25:13 +0200 [thread overview]
Message-ID: <20100927142513.GA6910@redhat.com> (raw)
In-Reply-To: <20100927124606.12060.66912.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
On Mon, Sep 27, 2010 at 08:50:44PM +0800, Jason Wang wrote:
> This series of patch tries to solve the problem of migration with nics who have
> multiple mac addresses or vlans. Qemu currently only send gratuitous packet for
> first mac address, so after migration other mac addresses or vlans were broken.
>
> The information of mac addresses and vlans were often stored in model specific
> structure, so a model specific function were introduced and used after
> migration during self announcement. A sample announcing function for virtio-net
> is also implemented in this series. Other model could be also done in this
> way. The previous method is kept for the model who does not implement model
> specific function.
>
> While there's still issues which need your comments and need to be solved.
>
> 1 Virtio specification allows filtering any number of destination mac addresses
> which looks impossible for the migration. Then we need to record an unlimited
> numbers of mac address which is not safe.
>
> 2 Virtio specification allows filtering of vlan and mac address but neither the
> spec nor the implementation could decide the mappings between vlans and mac
> addresses. This could make it impossible to send correct tagged gratuitous
> packet.
> For issue 1, the number of mac addresses were limited in this series.
> For issue 2, I suspect it needs the modification of guest drivers to send the
> mappings in order to make migration work. Or is there any method to get this
> without touching guest drivers? For safety, all the mac addresses were only
> announced when there's no vlan in guest which means the vlan after migration is
> still broken.
>
> This patchset is just an RFC and need your suggestions and comments.
>
> Thanks.
For 1, all guests actually do is on error status is print
a warning. This does not sound all that useful, does it?
I note that we also have a similar issue with promisc mode.
For 2, we could at least make it work for a common case of 1 mac,
which would already cover many users.
> ---
>
> Jason Wang (4):
> net: move announce_self_create to net.c
> net: Introduce model specific nic announce function
> virtio-net: Limit the num of uni/multicast mac addresses
> virtio-net: implement virtio-net specific announce function
>
>
> hw/virtio-net.c | 47 ++++++++++++++++++++++++++++++++++++++++++-----
> net.c | 31 +++++++++++++++++++++++++++++++
> net.h | 3 +++
> savevm.c | 42 ++++++++----------------------------------
> 4 files changed, 84 insertions(+), 39 deletions(-)
>
> --
> Jason Wang
next prev parent reply other threads:[~2010-09-27 14:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-27 12:50 [RFC PATCH 0/4] Model specific function for nic announcement Jason Wang
2010-09-27 12:50 ` [Qemu-devel] " Jason Wang
2010-09-27 12:50 ` [RFC PATCH 1/4] net: move announce_self_create to net.c Jason Wang
2010-09-27 12:50 ` [Qemu-devel] " Jason Wang
2010-09-27 12:51 ` [RFC PATCH 2/4] net: Introduce model specific nic announce function Jason Wang
2010-09-27 12:51 ` [Qemu-devel] " Jason Wang
2010-09-27 12:51 ` [RFC PATCH 3/4] virtio-net: Limit the num of uni/multicast mac addresses Jason Wang
2010-09-27 12:51 ` [Qemu-devel] " Jason Wang
2010-09-27 12:51 ` [RFC PATCH 4/4] virtio-net: implement virtio-net specific announce function Jason Wang
2010-09-27 12:51 ` [Qemu-devel] " Jason Wang
2010-09-27 14:25 ` Michael S. Tsirkin [this message]
2010-09-27 14:25 ` [Qemu-devel] Re: [RFC PATCH 0/4] Model specific function for nic announcement Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100927142513.GA6910@redhat.com \
--to=mst@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.