qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).