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

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

[Stefan Hajnoczi]

On Mon, Apr 28, 2014 at 03:22:34AM +0000, Zhanghailiang wrote:
> > On Sat, Apr 26, 2014 at 9:04 PM, Peter Maydell <peter.maydell@linaro.org>
> > wrote:
> > > On 26 April 2014 11:44, Amos Kong <akong@redhat.com> 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.

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.

Stefan

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
> > > <peter.maydell@linaro.org>
> > > wrote:
> > > > On 26 April 2014 11:44, Amos Kong <akong@redhat.com> 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

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

[Stefan Hajnoczi]

On Thu, May 08, 2014 at 12:51:05PM +0000, Zhanghailiang wrote:
> > 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? 

When the runstate changes back to running, we definitely need to flush
queues to get packets flowing again.  I think the simplest way of doing
that is in the net layer so individual NICs and netdevs don't have to
duplicate this code.

Stefan

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

[Michael S. Tsirkin]

On Wed, May 14, 2014 at 02:30:26PM +0200, Stefan Hajnoczi wrote:
> On Thu, May 08, 2014 at 12:51:05PM +0000, Zhanghailiang wrote:
> > > 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? 
> 
> When the runstate changes back to running, we definitely need to flush
> queues to get packets flowing again.  I think the simplest way of doing
> that is in the net layer so individual NICs and netdevs don't have to
> duplicate this code.
> 
> Stefan

That will help with networking but not other devices.
The issue isn't limited to networking at all.
How about we stop all io threads with the vm?

That will address the issue in a generic way.

-- 
MST

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

[Stefan Hajnoczi]

On Wed, May 14, 2014 at 03:46:48PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 14, 2014 at 02:30:26PM +0200, Stefan Hajnoczi wrote:
> > On Thu, May 08, 2014 at 12:51:05PM +0000, Zhanghailiang wrote:
> > > > 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? 
> > 
> > When the runstate changes back to running, we definitely need to flush
> > queues to get packets flowing again.  I think the simplest way of doing
> > that is in the net layer so individual NICs and netdevs don't have to
> > duplicate this code.
> > 
> > Stefan
> 
> That will help with networking but not other devices.
> The issue isn't limited to networking at all.
> How about we stop all io threads with the vm?
> 
> That will address the issue in a generic way.

I'm not sure if it works in all cases, for example iSCSI where we send
nop keepalives.

Stefan

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

[Michael S. Tsirkin]

On Mon, May 26, 2014 at 01:48:13PM +0200, Stefan Hajnoczi wrote:
> On Wed, May 14, 2014 at 03:46:48PM +0300, Michael S. Tsirkin wrote:
> > On Wed, May 14, 2014 at 02:30:26PM +0200, Stefan Hajnoczi wrote:
> > > On Thu, May 08, 2014 at 12:51:05PM +0000, Zhanghailiang wrote:
> > > > > 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? 
> > > 
> > > When the runstate changes back to running, we definitely need to flush
> > > queues to get packets flowing again.  I think the simplest way of doing
> > > that is in the net layer so individual NICs and netdevs don't have to
> > > duplicate this code.
> > > 
> > > Stefan
> > 
> > That will help with networking but not other devices.
> > The issue isn't limited to networking at all.
> > How about we stop all io threads with the vm?
> > 
> > That will address the issue in a generic way.
> 
> I'm not sure if it works in all cases, for example iSCSI where we send
> nop keepalives.
> 
> Stefan

I am guessing that runs from the realtime clock?
We definitely want to keep realtime clock going when VM
is stopped, that's the definition.

-- 
MST