Re: [Qemu-devel] Re: [PATCHv2 2/2] tap: mark fd handler as device
On 11/15/2010 02:53 PM, Stefan Hajnoczi wrote: 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. I still think that stopping this at the net/block layer is going to be a lot more robust in the long term. All net/block traffic flows through a single set of interfaces whereas getting the devices to completely stop themselves requires touching every device and making sure that noone adds back vmstop-unfriendly behavior down the road. Regards, Anthony Liguori Stefan
Re: [Qemu-devel] Re: [PATCHv2 2/2] tap: mark fd handler as device
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. Tsirkinm...@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. Tsirkinm...@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
Re: [Qemu-devel] Re: [PATCHv2 2/2] tap: mark fd handler as device
On Mon, Nov 15, 2010 at 03:05:39PM -0600, Anthony Liguori wrote: On 11/15/2010 02:53 PM, Stefan Hajnoczi wrote: 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. I still think that stopping this at the net/block layer is going to be a lot more robust in the long term. All net/block traffic flows through a single set of interfaces whereas getting the devices to completely stop themselves requires touching every device and making sure that noone adds back vmstop-unfriendly behavior down the road. Regards, Anthony Liguori So I'm not sure I understand what is proposed here. Care posting a patch? -- MST
Re: [Qemu-devel] Re: [PATCHv2 2/2] tap: mark fd handler as device
On 11/15/2010 04:44 PM, Michael S. Tsirkin wrote:
So I'm not sure I understand what is proposed here.
Care posting a patch?
I *think* just adding:
if (vm_running == 0) {
return qemu_net_queue_append(queue, sender, flags, data, size, NULL);
}
To qemu_net_queue_send() along with a state notifier to kick the queue
on start would do the trick.
Regards,
Anthony Liguori
