The Intel PT packets which contain IP payloads will have LIP values, and it
will include the CS base component if the CPUID.(EAX=14H,ECX=0H).ECX.[bit31]
is set. But it will disabled the Intel PT in kvm guest because of the need
of live migration safe(c078ca9 i386: Disable Intel PT if packets IP payloads
have LIP values).
This patch will revert the previous limitation because the Intel new hardware
will set this bit and LIP == RIP for most/all real code.
Signed-off-by: Luwei Kang <luwei.kang@intel.com>
---
target/i386/cpu.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 69f518a..8c0d1e4 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -688,8 +688,6 @@ static CPUCacheInfo legacy_l3_cache = {
* bit[02]: Support Single-Range Output scheme;
*/
#define INTEL_PT_MINIMAL_ECX 0x7
-/* generated packets which contain IP payloads have LIP values */
-#define INTEL_PT_IP_LIP (1 << 31)
#define INTEL_PT_ADDR_RANGES_NUM 0x2 /* Number of configurable address ranges */
#define INTEL_PT_ADDR_RANGES_NUM_MASK 0x3
#define INTEL_PT_MTC_BITMAP (0x0249 << 16) /* Support ART(0,3,6,9) */
@@ -6281,8 +6279,7 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool verbose)
((eax_1 & INTEL_PT_ADDR_RANGES_NUM_MASK) <
INTEL_PT_ADDR_RANGES_NUM) ||
((ebx_1 & (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) !=
- (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) ||
- (ecx_0 & INTEL_PT_IP_LIP)) {
+ (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP))) {
/*
* Processor Trace capabilities aren't configurable, so if the
* host can't emulate the capabilities we report on
--
1.8.3.1
On Tue, Feb 25, 2020 at 05:38:30AM +0800, Luwei Kang wrote:
> The Intel PT packets which contain IP payloads will have LIP values, and it
> will include the CS base component if the CPUID.(EAX=14H,ECX=0H).ECX.[bit31]
> is set. But it will disabled the Intel PT in kvm guest because of the need
> of live migration safe(c078ca9 i386: Disable Intel PT if packets IP payloads
> have LIP values).
>
> This patch will revert the previous limitation because the Intel new hardware
> will set this bit and LIP == RIP for most/all real code.
"works most of the time" might be good enough if it's a conscious
user choice, but not for something we might be enabling by
default. Under which conditions this wouldn't work? Can we
detect those conditions somehow?
To allow live migration between LIP=0 and LIP=1 hosts, we need
KVM to be able to properly emulate LIP=0 on LIP=1 hosts. Does
the hardware make this possible?
If KVM can't emulate LIP=0 on a LIP=1 host, what you can do here
is to make the flag configurable and check if the configured
value matches the one in the host. This way we can support both
types of hosts, just not allow live migration between them.
>
> Signed-off-by: Luwei Kang <luwei.kang@intel.com>
> ---
> target/i386/cpu.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 69f518a..8c0d1e4 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -688,8 +688,6 @@ static CPUCacheInfo legacy_l3_cache = {
> * bit[02]: Support Single-Range Output scheme;
> */
> #define INTEL_PT_MINIMAL_ECX 0x7
> -/* generated packets which contain IP payloads have LIP values */
> -#define INTEL_PT_IP_LIP (1 << 31)
> #define INTEL_PT_ADDR_RANGES_NUM 0x2 /* Number of configurable address ranges */
> #define INTEL_PT_ADDR_RANGES_NUM_MASK 0x3
> #define INTEL_PT_MTC_BITMAP (0x0249 << 16) /* Support ART(0,3,6,9) */
> @@ -6281,8 +6279,7 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool verbose)
> ((eax_1 & INTEL_PT_ADDR_RANGES_NUM_MASK) <
> INTEL_PT_ADDR_RANGES_NUM) ||
> ((ebx_1 & (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) !=
> - (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) ||
> - (ecx_0 & INTEL_PT_IP_LIP)) {
> + (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP))) {
> /*
> * Processor Trace capabilities aren't configurable, so if the
> * host can't emulate the capabilities we report on
> --
> 1.8.3.1
>
--
Eduardo
LIP=0 will differ from LIP=1 behavior only when CSbase is non-zero, which requires 32-bit code. In that case a LIP=0 implementation will provide only the EIP offset from CSbase in IP packets (like TIP or FUP), while LIP=1 implementation will provide the full LIP (CSbase + EIP offset).
-----Original Message-----
From: Eduardo Habkost <ehabkost@redhat.com>
Sent: Friday, September 25, 2020 9:16 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>
Subject: Re: [PATCH v1 1/3] i386: Remove the limitation of IP payloads for Intel PT
On Tue, Feb 25, 2020 at 05:38:30AM +0800, Luwei Kang wrote:
> The Intel PT packets which contain IP payloads will have LIP values,
> and it will include the CS base component if the
> CPUID.(EAX=14H,ECX=0H).ECX.[bit31]
> is set. But it will disabled the Intel PT in kvm guest because of the
> need of live migration safe(c078ca9 i386: Disable Intel PT if packets
> IP payloads have LIP values).
>
> This patch will revert the previous limitation because the Intel new
> hardware will set this bit and LIP == RIP for most/all real code.
"works most of the time" might be good enough if it's a conscious user choice, but not for something we might be enabling by default. Under which conditions this wouldn't work? Can we detect those conditions somehow?
To allow live migration between LIP=0 and LIP=1 hosts, we need KVM to be able to properly emulate LIP=0 on LIP=1 hosts. Does the hardware make this possible?
If KVM can't emulate LIP=0 on a LIP=1 host, what you can do here is to make the flag configurable and check if the configured value matches the one in the host. This way we can support both types of hosts, just not allow live migration between them.
>
> Signed-off-by: Luwei Kang <luwei.kang@intel.com>
> ---
> target/i386/cpu.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c index
> 69f518a..8c0d1e4 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -688,8 +688,6 @@ static CPUCacheInfo legacy_l3_cache = {
> * bit[02]: Support Single-Range Output scheme;
> */
> #define INTEL_PT_MINIMAL_ECX 0x7
> -/* generated packets which contain IP payloads have LIP values */
> -#define INTEL_PT_IP_LIP (1 << 31)
> #define INTEL_PT_ADDR_RANGES_NUM 0x2 /* Number of configurable
> address ranges */ #define INTEL_PT_ADDR_RANGES_NUM_MASK 0x3
> #define INTEL_PT_MTC_BITMAP (0x0249 << 16) /* Support ART(0,3,6,9) */
> @@ -6281,8 +6279,7 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool verbose)
> ((eax_1 & INTEL_PT_ADDR_RANGES_NUM_MASK) <
> INTEL_PT_ADDR_RANGES_NUM) ||
> ((ebx_1 & (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) !=
> - (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) ||
> - (ecx_0 & INTEL_PT_IP_LIP)) {
> + (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP))) {
> /*
> * Processor Trace capabilities aren't configurable, so if the
> * host can't emulate the capabilities we report on
> --
> 1.8.3.1
>
--
Eduardo
On Fri, Sep 25, 2020 at 04:42:26PM +0000, Strong, Beeman wrote:
> LIP=0 will differ from LIP=1 behavior only when CSbase is non-zero, which requires 32-bit code. In that case a LIP=0 implementation will provide only the EIP offset from CSbase in IP packets (like TIP or FUP), while LIP=1 implementation will provide the full LIP (CSbase + EIP offset).
>
Thanks. Is it possible to make KVM emulate LIP=0 behavior
correctly on LIP=1 hosts, or vice versa?
> -----Original Message-----
> From: Eduardo Habkost <ehabkost@redhat.com>
> Sent: Friday, September 25, 2020 9:16 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>
> Subject: Re: [PATCH v1 1/3] i386: Remove the limitation of IP payloads for Intel PT
>
> On Tue, Feb 25, 2020 at 05:38:30AM +0800, Luwei Kang wrote:
> > The Intel PT packets which contain IP payloads will have LIP values,
> > and it will include the CS base component if the
> > CPUID.(EAX=14H,ECX=0H).ECX.[bit31]
> > is set. But it will disabled the Intel PT in kvm guest because of the
> > need of live migration safe(c078ca9 i386: Disable Intel PT if packets
> > IP payloads have LIP values).
> >
> > This patch will revert the previous limitation because the Intel new
> > hardware will set this bit and LIP == RIP for most/all real code.
>
> "works most of the time" might be good enough if it's a conscious user choice, but not for something we might be enabling by default. Under which conditions this wouldn't work? Can we detect those conditions somehow?
>
> To allow live migration between LIP=0 and LIP=1 hosts, we need KVM to be able to properly emulate LIP=0 on LIP=1 hosts. Does the hardware make this possible?
>
> If KVM can't emulate LIP=0 on a LIP=1 host, what you can do here is to make the flag configurable and check if the configured value matches the one in the host. This way we can support both types of hosts, just not allow live migration between them.
>
>
> >
> > Signed-off-by: Luwei Kang <luwei.kang@intel.com>
> > ---
> > target/i386/cpu.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c index
> > 69f518a..8c0d1e4 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -688,8 +688,6 @@ static CPUCacheInfo legacy_l3_cache = {
> > * bit[02]: Support Single-Range Output scheme;
> > */
> > #define INTEL_PT_MINIMAL_ECX 0x7
> > -/* generated packets which contain IP payloads have LIP values */
> > -#define INTEL_PT_IP_LIP (1 << 31)
> > #define INTEL_PT_ADDR_RANGES_NUM 0x2 /* Number of configurable
> > address ranges */ #define INTEL_PT_ADDR_RANGES_NUM_MASK 0x3
> > #define INTEL_PT_MTC_BITMAP (0x0249 << 16) /* Support ART(0,3,6,9) */
> > @@ -6281,8 +6279,7 @@ static void x86_cpu_filter_features(X86CPU *cpu, bool verbose)
> > ((eax_1 & INTEL_PT_ADDR_RANGES_NUM_MASK) <
> > INTEL_PT_ADDR_RANGES_NUM) ||
> > ((ebx_1 & (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) !=
> > - (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP)) ||
> > - (ecx_0 & INTEL_PT_IP_LIP)) {
> > + (INTEL_PT_PSB_BITMAP | INTEL_PT_CYCLE_BITMAP))) {
> > /*
> > * Processor Trace capabilities aren't configurable, so if the
> > * host can't emulate the capabilities we report on
> > --
> > 1.8.3.1
> >
>
> --
> Eduardo
>
--
Eduardo
On 25/09/20 18:54, Eduardo Habkost wrote: > On Fri, Sep 25, 2020 at 04:42:26PM +0000, Strong, Beeman wrote: >> LIP=0 will differ from LIP=1 behavior only when CSbase is non-zero, which requires 32-bit code. In that case a LIP=0 implementation will provide only the EIP offset from CSbase in IP packets (like TIP or FUP), while LIP=1 implementation will provide the full LIP (CSbase + EIP offset). >> > Thanks. Is it possible to make KVM emulate LIP=0 behavior > correctly on LIP=1 hosts, or vice versa? No, it's not possible. KVM doesn't have a say on what the processor writes in the tracing packets. Paolo
On Fri, Sep 25, 2020 at 10:23:49PM +0200, Paolo Bonzini wrote: > On 25/09/20 18:54, Eduardo Habkost wrote: > > On Fri, Sep 25, 2020 at 04:42:26PM +0000, Strong, Beeman wrote: > >> LIP=0 will differ from LIP=1 behavior only when CSbase is non-zero, which requires 32-bit code. In that case a LIP=0 implementation will provide only the EIP offset from CSbase in IP packets (like TIP or FUP), while LIP=1 implementation will provide the full LIP (CSbase + EIP offset). > >> > > Thanks. Is it possible to make KVM emulate LIP=0 behavior > > correctly on LIP=1 hosts, or vice versa? > > No, it's not possible. KVM doesn't have a say on what the processor > writes in the tracing packets. Can KVM refuse to enable packet generation if CSbase is not zero and CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from host? -- Eduardo
On 25/09/20 22:29, Eduardo Habkost wrote: >> No, it's not possible. KVM doesn't have a say on what the processor >> writes in the tracing packets. > Can KVM refuse to enable packet generation if CSbase is not zero > and CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from > host? Yes, but the processor could change operating mode (and hence CSbase) while tracing is active. This is very unlikely, since it would require nonzero CS-base and a 32-bit host, but in principle not impossible (could be a firmware call, for example). The only solution is for KVM to accept both, and for QEMU to refuse a setting that does not match the host. Paolo
> >> No, it's not possible. KVM doesn't have a say on what the processor > >> writes in the tracing packets. > > Can KVM refuse to enable packet generation if CSbase is not zero and > > CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from host? > > Yes, but the processor could change operating mode (and hence CSbase) while > tracing is active. This is very unlikely, since it would require nonzero CS-base > and a 32-bit host, but in principle not impossible (could be a firmware call, for > example). > > The only solution is for KVM to accept both, and for QEMU to refuse a setting > that does not match the host. > So I need to add a patch in KVM to disabled the Intel PT when the CSbase is not zero and the guest LIP different from the host. And this limitation in qemu (disabled the PT when LIP is enabled in the host) can be remove. Is that right? Thanks, Luwei Kang
On 28/09/20 07:19, Kang, Luwei wrote: >>>> No, it's not possible. KVM doesn't have a say on what the processor >>>> writes in the tracing packets. >>> Can KVM refuse to enable packet generation if CSbase is not zero and >>> CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from host? >> >> Yes, but the processor could change operating mode (and hence CSbase) while >> tracing is active. This is very unlikely, since it would require nonzero CS-base >> and a 32-bit host, but in principle not impossible (could be a firmware call, for >> example). >> >> The only solution is for KVM to accept both, and for QEMU to refuse a setting >> that does not match the host. >> > > So I need to add a patch in KVM to disabled the Intel PT when the > CSbase is not zero and the guest LIP different from the host. And this > limitation in qemu (disabled the PT when LIP is enabled in the host) can > be remove. Is that right? No, if a feature cannot be emulated, that means it cannot be enabled unless it matches the host. That's generally not a problem since Intel PT is usually used only with "-cpu host". Paolo
> >>>> No, it's not possible. KVM doesn't have a say on what the > >>>> processor writes in the tracing packets. > >>> Can KVM refuse to enable packet generation if CSbase is not zero and > >>> CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from host? > >> > >> Yes, but the processor could change operating mode (and hence CSbase) > >> while tracing is active. This is very unlikely, since it would > >> require nonzero CS-base and a 32-bit host, but in principle not > >> impossible (could be a firmware call, for example). > >> > >> The only solution is for KVM to accept both, and for QEMU to refuse a > >> setting that does not match the host. > >> > > > > So I need to add a patch in KVM to disabled the Intel PT when the > > CSbase is not zero and the guest LIP different from the host. And this > > limitation in qemu (disabled the PT when LIP is enabled in the host) > > can be remove. Is that right? > > No, if a feature cannot be emulated, that means it cannot be enabled unless it > matches the host. That's generally not a problem since Intel PT is usually used > only with "-cpu host". > The limitation of LIP in qemu will mask off the Intel PT in KVM guest even with "-cpu host". e.g. This bit will be set in SnowRidge HW and later. How about "-cpu cpu_model, +intel-pt" use case? The current value of Intel PT CPUID is a constant. Can we make the ICX CPUID as basic inforation(LIP is 0) and using "+intel-pt-lip" to make Intel PT work on the CPU which LIP is 1 on the host? As you mentioned before, Intel PT cannot be enabled in guest unless it matches the host. Thanks, Luwei Kang
On Mon, Sep 28, 2020 at 12:42:37PM +0000, Kang, Luwei wrote: > > >>>> No, it's not possible. KVM doesn't have a say on what the > > >>>> processor writes in the tracing packets. > > >>> Can KVM refuse to enable packet generation if CSbase is not zero and > > >>> CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from host? > > >> > > >> Yes, but the processor could change operating mode (and hence CSbase) > > >> while tracing is active. This is very unlikely, since it would > > >> require nonzero CS-base and a 32-bit host, but in principle not > > >> impossible (could be a firmware call, for example). > > >> > > >> The only solution is for KVM to accept both, and for QEMU to refuse a > > >> setting that does not match the host. > > >> > > > > > > So I need to add a patch in KVM to disabled the Intel PT when the > > > CSbase is not zero and the guest LIP different from the host. And this > > > limitation in qemu (disabled the PT when LIP is enabled in the host) > > > can be remove. Is that right? > > > > No, if a feature cannot be emulated, that means it cannot be enabled unless it > > matches the host. That's generally not a problem since Intel PT is usually used > > only with "-cpu host". > > > > The limitation of LIP in qemu will mask off the Intel PT in KVM > guest even with "-cpu host". e.g. This bit will be set in > SnowRidge HW and later. This behavior can and should be changed. > > How about "-cpu cpu_model, +intel-pt" use case? The current > value of Intel PT CPUID is a constant. Can we make the ICX > CPUID as basic inforation(LIP is 0) and using "+intel-pt-lip" > to make Intel PT work on the CPU which LIP is 1 on the host? As > you mentioned before, Intel PT cannot be enabled in guest > unless it matches the host. This makes sense, but you can also make each CPU model set a default for the LIP bit. "-cpu SnowRidge,+intel-pt" could set LIP=1 by default. -- Eduardo
> > > >>>> No, it's not possible. KVM doesn't have a say on what the > > > >>>> processor writes in the tracing packets. > > > >>> Can KVM refuse to enable packet generation if CSbase is not zero > > > >>> and CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from > host? > > > >> > > > >> Yes, but the processor could change operating mode (and hence > > > >> CSbase) while tracing is active. This is very unlikely, since it > > > >> would require nonzero CS-base and a 32-bit host, but in principle > > > >> not impossible (could be a firmware call, for example). > > > >> > > > >> The only solution is for KVM to accept both, and for QEMU to > > > >> refuse a setting that does not match the host. > > > >> > > > > > > > > So I need to add a patch in KVM to disabled the Intel PT when the > > > > CSbase is not zero and the guest LIP different from the host. And > > > > this limitation in qemu (disabled the PT when LIP is enabled in > > > > the host) can be remove. Is that right? > > > > > > No, if a feature cannot be emulated, that means it cannot be enabled > > > unless it matches the host. That's generally not a problem since > > > Intel PT is usually used only with "-cpu host". > > > > > > > The limitation of LIP in qemu will mask off the Intel PT in KVM guest > > even with "-cpu host". e.g. This bit will be set in SnowRidge HW and > > later. > > This behavior can and should be changed. > > > > > How about "-cpu cpu_model, +intel-pt" use case? The current value of > > Intel PT CPUID is a constant. Can we make the ICX CPUID as basic > > inforation(LIP is 0) and using "+intel-pt-lip" > > to make Intel PT work on the CPU which LIP is 1 on the host? As you > > mentioned before, Intel PT cannot be enabled in guest unless it > > matches the host. > > This makes sense, but you can also make each CPU model set a default for the > LIP bit. "-cpu SnowRidge,+intel-pt" could set > LIP=1 by default. I have a question on how to set LIP=1 in SnowRidge by default. 1. Set LIP in "builtin_x86_defs[]" SnowRidge CPU model. The LIP included in CPUID.(eax=14x,ecx=0)ecx[bit31] and a new leaf needs to be added. 2. Checking the CPU model in the later software flow and set the LIP bit if the CPU model is Snowridge. And we also need to add more CPU model's checking for new CPUs. What is your opinion? Thanks, Luwei Kang > > -- > Eduardo
On Tue, Sep 29, 2020 at 02:28:48AM +0000, Kang, Luwei wrote: > > > > >>>> No, it's not possible. KVM doesn't have a say on what the > > > > >>>> processor writes in the tracing packets. > > > > >>> Can KVM refuse to enable packet generation if CSbase is not zero > > > > >>> and CPUID.(EAX=14H,ECX=0)[bit 31] seen by guest is different from > > host? > > > > >> > > > > >> Yes, but the processor could change operating mode (and hence > > > > >> CSbase) while tracing is active. This is very unlikely, since it > > > > >> would require nonzero CS-base and a 32-bit host, but in principle > > > > >> not impossible (could be a firmware call, for example). > > > > >> > > > > >> The only solution is for KVM to accept both, and for QEMU to > > > > >> refuse a setting that does not match the host. > > > > >> > > > > > > > > > > So I need to add a patch in KVM to disabled the Intel PT when the > > > > > CSbase is not zero and the guest LIP different from the host. And > > > > > this limitation in qemu (disabled the PT when LIP is enabled in > > > > > the host) can be remove. Is that right? > > > > > > > > No, if a feature cannot be emulated, that means it cannot be enabled > > > > unless it matches the host. That's generally not a problem since > > > > Intel PT is usually used only with "-cpu host". > > > > > > > > > > The limitation of LIP in qemu will mask off the Intel PT in KVM guest > > > even with "-cpu host". e.g. This bit will be set in SnowRidge HW and > > > later. > > > > This behavior can and should be changed. > > > > > > > > How about "-cpu cpu_model, +intel-pt" use case? The current value of > > > Intel PT CPUID is a constant. Can we make the ICX CPUID as basic > > > inforation(LIP is 0) and using "+intel-pt-lip" > > > to make Intel PT work on the CPU which LIP is 1 on the host? As you > > > mentioned before, Intel PT cannot be enabled in guest unless it > > > matches the host. > > > > This makes sense, but you can also make each CPU model set a default for the > > LIP bit. "-cpu SnowRidge,+intel-pt" could set > > LIP=1 by default. > > I have a question on how to set LIP=1 in SnowRidge by default. > 1. Set LIP in "builtin_x86_defs[]" SnowRidge CPU model. The LIP included in CPUID.(eax=14x,ecx=0)ecx[bit31] and a new leaf needs to be added. > 2. Checking the CPU model in the later software flow and set the LIP bit if the CPU model is Snowridge. And we also need to add more CPU model's checking for new CPUs. > > What is your opinion? > 1 is preferred. Any CPU-model-specific data should be represented as data inside builtin_x86_defs, not code. -- Eduardo
On 28/09/20 14:42, Kang, Luwei wrote:
>> No, if a feature cannot be emulated, that means it cannot be
>> enabled unless it matches the host. That's generally not a problem
>> since Intel PT is usually used only with "-cpu host".
>>
> The limitation of LIP in qemu will mask off the Intel PT in KVM guest
> even with "-cpu host". e.g. This bit will be set in SnowRidge HW and
> later.
I agree that QEMU would have to learn about LIP. Unlike this patch,
however, x86_cpu_filter_features would have to fail if host LIP != guest
LIP. That is, something like
(ecx_0 & INTEL_PT_IP_LIP)) !=
(env->features[INTEL_PT_ECX_0] & INTEL_PT_IP_LIP)
where "intel-pt-lip" would be a feature in env->features[INTEL_PT_ECX_0].
> How about "-cpu cpu_model, +intel-pt" use case? The current value of
> Intel PT CPUID is a constant. Can we make the ICX CPUID as basic
> inforation(LIP is 0) and using "+intel-pt-lip" to make Intel PT work
> on the CPU which LIP is 1 on the host? As you mentioned before, Intel
> PT cannot be enabled in guest unless it matches the host.
Yes, this would work.
Paolo
> >> No, if a feature cannot be emulated, that means it cannot be enabled > >> unless it matches the host. That's generally not a problem since > >> Intel PT is usually used only with "-cpu host". > >> > > The limitation of LIP in qemu will mask off the Intel PT in KVM guest > > even with "-cpu host". e.g. This bit will be set in SnowRidge HW and > > later. > > I agree that QEMU would have to learn about LIP. Unlike this patch, however, > x86_cpu_filter_features would have to fail if host LIP != guest LIP. That is, > something like > > (ecx_0 & INTEL_PT_IP_LIP)) != > (env->features[INTEL_PT_ECX_0] & INTEL_PT_IP_LIP) > > where "intel-pt-lip" would be a feature in env->features[INTEL_PT_ECX_0]. Got it. Thanks. Luwei Kang > > > How about "-cpu cpu_model, +intel-pt" use case? The current value of > > Intel PT CPUID is a constant. Can we make the ICX CPUID as basic > > inforation(LIP is 0) and using "+intel-pt-lip" to make Intel PT work > > on the CPU which LIP is 1 on the host? As you mentioned before, Intel > > PT cannot be enabled in guest unless it matches the host. > > Yes, this would work. > > Paolo
© 2016 - 2025 Red Hat, Inc.