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