Re: [PATCH] Modify virCPUarmCompare to perform compare actions
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