On Thu, Sep 03, 2020 at 19:50:13 +0800, Zhenyu Zheng wrote:
> Hi,
>
> Thanks alot for the review and feedback. As for host-passthrough cases, I
> have some other understandings,
> if I understand correctly, what you mean is that if a vm uses
> host-passthrough, it can migrate to any other
> host, since it asks for host-passthrough. In my point of view, I think in
> real cases, there are few different kinds
> of ARM datacenter CPUs on the market, and there CPU capabilities are
> different, so one might create a vm on
> hostA with feature1 and feature2 because it uses host-passthrough and hostA
> has these features. Now in your
> definition(if I understand correctly) of host-passthrough and the current
> code(returns identical directly), this vm
> can be migrated to hostB with only feature1, since there are no
> limitations. If one has some important application
> that depends on feature2, the app will break as feature2 is not available
> on hostB.

And that's why migrating a domain with host-passthrough CPU is generally
not supported. It should work if you have two identical hosts in terms
of CPU, microcode (if applicable to ARM), system settings (not sure
about ARM, but x86 let's you hide some CPU features), kernel and its
command line arguments, kvm modules and their options, and QEMU. If any
of this is different the guest CPU may change in an unexpected way
during migration and there's no way libvirt could know about it or
prevent it in general.

Even if we made the change and compared CPU features, the CPUs may have
other features which libvirt does not know about or the CPUs could even
differ in other aspects which libvirt does not cover in the CPU modeling
code.

But thinking about this and your patch, I guess I know what you are
trying to do. You're not trying to compare the CPU definition from a
domain XML (which was the primary use case for CPU comparison APIs), but
you want to compare the host CPU definition from one host to the host
CPU on the other host to see whether the two hosts might be compatible.

This sounds like a valid use case (not sure it is that useful), but we
need to be careful. But we should make sure implementing this does not
break anything. This means, we need to do different things depending on
the type of the CPU definition we are asked to compare. Guest CPU
definitions should keep the old behaviour (return IDENTICAL) and host
CPU definitions can be compared to the host CPU. But when doing so,
don't get too influenced by x86 code, which I believe is way too
complicated for ARM. Specifically you don't need to create armCompute
and mess with guestData and other stuff there as all you want to do is
compare the two CPU definitions. In x86 the same function is used for
several things, but that's not the case for ARM.

> Considering this, I proposed to add basic checks to compare CPU to
> limit the migration to only the same CPU models. And once the
> capability of ARM driver is enhanced in QEMU or other related
> projects, we can make the compare API better.

Sure, but that would be comparing guest CPU definition with the CPU we
get from QEMU rather than the one we detect ourselves.

Jirka