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]

 



[...]
> 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.
>

Hi Daniel,
 
Maybe I misunderstood your meaning. Next I will let you know what we
think in detail.

libvirt already implements Vcpu hotplug for qemu driver by qemu command
'cpu-add', but Vcpu hot-unplug has not been implemented.

qemu prefers to implement Vcpu hotplug by command 'device_add' instead
of 'cpu-add', implement Vcpu hotplug by command 'device_del' in future.

So, according to the above, our team has the following two methods to
implement Vcpu hotplug/un-plug in libvirt.

1) improve the existing API, and use the old command 'setVcpus'.

This method will invoke qemu's command 'device_add' instead of
'cpu-add'.

This method has three problems:
    a) can not specific the cpu' model. This will change qemu's design
       for cpu hotplug.
    b) can not keep consistent with other devices' hotplug in libvirt. 
    c) influence cpu's hot-unplug.  If device_add a cpu without id
       (i.e. device alias name in libvirt), cpu hot-unplug can not work.

2) Add a new API to support cpu hot-plug/unplug, and leave the the
existing API as a legacy.

This method will realize the feature by libvirt command 'attach-device',
and will allow user to specify the cpu model.
 
And in the future, we want to make struct virCPUDefPtr as a member of
the new defined struct for hotplugged cpu device, so that We can allow
user to set more details for cpu device, not only cpu model.

This method has two advantages.
    a) keep consistent with other devices' hotplug in libvirt.
    b) can assign device alias name. This is helpful for cpu hot-unplug.
 
The above is our opinion. May you give us some suggestions?

Regards,
Zhu

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