All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: Markus Armbruster <armbru@redhat.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	qemu-devel List <qemu-devel@nongnu.org>,
	Aurelien Jarno <aurelien@aurel32.net>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 4/5] Add generic drive hotplugging
Date: Tue, 24 Aug 2010 14:44:46 +0100	[thread overview]
Message-ID: <20100824134446.GM7376@redhat.com> (raw)
In-Reply-To: <4C73CBC9.4050602@suse.de>

On Tue, Aug 24, 2010 at 03:40:25PM +0200, Alexander Graf wrote:
> Daniel P. Berrange wrote:
> > On Tue, Aug 24, 2010 at 12:45:19PM +0200, Alexander Graf wrote:
> >   
> >> Daniel P. Berrange wrote:
> >>     
> >>> On Tue, Aug 24, 2010 at 12:02:30AM +0200, Alexander Graf wrote:
> >>>   
> >>>       
> >>>> The monitor command for hotplugging is in i386 specific code. This is just
> >>>> plain wrong, as S390 just learned how to do hotplugging too and needs to
> >>>> get drives for that.
> >>>>
> >>>> So let's add a generic copy to generic code that handles drive_add in a
> >>>> way that doesn't have pci dependencies.
> >>>>
> >>>> I'm not fully happy with the patch as is. IMHO there should only be a
> >>>> single target agnostic drive_hot_add function available. How we could
> >>>> potentially fit IF_SCSI in there I don't know though.
> >>>>     
> >>>>         
> >>> I'm not sure that this patch is actually neccessary. Via a undocumented,
> >>> sick, dirty hack, you can already use the current drive_add command
> >>> without a PCI address, for both virtio + scsi. In fact not using the
> >>> PCI address with drive_add is the preferred approach in the new qdev
> >>> world even on x86
> >>>   
> >>>       
> >> It is certainly necessary since the current code is in a big fat #if
> >> defined(TARGET_I386) block :).
> >>     
> >
> > True, true, killing the #ifdef is needed :-)
> >   
> 
> And moving it out of the pci specific file. Yeah :). Basically my
> proposal was to take the patches as is and phase out the pci-hotplug.c
> version.
> 
> >   
> >>> The key is that you should use  if=none for all cases. Here are two
> >>> examples of how libvirt does it currently:
> >>>
> >>> VirtIO:
> >>>
> >>>   drive_add dummy file=/var/lib/libvirt/images/data.img,if=none,id=drive-virtio-disk1,format=raw
> >>>   device_add virtio-blk-pci,bus=pci.0,addr=0x0,drive=drive-virtio-disk1,id=virtio-disk1'
> >>>
> >>> SCSI:
> >>>
> >>>   drive_add dummy file=/var/lib/libvirt/images/data.img,if=none,id=drive-scsi0-0-1,format=raw'
> >>>   device_add scsi-disk,bus=scsi0.0,scsi-id=1,drive=drive-scsi0-0-1,id=scsi0-0-1
> >>>
> >>> The 'dummy' value there can be absolutely anything you want.
> >>> It is totaly ignored when QEMU sees if=none in 2nd arg.
> >>>   
> >>>       
> >> I'd be all for removing the pci-hotplug.c version of drive_add then. But
> >> I think the IF_SCSI option there is to append a drive to an existing
> >> SCSI bus, no?
> >>     
> >
> > Actually this SCSI example I give above is appending a drive to an existing
> > bus (scsi0), in slot 1 (scsi-id=1).  To best of my knowledge there is no
> > remaining use case that requires use of IF_SCSI, IF_IDE, etc. The IF_NONE
> > approach can cope with all, modulo bugs that appear periodically with code
> > that mistakenly checks for a particular IF_XXX constant.
> >
> > If you wanted to also create a new SCSI bus, before creating the drive on
> > it, you'd need to run three commands in total:
> >
> >   device_add lsi,id=scsi0,bus=pci.0,addr=0x7
> >   drive_add dummy file=/var/lib/libvirt/images/data.img,if=none,id=drive-scsi0-0-1,format=raw
> >   device_add scsi-disk,bus=scsi0.0,scsi-id=1,drive=drive-scsi0-0-1,id=scsi0-0-1
> >   
> 
> Nice - so we can just deprecate if=!none?

In theory yes, but its not nice to tell users to switch everything over to
use if=none, if we're going to deprecate that too in the next release when
blockdev appears. Might as well just deprecate entire of drive_add/-drive
at once.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

  reply	other threads:[~2010-08-24 13:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-23 22:02 [Qemu-devel] [PATCH 0/5] Add S390 hotplug add support Alexander Graf
2010-08-23 22:02 ` [Qemu-devel] [PATCH 1/5] [S390] Add hotplug support Alexander Graf
2010-08-23 22:02 ` [Qemu-devel] [PATCH 2/5] [S390] Increase amount of virtio pages Alexander Graf
2010-08-23 22:02 ` [Qemu-devel] [PATCH 3/5] Compile device-hotplug on all targets Alexander Graf
2010-08-23 22:02 ` [Qemu-devel] [PATCH 4/5] Add generic drive hotplugging Alexander Graf
2010-08-23 22:21   ` Anthony Liguori
2010-08-23 22:23     ` Alexander Graf
2010-08-23 22:45       ` Alexander Graf
2010-08-23 22:50         ` Anthony Liguori
2010-08-23 22:54           ` Alexander Graf
2010-08-24  9:31   ` Daniel P. Berrange
2010-08-24 10:45     ` Alexander Graf
2010-08-24 10:51       ` Daniel P. Berrange
2010-08-24 13:40         ` Alexander Graf
2010-08-24 13:44           ` Daniel P. Berrange [this message]
2010-08-24 13:46             ` Alexander Graf
2010-08-24 13:51               ` Daniel P. Berrange
2010-08-27  9:27                 ` Markus Armbruster
2010-08-24 18:35             ` Anthony Liguori
2010-08-24 21:53               ` Alexander Graf
2010-08-27  9:53   ` Markus Armbruster
2010-08-27  9:56     ` Alexander Graf
2010-08-23 22:02 ` [Qemu-devel] [PATCH 5/5] Expose drive_add on all architectures Alexander Graf

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=20100824134446.GM7376@redhat.com \
    --to=berrange@redhat.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=aurelien@aurel32.net \
    --cc=kraxel@redhat.com \
    --cc=lcapitulino@redhat.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.