From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uq1Z9-0006Qg-O4 for qemu-devel@nongnu.org; Fri, 21 Jun 2013 09:39:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uq1Z8-00020e-F8 for qemu-devel@nongnu.org; Fri, 21 Jun 2013 09:39:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uq1Z8-00020V-7I for qemu-devel@nongnu.org; Fri, 21 Jun 2013 09:39:50 -0400 Message-ID: <51C4579F.1030803@redhat.com> Date: Fri, 21 Jun 2013 15:39:43 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1371750371-18491-1-git-send-email-marcandre.lureau@redhat.com> <1371750371-18491-8-git-send-email-marcandre.lureau@redhat.com> <51C38171.3010806@redhat.com> <51C43FA4.5060800@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 07/12] block: save the associated child in BlockDriverState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Marc-Andr=E9_Lureau?= Cc: spice-devel , qemu-devel@nongnu.org, "Richard W.M. Jones" Il 21/06/2013 15:30, Marc-Andr=E9 Lureau ha scritto: > > 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) >=20 > There is already an interface for eject/change, which is the monito= r. > 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" spiceb= d:, > the guest would still perceive it as a change. >=20 > I'm not sure how libvirt communicates the change back to the SPICE > client, and whether it is asynchronous or synchronous. >=20 > Spice is not using libvirt, and doesn't have access to monitor. I looke= d > at the monitor code. Basically, the spice block driver I proposed uses = a > similar code to forcefully eject and change. Similar, but it also violates encapsulation by adding bs->child. :) > Perhaps it's possible for the Spice qemu-side code to have access to th= e > monitor, but the end result would be similar anyway. That would work better. Spice qemu-side would keep an association between Spice channels and block device names, and use that to convert Spice commands to monitor commands (the API is qmp_change_blockdev/qmp_eject). Paolo >=20 > BTW, note that IDE or virtio-blk do not support removable media, an= d are > not able to pass eject or media change notifications. SCSI devices > (such as usb-bot, usb-uas and virtio-scsi) can. >=20 > > 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). >=20 > Then draw it. :) But from the above description it looks like it i= s 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. >=20 > =20 > Right, "raw" on top of "spicebd" for iso/raw images (and "qcow2" on top > for snapshot support - even in readonly). >=20 > I wonder what would happen if spicebd image would be something else tha= n > raw/iso, I suppose there would be more BlockDriverStates to handle the > various format. >=20 > --=20 > Marc-Andr=E9 Lureau