From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJwCm-0003o9-AC for qemu-devel@nongnu.org; Thu, 25 Jun 2009 17:10:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJwCh-0003n9-Rs for qemu-devel@nongnu.org; Thu, 25 Jun 2009 17:09:59 -0400 Received: from [199.232.76.173] (port=58662 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJwCh-0003n6-NO for qemu-devel@nongnu.org; Thu, 25 Jun 2009 17:09:55 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:58340) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJwCh-0003O4-2X for qemu-devel@nongnu.org; Thu, 25 Jun 2009 17:09:55 -0400 Message-ID: <4A43E798.3060303@web.de> Date: Thu, 25 Jun 2009 23:09:44 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] drive_add vs. pci_add References: <4A431D3D.2040604@web.de> <4A439A15.5040707@redhat.com> <200906251702.44505.paul@codesourcery.com> <4A43C1D8.1000100@codemonkey.ws> In-Reply-To: <4A43C1D8.1000100@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig93400D61495040F7694A7F88" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Avi Kivity , Paul Brook , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig93400D61495040F7694A7F88 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > Paul Brook wrote: >> On Thursday 25 June 2009, Avi Kivity wrote: >> =20 >>> On 06/25/2009 09:46 AM, Jan Kiszka wrote: >>> =20 >>>> Hi, >>>> >>>> sorry, it's still early, but isn't the monitor command 'drive_add' >>>> completely redundant to 'pci_add ... storage'? If yes, and drive_add= is >>>> only there for legacy users, I would mask its help from the monitor >>>> interface to avoid confusion. >>>> =20 >>> What we really want is pci_add storage to add a storage controller, a= nd >>> drive_add to attach a drive to that controller. I don't think that's= >>> what happens now. >>> =20 >> >> Part of the problem is that we don't currently isolate configs for >> different pats of the device stack. There are several different layers= >> at which hotplug can occur: >> >> - Device - e.g. PCI hotplug. If done properly this shouldn't care >> whether you're adding a NIC, VGA, SCSI HBA, or whatever. >> - Drive - Adding/removing drives to an existing HBA. >> - Media - e.g. changing the contents of a CDROM drive. >> =20 >=20 > Also, we probably want to separate the definition of storage from the > act of connecting the storage via hotplug. What would be the benefit of be able to define detached storages? > If I were going to add new > monitor commands today, I may do something like: >=20 > # Create a new BlockDriverState with a symbolic name of 'Foo' > (qemu) storage_add Foo file=3D/path/to/image,snapshot=3Don >=20 > # Create a new pci device with a symbolic name of 'Bar' > (qemu) pci_create dev=3Dvirtio-blk,name=3DBar Support for creating pci devices and attaching storages offline would surely be useful. >=20 > # Connect the storage backend Foo to the storage frontend Bar > (qemu) storage_connect Foo Bar >=20 > # Attach PCI device via hotplug > (qemu) pci_hotplug Bar addr=3D0.01.0 >=20 > Beyond pci_hotplug, you could also introduce pci_insert/remove > commands. This could be used if starting a guest in the stopped state > to insert a PCI card or in combination with -no-shutdown. Shouldn't this be handled more generically one day by (re-)reading a machine configuration (from a file or from a QMP session)? Jan --------------enig93400D61495040F7694A7F88 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpD56AACgkQniDOoMHTA+mwUwCfdA6XYOmK3go44Fm1VuEdu3vb I3cAn1obXzX8AO0fN5EML2/GCBlJiuDy =pNFC -----END PGP SIGNATURE----- --------------enig93400D61495040F7694A7F88--