On Mon, Nov 15, 2010 at 4:09 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 11/15/2010 09:18 AM, Michael S. Tsirkin wrote: >> >> On Mon, Nov 15, 2010 at 08:55:07AM -0600, Anthony Liguori wrote: >> >>> >>> On 11/15/2010 08:52 AM, Juan Quintela wrote: >>> >>>> >>>> "Michael S. Tsirkin"<m...@redhat.com> wrote: >>>> >>>>> >>>>> There's no reason for tap to run when VM is stopped. >>>>> If we let it, it confuses the bridge on TX >>>>> and corrupts DMA memory on RX. >>>>> >>>>> Signed-off-by: Michael S. Tsirkin<m...@redhat.com> >>>>> >>>> >>>> once here, what handlers make sense to run while stopped? >>>> /me can think of the normal console, non live migration, loadvm and not >>>> much more. Perhaps it is easier to just move the other way around? >>>> >>> >>> I'm not sure I concur that this is really a problem. >>> Semantically, I don't think that stop has to imply that the guest >>> memory no longer changes. >>> >>> Regards, >>> >>> Anthony Liguori >>> >>> >>>> >>>> Later, Juan. >>>> >> >> Well, I do not really know about vmstop that is not for migration. >> > > They are separate. For instance, we don't rely on stop to pause pending > disk I/O because we don't serialize pending disk I/O operations. Instead, > we flush all pending I/O and rely on the fact that disk I/O requests are > always submitted in the context of a vCPU operation. This assumption breaks > down though with ioeventfd so we need to revisit it.
vhost has a solution for this: register a VMChangeStateHandler function that stops ioeventfd while vm_stop(0) is in effect. Then poll to see if there is work pending. I will add equivalent functionality to virtio-ioeventfd. Stefan
