Re: [Qemu-devel] Re: [PATCHv2 2/2] tap: mark fd handler as device

[Stefan Hajnoczi]

On Mon, Nov 15, 2010 at 4:09 PM, Anthony Liguori <address@hidden> 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"<address@hidden>   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<address@hidden>
>>>>>
>>>>
>>>> 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