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: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 20:36 [Qemu-devel] [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support Luwei Kang
2018-01-08 20:36 ` [Qemu-devel] [PATCH RESEND v1 2/2] i386: Add support to get/set/migrate Intel Processor Trace feature Luwei Kang
2018-01-12 14:22 ` [Qemu-devel] [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support Eduardo Habkost
2018-01-15 7:19 ` Kang, Luwei
2018-01-15 9:33 ` Paolo Bonzini
2018-01-15 14:04 ` Eduardo Habkost [this message]
2018-01-15 14:25 ` Jiri Denemark
2018-01-15 14:31 ` Eduardo Habkost
2018-01-16 6:10 ` Kang, Luwei
2018-01-16 11:51 ` Eduardo Habkost
2018-01-17 10:32 ` Kang, Luwei
2018-01-18 2:42 ` Eduardo Habkost
2018-01-18 5:33 ` Kang, Luwei
2018-01-18 13:24 ` Eduardo Habkost
2018-01-18 13:39 ` Paolo Bonzini
2018-01-18 14:37 ` Eduardo Habkost
2018-01-18 14:44 ` Paolo Bonzini
2018-01-18 16:52 ` Eduardo Habkost
2018-01-18 16:53 ` Paolo Bonzini
2018-01-22 10:36 ` Kang, Luwei
2018-01-26 9:19 ` Paolo Bonzini
2018-01-22 10:45 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).