On Mon, Nov 12, 2018 at 10:53 PM Michael S. Tsirkin <m...@redhat.com> wrote:
> On Mon, Nov 12, 2018 at 01:31:36PM +0200, Yuri Benditovich wrote: > > > > > > On Mon, Nov 12, 2018 at 11:26 AM Jason Wang <jasow...@redhat.com> wrote: > > > > > > On 2018/11/12 下午4:57, Yuri Benditovich wrote: > > > > > > On Mon, Nov 12, 2018 at 4:54 AM Michael S. Tsirkin <m...@redhat.com > > > <mailto:m...@redhat.com>> wrote: > > > > > > On Sun, Nov 11, 2018 at 12:18:54PM +0200, Yuri Benditovich > wrote: > > > > > @@ -66,12 +143,16 @@ typedef struct VirtIONet { > > > > > VirtIONetQueue *vqs; > > > > > VirtQueue *ctrl_vq; > > > > > NICState *nic; > > > > > + QTAILQ_HEAD(, NetRscChain) rsc_chains; > > > > > > > > what exactly happens with these chains on migration? > > > > > > > > > > > > This feature (software implementation of RSC in QEMU) is > > > intended to be used in > > > > the environment of certification tests which never uses > migration. > > > > > > Should this feature disable migration then? > > > > > > > > > IMO, this should not. But if you find it mandatory, please respond > and > > > I will add the migration blocker. > > > > > > So if my understanding is correct, it's safe to do nothing even if we > > allow migration for RSC? > > > > > > This does not create any unrecoverable failure (assertion, BSOD), > although > > some data (coalesced parts of packets not delivered yet to guest) will > be lost. > > If guest has no way to detect none of these packets were ever > received by card, then I guess it's fine. Needs a > comment in case we start caring about packet loss around > migration. > > Where is the best place to place such a comment in the code? Are there more notes toward v3 of the patch? > > > > > > Thanks > > > > > > >
