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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 22, 2015 at 07:02:27PM +0800, Zhu Guihua wrote:
> On Thu, 2015-01-22 at 10:06 +0000, Daniel P. Berrange wrote:
> > 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.
> > 
> 
> In future, this will become an advanced feature for specific user. If
> user may not specific a model, we will specific a default model.
> 
> I think this feature is mainly for test environment. If you want to test
> different cpu model's performance, this feature will be essential.

The choice of Nehalem, Opteron, etc as CPU models is already supported
in QEMU and influences guest CPU performance.  You're not explaining why
we need to introduce multiple CPU <cpu driver='qemu64-x86_64-cpu'> values.
It makes no sense to have two different CPU models listed for the same
guest like this.

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 :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]