From: Eduardo Habkost <ehabkost@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Kang, Luwei" <luwei.kang@intel.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"rth@twiddle.net" <rth@twiddle.net>,
"mtosatti@redhat.com" <mtosatti@redhat.com>,
Chao Peng <chao.p.peng@linux.intel.com>,
Jiri Denemark <jdenemar@redhat.com>,
libvir-list@redhat.com
Subject: Re: [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support
Date: Mon, 15 Jan 2018 12:04:55 -0200 [thread overview]
Message-ID: <20180115140455.GN6646@localhost.localdomain> (raw)
In-Reply-To: <97bf8d29-4009-6f61-f4bb-d128da5a4c9f@redhat.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Kang, Luwei" <luwei.kang@intel.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"rth@twiddle.net" <rth@twiddle.net>,
"mtosatti@redhat.com" <mtosatti@redhat.com>,
Chao Peng <chao.p.peng@linux.intel.com>,
Jiri Denemark <jdenemar@redhat.com>,
libvir-list@redhat.com
Subject: Re: [Qemu-devel] [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support
Date: Mon, 15 Jan 2018 12:04:55 -0200 [thread overview]
Message-ID: <20180115140455.GN6646@localhost.localdomain> (raw)
In-Reply-To: <97bf8d29-4009-6f61-f4bb-d128da5a4c9f@redhat.com>
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
next prev parent reply other threads:[~2018-01-15 14:05 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 20:36 [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support Luwei Kang
2018-01-08 20:36 ` [Qemu-devel] " Luwei Kang
2018-01-08 20:36 ` [PATCH RESEND v1 2/2] i386: Add support to get/set/migrate Intel Processor Trace feature Luwei Kang
2018-01-08 20:36 ` [Qemu-devel] " Luwei Kang
2018-01-12 14:22 ` [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support Eduardo Habkost
2018-01-12 14:22 ` [Qemu-devel] " Eduardo Habkost
2018-01-15 7:19 ` Kang, Luwei
2018-01-15 7:19 ` [Qemu-devel] " Kang, Luwei
2018-01-15 9:33 ` Paolo Bonzini
2018-01-15 9:33 ` [Qemu-devel] " Paolo Bonzini
2018-01-15 14:04 ` Eduardo Habkost [this message]
2018-01-15 14:04 ` Eduardo Habkost
2018-01-15 14:25 ` Jiri Denemark
2018-01-15 14:25 ` [Qemu-devel] " Jiri Denemark
2018-01-15 14:31 ` Eduardo Habkost
2018-01-15 14:31 ` [Qemu-devel] " Eduardo Habkost
2018-01-16 6:10 ` Kang, Luwei
2018-01-16 6:10 ` [Qemu-devel] " Kang, Luwei
2018-01-16 11:51 ` Eduardo Habkost
2018-01-16 11:51 ` [Qemu-devel] " Eduardo Habkost
2018-01-17 10:32 ` Kang, Luwei
2018-01-17 10:32 ` [Qemu-devel] " Kang, Luwei
2018-01-18 2:42 ` Eduardo Habkost
2018-01-18 2:42 ` [Qemu-devel] " Eduardo Habkost
2018-01-18 5:33 ` Kang, Luwei
2018-01-18 5:33 ` [Qemu-devel] " Kang, Luwei
2018-01-18 13:24 ` Eduardo Habkost
2018-01-18 13:24 ` [Qemu-devel] " Eduardo Habkost
2018-01-18 13:39 ` Paolo Bonzini
2018-01-18 13:39 ` [Qemu-devel] " Paolo Bonzini
2018-01-18 14:37 ` Eduardo Habkost
2018-01-18 14:37 ` [Qemu-devel] " Eduardo Habkost
2018-01-18 14:44 ` Paolo Bonzini
2018-01-18 14:44 ` [Qemu-devel] " Paolo Bonzini
2018-01-18 16:52 ` Eduardo Habkost
2018-01-18 16:52 ` [Qemu-devel] " Eduardo Habkost
2018-01-18 16:53 ` Paolo Bonzini
2018-01-18 16:53 ` [Qemu-devel] " Paolo Bonzini
2018-01-22 10:36 ` Kang, Luwei
2018-01-22 10:36 ` [Qemu-devel] " Kang, Luwei
2018-01-26 9:19 ` Paolo Bonzini
2018-01-26 9:19 ` [Qemu-devel] " Paolo Bonzini
2018-01-22 10:45 ` Kang, Luwei
2018-01-22 10:45 ` [Qemu-devel] " Kang, Luwei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180115140455.GN6646@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=chao.p.peng@linux.intel.com \
--cc=jdenemar@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=libvir-list@redhat.com \
--cc=luwei.kang@intel.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.