qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from devic


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal
Date: Thu, 4 Nov 2010 19:04:34 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Nov 04, 2010 at 11:45:51AM -0500, Ryan Harper wrote:
> OK.  With netdev_del and drive_unplug commands (not sure if we care to
> change the names to be similar, maybe blockdev_del) in qemu, we can then
> implement the following in libvirt:
> 
> 1) detach-device invocation
> 2) issue device_del to QEMU
> 2a) notification is sent)
> 3) issue netdev_del/blockdev_del as appropriate for the device type
> 4) update guest XML to indicate device has been removed
> And a fancier version would look like:
> 
> 1) detach-device invocation
> 2) issue device_del to QEMU
> 2a) notification is sent)
> 3) set a timeout for guest to respond
> 4) when timeout expires
> 4a) check if the pci device has been removed by quering QEMU
>     if it hasn't been removed, issue netdev_del/blockdev_del

I think it's easier to check the network device:
info network and whatever is appropriate for block

> 5) update guest XML to indicate device has been removed
> 
> 
> in both cases, I think we'll also want a patch that validates that the
> pci slot is available before handing it out again; this will handle the
> case where the guest doesn't respond to the device removal request; our
> net/blockdev_del command will break the host/guest association, but we
> don't want to attempt to attach a device to the same slot.

Yes, absolutely.  And same for qdev device id.

> Marcus, do you think we're at a point where the mechanisms for
> explicitly revoking access to the host resource is consistent between
> net and block?
> 
> If so, then I suppose I might have a consmetic patch to fix up the
> monitor command name to line up with the netdev_del.
> 
> 
> -- 
> Ryan Harper
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
> address@hidden



reply via email to

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