On Fri, Mar 02, 2018 at 12:56:21PM -0800, Samudrala, Sridhar wrote: > > > 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. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > - 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 > > VF2. > > > > > 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.
If these are two separate PFs then I don't see why - each has its own MAC filter. > Here is the more complete sequence of steps that are required to > enable live migration. Replacing VF1 by VF2 is not about migration. It's to remove PF from host e.g. for service. -- MST
