From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Chao Peng <chao.p.peng@linux.intel.com>
Subject: Re: Live migration regarding Intel PT
Date: Thu, 26 Aug 2021 10:16:26 +0800 [thread overview]
Message-ID: <3d098ac3-e757-a26f-8bf8-e74e711ca09e@intel.com> (raw)
In-Reply-To: <20210825204813.tfhrj3dg2vlqxm4u@habkost.net>
On 8/26/2021 4:48 AM, Eduardo Habkost wrote:
> On Wed, Aug 25, 2021 at 02:59:37PM +0800, Xiaoyao Li wrote:
>> Hi Eduardo,
>>
>> I have some question regrading Intel PT live migration.
>>
>> Commit "e37a5c7fa459 (i386: Add Intel Processor Trace feature support)"
>> expose Intel PT with a fixed capabilities of CPUID 0x14 for live migration.
>> And the fixed capabilities are the value reported on ICX(IceLake). However,
>> the upcoming SPR(Sapphire Rapids) has less capabilities of
>> INTEL_PT_CYCLE_BITMAP than ICX. It fails to enable PT in guest on SPR
>> machine.
>>
>> If change the check on INTEL_PT_CYCLE_BITMAP to allow different value to
>> allow it work on SPR. I think it breaks live migration, right?
>
> If I understand your description correctly, I don't think that
> would break live migration.
>
> Generating different CPUID data for the same CPU model+flags
> would break live migration.
>
> However, merely allowing a wider set of configurations to work
> wouldn't break live migration, as long as the same CPU
> model+flags generates the same CPUID data on any host.
The easy fix in my brain to make PT work on SPR guest surely will lead
to different CPUID data between ICX and SPR. That's why I wrote the email.
Other questions about live migration. I think a named CPU model is the
pre-condition for live migration, right?
Then is "same QEMU version/binary" the pre-condition for live migration
as well?
>
>>
>> For me, not making each sub-function of PT as configurable in QEMU indeed
>> makes it hard for live migration. [...]
>
> Making all sub-functions of PT configurable would be welcome.
> actually. That would allow us to support a wider range of
> configurations and keep live migration working at the same time.
I think it will break old QEMU? Is it OK?
>
>> [...] Why not make PT as unmigratable in the
>> first place when introducing the support in QEMU?
>
> I don't know, this was not my decision. Now we support live
> migration in a few specific cases (ICX hosts), and I assume we
> don't want to stop supporting it.
>
> If you just want to support a larger set of hosts when live
> migration is not needed, you can add support to that use case
> too. e.g.: "-cpu host,migratable=off" and/or
> "-cpu ...,intel-pt-passthrough=on" could do host passthrough of
> intel-pt sub-leaves (and block live migration).
>
That will make things complicated that old use case "-cpu ...,+intel-pt"
still means supporting live migration. And when use "-cpu
...,+intel-pt", QEMU needs to generate fixed PT capability as previous?
next prev parent reply other threads:[~2021-08-26 2:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-25 6:59 Live migration regarding Intel PT Xiaoyao Li
2021-08-25 20:48 ` Eduardo Habkost
2021-08-26 2:16 ` Xiaoyao Li [this message]
2021-08-26 15:14 ` Eduardo Habkost
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=3d098ac3-e757-a26f-8bf8-e74e711ca09e@intel.com \
--to=xiaoyao.li@intel.com \
--cc=chao.p.peng@linux.intel.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).