[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH] net: delay peer host device delete

From: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCH] net: delay peer host device delete
Date: Mon, 20 Sep 2010 15:15:45 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100826 Lightning/1.0b1 Thunderbird/3.0.7

On 09/20/2010 02:37 PM, Michael S. Tsirkin wrote:
On Mon, Sep 20, 2010 at 02:22:18PM -0500, Anthony Liguori wrote:
On 09/20/2010 01:59 PM, Michael S. Tsirkin wrote:
You can also initiate the unplug from the OS without the ACPI event
ever happening.  I suspect that in our current implementation, that
means that we'll automatically delete the device which may have
strange effects on management tools.

So it probably makes sense for our interface to present the same
procedure.  What do you think?


Anthony Liguori
We seem to have two discussions here. you speak about how an ideal hot plug
interface will look. This can involve new commands etc.
I speak about fixing existing ones so qemu and/or guest won't crash.
To be fair, existing qemu won't crash if you do:

(qemu) device_del<device>
Use info_qtree to notice when device goes away
(qemu) netdev_del<backend>
Asking libvirt to busy loop polling the monitor sounds like a really bad
situation: note that guest is blocked from doing any io while monitor is
used, so it may in fact prevent it from making progress. Right?

With a busy loop? No, the guest will always make some progress because we drop back to the main loop. But that's besides the point really. libvirt can just do a usleep() when polling.

Yes, this interface sucks but that's the interface we have today.

So why can't we let management do netdev_del and have it take effect
when this becomes possible?

You're making netdev_del be a semantic request that a network backend is eventually deleted after some guest controlled period of time.

If libvirt is trying to do useful things like manage a limit set of resources (maybe VFs using SR-IOV passthrough), then libvirt needs to know when it can reassign a VF to another guest. But now it can't do that after it does netdev_del. Is it supposed to poll to figure out when it can do it?

You're trying to come up with a workaround for the fact that libvirt
is making bad assumptions.
BTW, even if it is, I don't think we should be crashing qemu or guest.

That's certainly true.  But that's a different patch.

That's wrong.  We either need to fix
libvirt to not make bad assumptions or we need to provide better
interfaces for libvirt to use if the current interfaces aren't


Anthony Liguori

This requires fixing existing commands, unless we can't
fix them at all - which is demonstrably not the case.
But frankly, most command semantics are completely ad hock and not well
undefined, in my mind it's better to define them to accomodate existing

Okay, let's give them an interface they actually want. Forcing them to poll for when a netdev is actually removed is probably not what they actually want.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]