Libvirt on little.BIG ARM systems unable to start guest if no cpuset is provided

Marc Zyngier maz at kernel.org
Tue Dec 14 10:33:53 UTC 2021


On Tue, 14 Dec 2021 10:08:29 +0000,
Peter Maydell <peter.maydell at linaro.org> wrote:
> 
> On Tue, 14 Dec 2021 at 09:52, Marc Zyngier <maz at kernel.org> wrote:
> > The best workaround is to taskset the QEMU process (and I really mean
> > the process, not individual threads) to an homogeneous set of CPUs and
> > be done with it.
> 
> Agreed. I suspect that often the 'little' CPUs are sufficiently
> low-power to probably not be worth giving to the VM anyway.

They are actually pretty beefy, in most cases. If you are I/O bound,
the small cores are the right target. This email is brought to you via
a couple of A55 CPUs running a VM and acting as my home gateway. If
'the internet' was getting slow, I'd have heard about it! ;-)

> Side note: if you *do* give a guest both big and little CPUs
> using kvmtool or something similar, does the guest kernel get
> enough information to schedule tasks properly to both kinds of
> CPU, or does it just assume they're all the same and happily
> put performance-requiring tasks on the little CPUs ?

Upstream kvmtool doesn't make any effort to do this, but I had a
series to perform such placement in the past. Once you know which
physical CPUs you are placing the vcpus on, you can extract the
individual CPU capacity[1] and expose it in the guest's DT as a
cpu-specific 'capacity-dmips-mhz' property. A Linux guest will take
the hint and do the right thing.

	M.

[1] /sys/devices/system/cpu/cpu*/cpu_capacity

-- 
Without deviation from the norm, progress is not possible.




More information about the libvirt-users mailing list