From: Eduardo Habkost <ehabkost@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
"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>,
libvir-list@redhat.com
Subject: Re: [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support
Date: Mon, 15 Jan 2018 12:31:56 -0200 [thread overview]
Message-ID: <20180115143156.GO6646@localhost.localdomain> (raw)
In-Reply-To: <20180115142518.GN1602429@orkuz.home>
On Mon, Jan 15, 2018 at 03:25:18PM +0100, Jiri Denemark wrote:
> On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > CCing libvirt developers.
> ...
> > 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.
> ...
> > [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)
>
> This is exactly what libvirt is doing (with model = "host") ever since
> query-cpu-model-expansion support was implemented for x86.
Oh, now I see that the x86 code uses
QEMU_MONITOR_CPU_MODEL_EXPANSION_STATIC_FULL and not just
QEMU_MONITOR_CPU_MODEL_EXPANSION_FULL. Nice!
--
Eduardo
WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
"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>,
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:31:56 -0200 [thread overview]
Message-ID: <20180115143156.GO6646@localhost.localdomain> (raw)
In-Reply-To: <20180115142518.GN1602429@orkuz.home>
On Mon, Jan 15, 2018 at 03:25:18PM +0100, Jiri Denemark wrote:
> On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > CCing libvirt developers.
> ...
> > 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.
> ...
> > [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)
>
> This is exactly what libvirt is doing (with model = "host") ever since
> query-cpu-model-expansion support was implemented for x86.
Oh, now I see that the x86 code uses
QEMU_MONITOR_CPU_MODEL_EXPANSION_STATIC_FULL and not just
QEMU_MONITOR_CPU_MODEL_EXPANSION_FULL. Nice!
--
Eduardo
next prev parent reply other threads:[~2018-01-15 14:32 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
2018-01-15 14:04 ` [Qemu-devel] " 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 [this message]
2018-01-15 14:31 ` 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=20180115143156.GO6646@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=chao.p.peng@linux.intel.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.