On 3/2/2018 12:44 PM, Siwei Liu wrote:
On Fri, Mar 2, 2018 at 12:10 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
On Fri, Mar 02, 2018 at 11:52:27AM -0800, Samudrala, Sridhar wrote:

On 3/2/2018 11:41 AM, Michael S. Tsirkin wrote:
On Fri, Mar 02, 2018 at 07:26:25AM -0800, Alexander Duyck wrote:
The design limits things to a 1:1 relationship since we just have the
child and backup pointers, but I don't think I am seeing exception
handling to prevent us from overwriting the child pointers so there
may be a leak there.


- Alex
In fact maintaining a list in that case would be nicer, and
just use an arbitrary one.
E.g. one can see how a user wanting to swap device 1 for device 2
might first add device 2 with same MAC then drop device 1.
It should be possible to swap VF1 with VF2 by
1.- enabling virtio link
2.- unplugging VF1
3.- plugging VF2
4.- disabling virtio link

True, but it isn't hard to avoid breakage if user
swapped steps 2 and 3. No need to make it more
fragile that it has to be.
The migration case, VF2 is associated with another PF on another
machine (destination), I wonder how it is possible.

Even with local plugging of VF2 on the same PF, the MAC address
requirement (VF1's == VF2's) would fail the MAC address assignment on

I didn't include updating the MAC filter step in the above sequence.
So definitely plugging 2 VFs with the same MAC address will be an issue.

Here is the more complete sequence of steps that are required to
enable live migration.

Source Hypervisor
- Bring up the virtio link
- Hot Unplug VF from the VM
- Delete FDB entry for the MAC on the Bridge associated with virtio/tap
- Remove the MAC filter associated with the VF
- Migrate VM to destination

Destination Hypervisor (after migration is completed)
- Set MAC filter for the VF
- Hot Plug VF to the VM
- Bring down the virtio link


To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org

Reply via email to