From: Eduardo Habkost <ehabkost@redhat.com> To: "Kang, Luwei" <luwei.kang@intel.com> Cc: "Strong, Beeman" <beeman.strong@intel.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Robert Hoo <robert.hu@linux.intel.com>, "pbonzini@redhat.com" <pbonzini@redhat.com>, Jiri Denemark <jdenemar@redhat.com>, "rth@twiddle.net" <rth@twiddle.net> Subject: Re: [PATCH v1 0/3] Remove the limitation of Intel PT CPUID info Date: Wed, 23 Sep 2020 10:15:02 -0400 Message-ID: <20200923141502.GO2044576@habkost.net> (raw) In-Reply-To: <CY4PR11MB144737577341CF0A5E8BAD1C80380@CY4PR11MB1447.namprd11.prod.outlook.com> On Wed, Sep 23, 2020 at 02:52:50AM +0000, Kang, Luwei wrote: > > > Hi Eduardo, > > > This patch set will remove some limitations of Intel PT CPUID information. > > > 1. The "IP payloads" feature will disable the Intel PT in guests and it will be > > coming soon. > > > 2. To make the live migration safe, we set the Intel PT CPUID as a constant > > value(Icelake server CPUID). It will mask off the new feature of Intel PT. > > > > Isn't this series doing the opposite of 2? It replaces all constant CPUID values > > with kvm_arch_get_supported_cpuid(), making the feature unavailable in > > migration-safe mode. > > Yes, This series will expose all the HW capabilities to KVM > guest if the Intel PT is supported in the guest. > > > > > Does it mean the plan is to drop intel-pt migration support entirely? > > I don't want to drop intel-pt live migration feature. As > discussed with you before, the Intel PT feature includes some > sub-features and may be different on each HW platform. Expose > all the capabilities to the guest can't make live migration > safe. Do you have any new proposals? To support live migration, we need the set of features seen by the guest be determined only by the input given to QEMU, not host capabilities. It can be via: (1) explicit "-cpu ...,+feat,feat=..." flags; (2) through data in the CPU model table; or (3) by hardcoding the same value for all configurations. The current solution is (3). (2) is probably the best solution, with the assumption that the host can always emulate features from an older CPU in a newer CPU. If there are features that can't be emulated if migrating to a newer CPU, a more explicit configuration mechanism (1) might be better, because not being able to migrate a VM to newer hardware is inconvenient. None of those approaches prevent us from implementing passthrough mode for "-cpu host". Wouldn't that be preferred instead of removing support for live migration? > > Thanks, > Luwei Kang > > > > > > > > > About this issue https://bugzilla.redhat.com/show_bug.cgi?id=1853972, > > Intel PT is disabled in the guest by default, we should use "-cpu Icelake- > > Server,+intel-pt" to enable the Intel PT. > > > > That's correct. The point of the BZ is that libvirt mode=host-model was > > expected to include intel-pt automatically when available. With this series, the > > request in the BZ stops making sense (because intel-pt won't be migration-safe > > anymore), but I'm not sure yet that's really the plan. > > > > > > > > > > Thanks, > > > Luwei Kang > > > > > > > -----Original Message----- > > > > From: Eduardo Habkost <ehabkost@redhat.com> > > > > Sent: Saturday, September 19, 2020 6:03 AM > > > > To: Kang, Luwei <luwei.kang@intel.com> > > > > Cc: pbonzini@redhat.com; rth@twiddle.net; qemu-devel@nongnu.org; > > > > Strong, Beeman <beeman.strong@intel.com>; Jiri Denemark > > > > <jdenemar@redhat.com>; Robert Hoo <robert.hu@linux.intel.com> > > > > Subject: Re: [PATCH v1 0/3] Remove the limitation of Intel PT CPUID > > > > info > > > > > > > > Hi Luwei Kang, > > > > > > > > I was looking for info on intel-pt and just saw this series, and it > > > > was never reviewed or merged (sorry for missing it!). Is this still > > > > the approach we want to follow for intel-pt? > > > > > > > > I'm CCing Jiri Denemark because this might be relevant for a libvirt > > > > issue related to intel-pt we were investigating[1]. > > > > > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1853972 > > > > > > > > > > > > On Mon, Mar 30, 2020 at 09:56:09AM +0000, Kang, Luwei wrote: > > > > > > -----Original Message----- > > > > > > From: Kang, Luwei <luwei.kang@intel.com> > > > > > > Sent: Tuesday, February 25, 2020 5:38 AM > > > > > > To: pbonzini@redhat.com; rth@twiddle.net; ehabkost@redhat.com > > > > > > Cc: qemu-devel@nongnu.org; Strong, Beeman > > > > <beeman.strong@intel.com>; > > > > > > Kang, Luwei <luwei.kang@intel.com> > > > > > > Subject: [PATCH v1 0/3] Remove the limitation of Intel PT CPUID > > > > > > info > > > > > > > > > > > > The Intel PT feature includes some > > > > > > sub-features(CPUID.(EAX=14H,ECX=0H)) > > > > > > and these sub-features are different on different HW platforms. > > > > > > To make the live migration safety(get the same CPUID info with > > > > > > same cpu model on different HW platform), the current Intel PT > > > > > > CPUID information is set to a constant value(from ICELAKE Server). > > > > > > > > > > > > It will block the new feature in the later HW platform. what's > > > > > > more, the support of "IP payloads" will disable the Intel PT in > > > > > > KVM guest(patch 1) but it will come soon. > > > > > > > > > > > > This patchset remove this limitation and expose all the > > > > > > capabilities to KVM guest. As it will break the live migration > > > > > > safe, Intel PT will be masked as unmigratable. > > > > > > > > > > Ping. > > > > > > > > > > Thanks, > > > > > Luwei Kang > > > > > > > > > > > > > > > > > Luwei Kang (3): > > > > > > i386: Remove the limitation of IP payloads for Intel PT > > > > > > i386: Remove the CPUID limitation of Intel PT > > > > > > i386: Mark the 'INTEL_PT' CPUID bit as unmigratable > > > > > > > > > > > > target/i386/cpu.c | 69 > > > > > > ++++--------------------------------------------------- > > > > > > 1 file changed, 5 insertions(+), 64 deletions(-) > > > > > > > > > > > > -- > > > > > > 1.8.3.1 > > > > > > > > > > > > > -- > > > > Eduardo > > > > > > > -- > > Eduardo > -- Eduardo
next prev parent reply index Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-24 21:38 Luwei Kang 2020-02-24 21:38 ` [PATCH v1 1/3] i386: Remove the limitation of IP payloads for Intel PT Luwei Kang 2020-09-25 16:15 ` Eduardo Habkost 2020-09-25 16:42 ` Strong, Beeman 2020-09-25 16:54 ` Eduardo Habkost 2020-09-25 20:23 ` Paolo Bonzini 2020-09-25 20:29 ` Eduardo Habkost 2020-09-25 20:40 ` Paolo Bonzini 2020-09-28 5:19 ` Kang, Luwei 2020-09-28 7:35 ` Paolo Bonzini 2020-09-28 12:42 ` Kang, Luwei 2020-09-28 14:12 ` Eduardo Habkost 2020-09-29 2:28 ` Kang, Luwei 2020-09-29 3:44 ` Eduardo Habkost 2020-09-28 16:46 ` Paolo Bonzini 2020-09-29 2:28 ` Kang, Luwei 2020-02-24 21:38 ` [PATCH v1 2/3] i386: Remove the CPUID limitation of " Luwei Kang 2020-02-24 21:38 ` [PATCH v1 3/3] i386: Mark the 'INTEL_PT' CPUID bit as unmigratable Luwei Kang 2020-03-30 9:56 ` [PATCH v1 0/3] Remove the limitation of Intel PT CPUID info Kang, Luwei 2020-09-18 22:02 ` Eduardo Habkost 2020-09-21 7:49 ` Kang, Luwei 2020-09-21 16:50 ` Eduardo Habkost 2020-09-23 2:52 ` Kang, Luwei 2020-09-23 14:15 ` Eduardo Habkost [this message] 2020-09-24 12:47 ` Kang, Luwei 2020-09-24 13:34 ` Eduardo Habkost 2020-09-25 8:20 ` 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=20200923141502.GO2044576@habkost.net \ --to=ehabkost@redhat.com \ --cc=beeman.strong@intel.com \ --cc=jdenemar@redhat.com \ --cc=luwei.kang@intel.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=robert.hu@linux.intel.com \ --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
QEMU-Devel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git git clone --mirror https://lore.kernel.org/qemu-devel/2 qemu-devel/git/2.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \ qemu-devel@nongnu.org public-inbox-index qemu-devel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git