Re: [Qemu-devel] [PATCH 07/12] block: save the associated child in BlockDriverState

[Paolo Bonzini]

Il 21/06/2013 10:36, Marc-André Lureau ha scritto:
> Hi
> 
> 
> On Fri, Jun 21, 2013 at 12:25 AM, Paolo Bonzini <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Il 20/06/2013 19:46, Marc-André Lureau ha scritto:
>     > This allows the Spice block driver to eject the associated device.
> 
>     The child can change when you have for example a streaming operation.
> 
> Ah, can you point me to some function or some way I can reproduce? I
> don't know what you mean by a streaming operation here.

Let's just discuss the design so that it just works and you don't have
to worry about it. :)

>     What exactly are you trying to do here (I guess I'll understand more
>     when I get to the later patches)?
> 
> Getting to the bottom BlockDriverState to be able to eject & change it.
> (it could also be named the "parent", but other parts of the code
> suggest the "child" name)

There is already an interface for eject/change, which is the monitor.
To signal an eject or medium change, the SPICE client should simply ask
libvirt to do so.  It is fine to change "from" spicebd: "to" spicebd:,
the guest would still perceive it as a change.

I'm not sure how libvirt communicates the change back to the SPICE
client, and whether it is asynchronous or synchronous.

BTW, note that IDE or virtio-blk do not support removable media, and are
not able to pass eject or media change notifications.  SCSI devices
(such as usb-bot, usb-uas and virtio-scsi) can.

>     Can you draw the relationships between all the BlockDriverStates in a
>     spicebd: drive?
> 
> 
> Hopefully, but I have only tested with raw images (w/wo snapshot).

Then draw it. :)  But from the above description it looks like it is not
necessary, it should simply be "raw" on top of "spicebd".  Parsing
formats should be done on the client side, perhaps by invoking qemu-nbd
and tunnelling the NBD data on the SPICE channel.

Paolo