qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 0/3] Remove the limitation of Intel PT CPUID info


From: Eduardo Habkost
Subject: Re: [PATCH v1 0/3] Remove the limitation of Intel PT CPUID info
Date: Wed, 23 Sep 2020 10:15:02 -0400

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]