On Mon, May 26, 2014 at 02:51:48PM +0300, Michael S. Tsirkin wrote:
> 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 0
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 +, Zhanghailiang wrote:
> > > > > If you implement
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 +, Zhanghailiang wrote:
> > > > If you implement this in the net layer then that problem is easy to
> > > > resolve sinc
On Wed, May 14, 2014 at 02:30:26PM +0200, Stefan Hajnoczi wrote:
> On Thu, May 08, 2014 at 12:51:05PM +, 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 flowin
On Thu, May 08, 2014 at 12:51:05PM +, 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
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 +, Zhanghailiang wrote:
> > > On Sat, Apr 26, 2014 at 9:04 PM, Peter Maydell
> > >
> > > wrote:
> > > > On 26 April 2014 11:44, Amos Kong wrote:
> > > >>
>
On Mon, Apr 28, 2014 at 03:22:34AM +, Zhanghailiang wrote:
> > On Sat, Apr 26, 2014 at 9:04 PM, Peter Maydell
> > wrote:
> > > On 26 April 2014 11:44, Amos Kong wrote:
> > >>
> > >> I'm ok with the patch idea.
> > >>
> > >> On Sat, Apr 26, 2014 at 06:19:12PM +0800, zhanghailiang wrote:
> > >>
> On Sat, Apr 26, 2014 at 9:04 PM, Peter Maydell
> wrote:
> > On 26 April 2014 11:44, Amos Kong 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.
>
Hi Amos:
Thanks for replying.
> 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 runni
On Sat, Apr 26, 2014 at 9:04 PM, Peter Maydell wrote:
> On 26 April 2014 11:44, Amos Kong 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.
>>
On 26 April 2014 11:44, Amos Kong 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.
> ^
>
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.
^
For e1000/rtl8139, qemu can still send/receive packets when VM is paused.
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.
Signed-off-by:
13 matches
Mail list logo
