* Re: [Qemu-devel] [PATCH] e1000/rtl8139: forbid dealing with packets when VM is paused [not found] ` <D1BD20B5DB34024DA951CEEE6C4C59985962636A@szxema505-mbs.china.huawei.com> @ 2014-05-06 12:55 ` Stefan Hajnoczi 2014-05-08 12:51 ` Zhanghailiang 0 siblings, 1 reply; 6+ messages in thread From: Stefan Hajnoczi @ 2014-05-06 12:55 UTC (permalink / raw) To: Zhanghailiang Cc: Zhouxiangjiu, Peter Maydell, Peter Crosthwaite, Juan Quintela, Michael S. Tsirkin, QEMU Developers, Huangpeng (Peter), Alex Williamson, Amos Kong, Dave Gilbert 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] e1000/rtl8139: forbid dealing with packets when VM is paused 2014-05-06 12:55 ` [Qemu-devel] [PATCH] e1000/rtl8139: forbid dealing with packets when VM is paused Stefan Hajnoczi @ 2014-05-08 12:51 ` Zhanghailiang 2014-05-14 12:30 ` Stefan Hajnoczi 0 siblings, 1 reply; 6+ messages in thread From: Zhanghailiang @ 2014-05-08 12:51 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Zhouxiangjiu, Peter Maydell, Peter Crosthwaite, Juan Quintela, Michael S. Tsirkin, QEMU Developers, Huangpeng (Peter), Alex Williamson, Amos Kong, Dave Gilbert 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] e1000/rtl8139: forbid dealing with packets when VM is paused 2014-05-08 12:51 ` Zhanghailiang @ 2014-05-14 12:30 ` Stefan Hajnoczi 2014-05-14 12:46 ` Michael S. Tsirkin 0 siblings, 1 reply; 6+ messages in thread From: Stefan Hajnoczi @ 2014-05-14 12:30 UTC (permalink / raw) To: Zhanghailiang Cc: Zhouxiangjiu, Peter Maydell, Peter Crosthwaite, Michael S. Tsirkin, Juan Quintela, QEMU Developers, Huangpeng (Peter), Alex Williamson, Stefan Hajnoczi, Amos Kong, Dave Gilbert 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] e1000/rtl8139: forbid dealing with packets when VM is paused 2014-05-14 12:30 ` Stefan Hajnoczi @ 2014-05-14 12:46 ` Michael S. Tsirkin 2014-05-26 11:48 ` Stefan Hajnoczi 0 siblings, 1 reply; 6+ messages in thread From: Michael S. Tsirkin @ 2014-05-14 12:46 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Zhouxiangjiu, Peter Maydell, Peter Crosthwaite, Zhanghailiang, Juan Quintela, QEMU Developers, Huangpeng (Peter), Alex Williamson, Stefan Hajnoczi, Amos Kong, Dave Gilbert 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] e1000/rtl8139: forbid dealing with packets when VM is paused 2014-05-14 12:46 ` Michael S. Tsirkin @ 2014-05-26 11:48 ` Stefan Hajnoczi 2014-05-26 11:51 ` Michael S. Tsirkin 0 siblings, 1 reply; 6+ messages in thread From: Stefan Hajnoczi @ 2014-05-26 11:48 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Zhouxiangjiu, Peter Maydell, Peter Crosthwaite, Zhanghailiang, Juan Quintela, Stefan Hajnoczi, Peter Lieven, QEMU Developers, Huangpeng (Peter), Alex Williamson, Amos Kong, Dave Gilbert 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH] e1000/rtl8139: forbid dealing with packets when VM is paused 2014-05-26 11:48 ` Stefan Hajnoczi @ 2014-05-26 11:51 ` Michael S. Tsirkin 0 siblings, 0 replies; 6+ messages in thread From: Michael S. Tsirkin @ 2014-05-26 11:51 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Zhouxiangjiu, Peter Maydell, Peter Crosthwaite, Zhanghailiang, Juan Quintela, Stefan Hajnoczi, Peter Lieven, QEMU Developers, Huangpeng (Peter), Alex Williamson, Amos Kong, Dave Gilbert 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-05-26 11:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1398507552-50168-1-git-send-email-zhang.zhanghailiang@huawei.com>
[not found] ` <20140426104415.GB2389@amosk.info>
[not found] ` <CAFEAcA_fBi1TuuvTwXHEKJ5zOw7teDB_6JOwBMMCLumw7_fgVQ@mail.gmail.com>
[not found] ` <CAEgOgz5mnaY8V8SeJ0WuSof8j2wYSWGXb=FW4erkqM39r3xQ-g@mail.gmail.com>
[not found] ` <D1BD20B5DB34024DA951CEEE6C4C59985962636A@szxema505-mbs.china.huawei.com>
2014-05-06 12:55 ` [Qemu-devel] [PATCH] e1000/rtl8139: forbid dealing with packets when VM is paused Stefan Hajnoczi
2014-05-08 12:51 ` Zhanghailiang
2014-05-14 12:30 ` Stefan Hajnoczi
2014-05-14 12:46 ` Michael S. Tsirkin
2014-05-26 11:48 ` Stefan Hajnoczi
2014-05-26 11:51 ` Michael S. Tsirkin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).