Re: [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support

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

 



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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux