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

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

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.

    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.

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

On Mon, Sep 21, 2020 at 07:49:22AM +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.

Does it mean the plan is to drop intel-pt migration support
entirely?

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

> > 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?

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

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

> > > > 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 for the comments and suggestions. I think the newer CPU includes all the features of the older CPU, but no document have such statement. To make sure it can work in all the cases, the solution (1) might be better.
The Intel PT virtualization first supported on Icelake and we can use this CPUID as basic CPUID information. Any new feature which supports on the newer CPUs can be added by "-cpu ...,+feat,feat=...". What is your opinion?

Thanks,
Luwei Kang

On Thu, Sep 24, 2020 at 12:47:04PM +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 for the comments and suggestions. I think the newer CPU
> includes all the features of the older CPU, but no document
> have such statement. To make sure it can work in all the cases,
> the solution (1) might be better.

Maybe (2) is still viable, as long as there are no expectations
that features will be removed in future hardware.  Compatibility
with future hardware in (2) is more about convenience, not a hard
a requirement.

In either case, (1) is the building block for making (2) work.
This means we can start by implementing (1), and see if we can
include features in new CPU models later.

> The Intel PT virtualization first supported on Icelake and we
> can use this CPUID as basic CPUID information. Any new feature
> which supports on the newer CPUs can be added by "-cpu
> ...,+feat,feat=...". What is your opinion?

Sounds good to me.  I would also make intel-pt passthrough work
if using "-cpu host" and/or an explicit "intel-pt-passthrough=on"
option.

-- 
Eduardo

> > > > > > 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 for the comments and suggestions. I think the newer CPU
> > includes all the features of the older CPU, but no document have such
> > statement. To make sure it can work in all the cases, the solution (1)
> > might be better.
> 
> Maybe (2) is still viable, as long as there are no expectations that features will
> be removed in future hardware.  Compatibility with future hardware in (2) is
> more about convenience, not a hard a requirement.
> 
> In either case, (1) is the building block for making (2) work.
> This means we can start by implementing (1), and see if we can include
> features in new CPU models later.

OK, I will add the new sub-feature of Intel PT base on the solution (1).

Regarding the limitation of IP payload, may I remove this limitation directly because LIP == RIP for most/all real code, and it will be set after ICX CPUs.
[PATCH v1 1/3] i386: Remove the limitation of IP payloads for Intel PT

Thanks,
Luwei Kang

> 
> > The Intel PT virtualization first supported on Icelake and we can use
> > this CPUID as basic CPUID information. Any new feature which supports
> > on the newer CPUs can be added by "-cpu ...,+feat,feat=...". What is
> > your opinion?
> 
> Sounds good to me.  I would also make intel-pt passthrough work if using "-cpu
> host" and/or an explicit "intel-pt-passthrough=on"
> option.
> 
> --
> Eduardo