[libvirt] [RFC PATCH 00/12] qemu: add support to hot-plug/unplug cpu device

Daniel P. Berrange berrange at redhat.com
Thu Jan 22 10:06:16 UTC 2015


On Thu, Jan 22, 2015 at 04:55:02PM +0800, Zhu Guihua wrote:
> On Wed, 2015-01-21 at 09:42 +0000, Daniel P. Berrange wrote:
> > On Wed, Jan 21, 2015 at 04:00:52PM +0800, Zhu Guihua wrote:
> > > If you apply the folowing patchset
> > > [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support
> > > https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg01552.html,
> > > and [PATCH v2 00/11] cpu: add i386 cpu hot remove support
> > > https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg01557.html,
> > > qemu can support hotplug and hot-unplug cpu device.
> > > 
> > > So this patch series will make libvirt support hotplug and hot-unplug cpu
> > > device for qemu driver, and now only supports one cpu driver which is
> > > 'qemu64-x86_64-cpu'.
> > > 
> > > The cpu device's xml like this:
> > > <cpu driver='qemu64-x86_64-cpu' apic_id='3'>
> > 
> > Do we really need to expose this 'qemu64-x86_64-cpu' string to apps.
> > It feels like a rather low level QEMU private implementation detail
> > to me that apps should not need to know or care about. I think libvirt
> > should always just do the right thing to make cpu hotplug work.
> > 
> 
> There is a need to use more cpu model. 
> 'qemu64-x86_64-cpu' is only one example, we will realize more driver in
> future.

Can you give an example of why we will need more than one model ? It seems
pretty crazy to me that we will need to specify two CPU models for CPUs,
both "Nehalem" / "Opteron" / etc and this new CPU model. It makes little
sense from the user / app POV IMHO.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list