CCing libvirt developers.
On Mon, Jan 15, 2018 at 10:33:35AM +0100, Paolo Bonzini wrote:
> On 15/01/2018 08:19, Kang, Luwei wrote:
> >> If you are forwarding host info directly to the guest, the feature
> >> is not migration-safe. The new feature needs to be added to
> >> feature_word_info[FEAT_7_0_EBX].unmigratable_flags.
> >>
> > Hi, Thanks for you review. I want to support Intel PT live migration
> > and patch [2/2] to do this. I don't understand why need to add this
> > feature in feature_word_info[FEAT_7_0_EBX].unmigratable_flags first
> > to disable live migration.
>
> Hi Luwei,
>
> the issue is that different hosts can have different CPUID flags. You
> don't have a way to set the CPUID flags from the "-cpu" command line,
> and it's not clear what values will be there in the various Ice Lake SKUs.
>
> I am not sure if there is a mechanism to allow live migration only for
> "-cpu host", but it cannot be supported for any other "-cpu" model.
IIRC, we don't have any mechanism to actually prevent migration
if an unmigratable flag is enabled. We just avoid enabling them
by accident on "-cpu host".
This case is slightly more problematic, however: the new feature
is actually migratable (under very controlled circumstances)
because of patch 2/2, but it is not migration-safe[1]. This
means libvirt shouldn't include it in "host-model" expansion
(which uses the query-cpu-model-expansion QMP command) until we
make the feature migration-safe.
For QEMU, this means the feature shouldn't be returned by
"query-cpu-model-expansion type=static model=max" (but it can be
returned by "query-cpu-model-expansion type=full model=max").
Jiri, it looks like libvirt uses type=full on
query-cpu-model-expansion on x86. It needs to use
type=static[2], or it will have no way to find out if a feature
is migration-safe or not.
This case is similar to "pmu", which is not migration-safe but
enabled by -cpu host by default. But "pmu" is less problematic
because it is already skipped by query-cpu-model-expansion
type=static.
---
[1] "migration-safe" is defined in the documentation for CpuDefinitionInfo on
the QAPI schema:
# @migration-safe: whether a CPU definition can be safely used for
# migration in combination with a QEMU compatibility machine
# when migrating between different QMU versions and between
# hosts with different sets of (hardware or software)
# capabilities. If not provided, information is not available
# and callers should not assume the CPU definition to be
# migration-safe. (since 2.8)
[2] It looks like libvirt uses type=full because it wants to get
all QOM property aliases returned. In this case, one
solution for libvirt is to use:
static_expansion = query_cpu_model_expansion(type=static, model)
all_props = query_cpu_model_expansion(type=full, static_expansion)
--
Eduardo
