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

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


On Tue, 14 Dec 2021 at 09:52, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> You are still missing the point of how QEMU works:
> - QEMU creates a dummy VM with a single vcpu. This can happen on *any*
>   CPU.
> - It snapshots the sysregs for this vcpu, and keep them for later
> - It then destroy this VM
> - QEMU then creates the full VM, with all the vcpus
> - Each vcpu gets initialised with the state saved earlier. If any vcpu
>   is initialised on a physical CPU of a different type from the one
>   that has been used for the dummy VM, you lose, as we cannot restore
>   some of the registers such as MIDR_EL1 (and other registers that KVM
>   considers as invariant).

Put another way, QEMU's "-cpu host" is exactly one thing
(the "create a dummy VM and snapshot" steps above are where
QEMU defines what "-cpu host" means), and we have an implicit
assumption that the VM must only have one kind of guest CPU,
and not be heterogenous.

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

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 ?

-- PMM

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux