All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Avi Kivity <avi@redhat.com>, Paul Brook <paul@codesourcery.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] drive_add vs. pci_add
Date: Thu, 25 Jun 2009 23:09:44 +0200	[thread overview]
Message-ID: <4A43E798.3060303@web.de> (raw)
In-Reply-To: <4A43C1D8.1000100@codemonkey.ws>

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

Anthony Liguori wrote:
> Paul Brook wrote:
>> On Thursday 25 June 2009, Avi Kivity wrote:
>>  
>>> On 06/25/2009 09:46 AM, Jan Kiszka wrote:
>>>    
>>>> 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.
>>>>       
>>> What we really want is pci_add storage to add a storage controller, and
>>> drive_add to attach a drive to that controller.  I don't think that's
>>> what happens now.
>>>     
>>
>> 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.
>>   
> 
> 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:
> 
> # Create a new BlockDriverState with a symbolic name of 'Foo'
> (qemu) storage_add Foo file=/path/to/image,snapshot=on
> 
> # Create a new pci device with a symbolic name of 'Bar'
> (qemu) pci_create dev=virtio-blk,name=Bar

Support for creating pci devices and attaching storages offline would
surely be useful.

> 
> # Connect the storage backend Foo to the storage frontend Bar
> (qemu) storage_connect Foo Bar
> 
> # Attach PCI device via hotplug
> (qemu) pci_hotplug Bar addr=0.01.0
> 
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

  reply	other threads:[~2009-06-25 21:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-25  6:46 [Qemu-devel] drive_add vs. pci_add Jan Kiszka
2009-06-25  7:15 ` [Qemu-devel] " Jan Kiszka
2009-06-25 15:39 ` [Qemu-devel] " Avi Kivity
2009-06-25 16:02   ` Paul Brook
2009-06-25 18:28     ` Anthony Liguori
2009-06-25 21:09       ` Jan Kiszka [this message]
2009-06-25 22:18       ` Paul Brook
2009-06-25 16:07   ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A43E798.3060303@web.de \
    --to=jan.kiszka@web.de \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.