Re: [Qemu-devel] [PATCH] e1000/rtl8139: forbid dealing with packets when VM is paused

[Zhanghailiang]

Hi Stefan,

I have test other network cards, such as pcnet, ne2000, and they also have the 
problem.
> On Mon, Apr 28, 2014 at 03:22:34AM +0000, Zhanghailiang wrote:
> > > On Sat, Apr 26, 2014 at 9:04 PM, Peter Maydell
> > > <address@hidden>
> > > wrote:
> > > > On 26 April 2014 11:44, Amos Kong <address@hidden> wrote:
> > > >>
> > > >> I'm ok with the patch idea.
> > > >>
> > > >> On Sat, Apr 26, 2014 at 06:19:12PM +0800, zhanghailiang wrote:
> > > >>> For e1000/rtl8139, qemu can still send/receive packets when VM
> > > >>> is
> > > paused.
> > > >>
> > > ^^^^^^^^^
> > > >>
> ->
> > > isn't
> > > >> running
> > > >>
> > > >> There are many kinds of RunState, "is paused" doesn't equal to
> > > >> "isn't
> > > running".
> > > >>
> > > >>> If this happened in *migration's* last PAUSE VM stage, the new
> > > >>> dirty RAM
> > > related to the packets will be missed.
> > > >>> To avoid this, do things like virtio-net, forbid
> > > >>> sending/receiving packets when VM is suspend.
> > > >>                   ^^^^^^^^^^^  -> isn't running.
> > > >
> > > > Shouldn't this be handled in the generic net code rather than
> > > > requiring every ethernet device model to include identical code?
> > > >
> > >
> > > +1.
> > >
> > > > thanks
> > > > -- PMM
> > > >
> > Hi,
> > Thanks for replying.
> > It is a good idea to handle the VM runstate check in generic net code.
> > Before send such a patch, I will look into other network cards emulated by
> qemu, and test if they have the same problem.
> 
> Yes, please!
> 
> virtio-net has a partial solution, it listens for VM runstate changes.
> But it's a bit buggy because it does not flush the peer's queue when runstate
> changes back to running.
Agreed! 
> If you implement this in the net layer then that problem is easy to resolve 
> since
> we can flush all queues when the guest resumes to get packets flowing again.
> 
Do you mean we should also listen for VM runstate changes in net layer, and 
when detect runstate changes back to running , we flush all queues actively? Am 
I misunderstanding? 
Or we can do it *before* qemu (exactly when it check if it can send packets) 
send packets to guest again, this way will be simple, but it also need know the 
change of runstate. Any idea? 

Thanks,
zhanghailiang