On Wed, 07/15 15:38, Jason Wang wrote:
> 
> 
> On 07/15/2015 02:01 PM, Fam Zheng wrote:
> > On Wed, 07/15 13:10, Jason Wang wrote:
> >>>> And can we do this without a bh? Otherwise, we may need to stop and
> >>>> restart the bh during vm stop and start?
> >>> A bh doesn't hurt when vm stop and restart (we get superfluous flush),
> >> The problem is qemu_flush_queued_packets() does not check runstate. So
> >> it may call .receive() which may modify guest state (DMA or registers).
> > You're right, .can_receive will be called incorrectly if the following 
> > sequence
> > of events is processed by main loop right after we schedule it:
> >
> >  1) QMP 'stop' command:
> >     Runstate is changed to STOP.
> >
> >  2) tap read:
> >     A new packet is read in, but since qemu_can_send_packet is false, it 
> > will
> >     be queued.
> >
> >  3) aio_dispatch:
> >     This BH is called too late here, and the queue is flushed, which calls
> >     .receive().
> >
> > An ideal fix would be stopping tap with a vmstate handler, but for this 
> > patch,
> > does the following work?
> 
> Looks good for me. How about axienet then since in your series it also
> uses a bh?

Good point, the same applies, I'll fix that too.

Fam

Reply via email to