>>
>> I guess there will be quite some issues to be sorted out.
>>
>
> That's what I'm getting from the several feedback I got so far. But the
> more fundamental question is about the need for it. If you think this
> goes in the right direction to make things more generic and
> architecture agnostic, it might be worth the effort of trying to design
> such solution. If instead you think this will be reinventing the wheel
> and will not benefit any use case, then let's not waste some time on
> this.
>
I think, the general cpu hotplug/unplug infrastructure in QEMU is pretty
much generic. The only special case most probably is hotplugging
different topologies. But the general "device_add $MODEL-$ARCH-cpu,
id=$ID..." + device_del $ID is most probably easy to deal with by QEMU
users.
The main issue I think really is different hot(un)plug support per
architecture. We heard that there might be a solution for s390x soon. I
wonder what about other architectures.
Of course, if people want to scrap ACPI completely, then
a) we don't have CPU hot(un)plug for x86-64
b) we need virtio-cpu
c) we need a paravirt layer on top that is able to tell the guest to not
use a certain CPU and account for such CPUs in QEMU.
c) would be something like ballooning for memory. Start your guest with
many CPUs but tell it to offline X CPUs. Account the number of CPUs
actually used in the hypervisor (fairly easy). Of course, whenever it
comes to ballooning, you can't really differentiate between a sane guest
("uses all CPUs because it is not aware of the paravirt interface") and
malicious guests ("uses all CPUs because he knows how to activate them").
Especially, when the guests starts up, it might use all CPUs, until the
point where the virtio-whatever module is loaded and offlines the
requested amount of CPUs. Only from that point on, you could detect
malicious guests.
But there is always the option to limit the compute power using cgroups
in addition. So if the guest uses more CPUs than requested, there might
be an performance impact.
--
Thanks,
David / dhildenb
