> > > > Suppose your KVM thing claims counter 0/2 (ICL/SKL) for some
> > > > random PEBS event, and then the host wants to use PREC_DIST.. Then
> > > > one of them will be screwed for no reason what so ever.
> > > >
> > >
> > > The multiplexing should be triggered.
> > >
> > > For host, if both use
> > > Suppose your KVM thing claims counter 0/2 (ICL/SKL) for some random
> > > PEBS event, and then the host wants to use PREC_DIST.. Then one of
> > > them will be screwed for no reason what so ever.
> > >
> >
> > The multiplexing should be triggered.
> >
> > For host, if both user A and user B r
> > + case MSR_IA32_PEBS_ENABLE:
> > + if (pmu->pebs_enable == data)
> > + return 0;
> > + if (!(data & pmu->pebs_enable_mask) &&
> > +(data & MSR_IA32_PEBS_OUTPUT_MASK) ==
> > + MSR_IA32_PEBS_OUTPUT_P
> > /* returns fixed PMC with the specified MSR */ -static inline struct
> > kvm_pmc *get_fixed_pmc(struct kvm_pmu *pmu, u32 msr)
> > +static inline struct kvm_pmc *get_fixed_pmc(struct kvm_pmu *pmu, u32
> msr,
> > + int base)
>
> Better d
> > PEBS output Inte PT introduces some new MSRs (MSR_RELOAD_FIXED_CTRx)
> > for fixed function counters that use for autoload the preset value
> > after writing out a PEBS event.
> >
> > Introduce base MSRs address parameter to make this function can get
> > performance monitor counter structure b
> On Thu, Aug 29, 2019 at 01:34:00PM +0800, Luwei Kang wrote:
> > Intel new hardware introduces some Precise Event-Based Sampling (PEBS)
> > extensions that output the PEBS record to Intel PT stream instead of
> > DS area. The PEBS record will be packaged in a specific format when
> > outputing to
> -Original Message-
> From: Christopherson, Sean J
> Sent: Friday, May 31, 2019 2:46 AM
> To: Kang, Luwei
> Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org; pbonz...@redhat.com;
> rkrc...@redhat.com; t...@linutronix.de;
> mi...@redhat.com; b...@alien8.
> > For Guest XSS, right now, only bit 11(user states) and bit 12
> > (supervisor states) are supported, if other bits are being set, need
> > to modify KVM_SUPPORTED_XSS macro to have support.
> >
> > Signed-off-by: Zhang Yi Z
> > Signed-off-by: Yang Weijiang
> > ---
> > arch/x86/kvm/vmx.c | 8
> > Some Posted-Interrupts from passthrough devices may be lost or
> > overwritten when the vCPU is in runnable state.
> >
> > The SN (Suppress Notification) of PID (Posted Interrupt Descriptor)
> > will be set when the vCPU is preempted (vCPU in
> KVM_MP_STATE_RUNNABLE
> > state but not running on
> > >> This is not what I asked. You should instead do the check after
> > >> pi_clear_sn.
> > >>
> > >
> > > I think the SN has been cleared here before test the bitmap.
> > > The SN will be set when the vCPU is schedule out. ID:
> > > 28b835d60fcc2498e717cf5e6f0c3691c24546f7
> > > But SN will
> >> This is not what I asked. You should instead do the check after
> >> pi_clear_sn.
> >>
> >
> > I think the SN has been cleared here before test the bitmap.
> > The SN will be set when the vCPU is schedule out. ID:
> > 28b835d60fcc2498e717cf5e6f0c3691c24546f7
> > But SN will be cleared when
> > Some Posted-Interrupts from passthrough devices may be lost or
> > overwritten when the vCPU is in runnable state.
> >
> > The SN (Suppress Notification) of PID (Posted Interrupt Descriptor)
> > will be set when the vCPU is preempted (vCPU in KVM_MP_STATE_RUNNABLE
> > state but not running on p
> >>> However, you should at least change the comment in vcpu_enter_guest
> >>> to mention "before reading PIR" instead of "before reading PIR.ON".
> >>
> >> Will do that. I think the "checking PIR.ON" should be PID.ON. I will fix
> >> it.
> >>
> > Hi Paolo,
> > I reconsidered the comment in v
> > However, you should at least change the comment in vcpu_enter_guest to
> > mention "before reading PIR" instead of "before reading PIR.ON".
>
> Will do that. I think the "checking PIR.ON" should be PID.ON. I will fix it.
>
Hi Paolo,
I reconsidered the comment in vcpu_enter_guest() and thi
> > Some Posted-Interrupts from passthrough devices may be lost or
> > overwritten when the vCPU is in runnable state.
> >
> > The SN (Suppress Notification) of PID (Posted Interrupt Descriptor)
> > will be set when the vCPU is preempted (vCPU in KVM_MP_STATE_RUNNABLE
> > state but not running on p
> > Some Posted-Interrupts from passthrough devices may be lost or
> > overwritten when the vCPU is in runnable state.
> >
> > The SN (Suppress Notification) of PID (Posted Interrupt Descriptor)
> > will be set when the vCPU is preempted (vCPU in KVM_MP_STATE_RUNNABLE
> > state but not running on p
> -Original Message-
> From: Gustavo A. R. Silva [mailto:gust...@embeddedor.com]
> Sent: Thursday, December 27, 2018 4:41 AM
> To: Kang, Luwei ; Paolo Bonzini ;
> Radim Krčmář ; Thomas Gleixner
> ; Ingo Molnar ; Borislav Petkov
> ; H. Peter Anvin ;
>
> >> If you "have to enable or disable anything" it means you have to
> >> override the default. But the default in this patches is "no change
> >> compared to before the patches", leaving tracing of both host and
> >> guest entirely to the host, so I don't understand your remark. What
> >> workf
> > > >> This part is in the " Intel® Architecture Instruction Set Extensions
> > > >> and Future Features Programming Reference"
> > > >> https://software.intel.com/sites/default/files/managed/c5/15/arch
> > > >> itec ture-instruction-set-extensions-programming-reference.pdf
> > > >>
> > > > Yet
> >> This part is in the " Intel® Architecture Instruction Set Extensions and
> >> Future Features Programming Reference"
> >> https://software.intel.com/sites/default/files/managed/c5/15/architec
> >> ture-instruction-set-extensions-programming-reference.pdf
> >>
> > Yet another PDF which will ch
> > From: Chao Peng
> >
> > Intel Processor Trace virtualization can be work in one of 2 possible
> > modes:
> >
> > a. System-Wide mode (default):
> >When the host configures Intel PT to collect trace packets
> >of the entire system, it can leave the relevant VMX controls
> >clear to
> > +static void pt_guest_enter(struct vcpu_vmx *vmx) {
> > + if (pt_mode == PT_MODE_SYSTEM)
> > + return;
> > +
> > + /* Save host state before VM entry */
> > + rdmsrl(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl);
> > +
> > + /*
> > +* Set guest state of MSR_IA32_RTIT_CTL MSR (
> >>> + /* Initialize and clear the no dependency bits */
> >>> + vmx->pt_desc.ctl_bitmask = ~0ULL;
> >> This looks redundant, doesn't it?
> > This is a bit mask for RTIT_CTL MSR and it will make & with the value of
> > RTIT_CLT from guest.
> > The reserved bits will be 1 in this bit mask and the
> > From: Chao Peng
> >
> > Disable intercept Intel PT MSRs only when Intel PT is enabled in
> > guest. But MSR_IA32_RTIT_CTL will alway be intercept.
>
> "I'd like to offer some suggestions as to how to make the commit message
> friendlier for reviewing.
>
> Generally, for every patch, we want
> > + /*
> > +* Any MSR write that attempts to change bits marked reserved will
> > +* case a #GP fault.
> > +*/
> > + if (data & vmx->pt_desc.ctl_bitmask)
> > + return 1;
> > +
> > + /*
> > +* Any attempt to modify IA32_RTIT_CTL while TraceEn is set will
> > +*
> On Tue, May 22, 2018 at 12:52:12PM +0800, Luwei Kang wrote:
> > Initialize the Intel PT configuration when cpuid update.
>
> Is it the CPUID configuration? Is it the MSR configuration? Is it both?
> Kind of looks like both. Not sure what is the cpuid update, though.
>
> > Include cpuid inforamt
> > On Tue, May 22, 2018 at 12:52:07PM +0800, Luwei Kang wrote:
> > > CPUID(EAX=14H,ECX=0):EBX[bit 3] = 1 indicates support of output to
> > > Trace Transport subsystem.
> > > MSR IA32_RTIT_CTL.FabricEn[bit 6] is reserved if CPUID.(EAX=14H,
> > > ECX=0):ECX[bit 3] = 0.
> >
> > This should instead s
> > CPUID(EAX=14H,ECX=0):EBX[bit 3] = 1 indicates support of output to
> > Trace Transport subsystem.
> > MSR IA32_RTIT_CTL.FabricEn[bit 6] is reserved if CPUID.(EAX=14H,
> > ECX=0):ECX[bit 3] = 0.
>
> This should instead say:
>
> This adds support for "output to Trace Transport subsystem" capabi
> > These bit definitions are use for emulate MSRs read/write for KVM. For
> > example, IA32_RTIT_CTL.FabricEn[bit 6] is available only when
> > CPUID.(EAX=14H, ECX=0):ECX[bit 3] = 1. If KVM guest try to set this
> > bit with CPUID.(EAX=14H, ECX=0):ECX[bit3] = 0 a #GP would be injected
> > to KVM g
> > From: Chao Peng
> >
> > Intel PT virtualization can be work in one of 2 possible modes:
> > a. system-wide: trace both host and guest and output to host buffer;
> > b. host-guest: trace host/guest simultaneous and output to their
> >respective buffer.
>
> I think we discussed this before.
> -Original Message-
> From: Kang, Luwei
> Sent: Tuesday, May 22, 2018 12:52 PM
> To: k...@vger.kernel.org
> Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> chao.p.p...@linux.intel.com;
> thomas.lenda...@amd.com; b..
> > From: Chao Peng
> >
> > Intel Processor Trace virtualization enabling in KVM guest need to
> > access these MSRs bit definitions, so move them to public header file
> > msr-index.h.
> > @@ -115,6 +148,7 @@
> > #define MSR_IA32_RTIT_ADDR2_B 0x0585
> > #define MSR_IA32_RTIT_AD
> >> Can you elaborate on this, what information do we need besides
> >> MSR_IA32_VMX_MISC[14]?
> >
> > Enable Intel PT in guest depend on SECONDARY_EXEC_PT_USE_GPA, EPT,
> > MSR_IA32_VMX_MISC[14] and the capability of " PT_CAP_topa_output" on
> > hardware. PT driver will return " -ENODEV" if hardw
> > > > New function __pt_cap_get() will be invoked in KVM to check if a
> > > > specific capability is availiable in KVM guest.
> > > > Another function pt_cap_get() can only check the hardware
> > > > capabilities but this may different with KVM guest because some
> > > > features may not be expo
> On Thu, May 03, 2018 at 10:23:12AM +0000, Kang, Luwei wrote:
> > Send this patch set twice because path 2 send fail in the first time.
>
> Then just resend patch 2; also I have two copies of patch 2, so clearly it
> _did_ send.
Cc all the maintainers and contributors.
Thanks,
Luwei Kang.
> > New function __pt_cap_get() will be invoked in KVM to check if a
> > specific capability is availiable in KVM guest.
> > Another function pt_cap_get() can only check the hardware capabilities
> > but this may different with KVM guest because some features may not be
> > exposed to guest.
>
> D
> Hi All,
>
> Here is a patch-series which adding Processor Trace enabling in KVM guest.
> You can get It's software developer manuals from:
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
> In Chapter 4 INTEL PROCES
> > Intel Processor Trace virtualization enabling in guest need to use
> > these MSR bits, so move them to public header msr-index.h.
> > Introduce RTIT_CTL_FABRIC_EN and sync the definitions to latest spec.
>
> You forgot to Cc the maintainers.
>
> Also, this patch does 2 things, I think we have
> > + if (pt_mode == PT_MODE_HOST_GUEST) {
>
> This would be vmx_pt_supported(), but I think it's better to remove that
> function and just test pt_mode ==
> PT_MODE_HOST_GUEST everywhere (or !=).
Hi Paolo,
There have so many vmx_pt_supported() invoked in MSRs read/write (patch 9)
patch a
> > +u32 pt_cap_get_ex(u32 *caps, enum pt_capabilities cap) {
> > + struct pt_cap_desc *cd = &pt_caps[cap];
> > + u32 c = caps[cd->leaf * PT_CPUID_REGS_NUM + cd->reg];
> > + unsigned int shift = __ffs(cd->mask);
> > +
> > + return (c & cd->mask) >> shift;
> > +}
> > +EXPORT_SYMBOL_GPL(pt_ca
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, January 5, 2018 11:43 PM
> To: linux-kernel@vger.kernel.org; k...@vger.kernel.org
> Cc: Kang, Luwei
> Subject: [PATCH] KVM: VMX: use same MSR b
> >>> + case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: {
> >>> + u32 eax, ebx, ecx, edx;
> >>> +
> >>> + cpuid_count(0x14, 1, &eax, &ebx, &ecx, &edx);
> >>
> >> Please cache the cpuid_count result, or do the cpuid_count after testing
> >> vmx_pt_suppor
> > + case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: {
> > + u32 eax, ebx, ecx, edx;
> > +
> > + cpuid_count(0x14, 1, &eax, &ebx, &ecx, &edx);
>
> Please cache the cpuid_count result, or do the cpuid_count after testing
> vmx_pt_supported() (whi
> > + if (!(_cpu_based_2nd_exec_control & SECONDARY_EXEC_PT_USE_GPA) ||
> > + !(_vmexit_control & VM_EXIT_CLEAR_IA32_RTIT_CTL) ||
> > + !(_vmentry_control & VM_ENTRY_LOAD_IA32_RTIT_CTL)) {
> > + _cpu_based_2nd_exec_control &= ~SECONDARY_EXEC_PT_USE_GPA;
>
> Also, yo
> > +#define VM_EXIT_PT_SUPPRESS_PIP0x0100
> > +#define VM_EXIT_CLEAR_IA32_RTIT_CTL0x0200
> >
> > #define VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR 0x00036dff
> >
> > @@ -108,6 +112,8 @@
> > #define VM_ENTRY_LOAD_IA32_PAT 0x4000
> > #d
> > + if (pt_mode == PT_MODE_HOST_GUEST) {
> > + u32 i, eax, ebx, ecx, edx;
> > +
> > + cpuid_count(0x14, 1, &eax, &ebx, &ecx, &edx);
> > + vmx_disable_intercept_for_msr(MSR_IA32_RTIT_STATUS, false);
> > + vmx_disable_intercept_for_msr(MSR_IA32_RTIT_OUTPUT_
> > static DEFINE_PER_CPU(struct vmcs *, vmxarea); static
> > DEFINE_PER_CPU(struct vmcs *, current_vmcs); @@ -3384,6 +3385,11 @@
> > static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> > return 1;
> > msr_info->data = vcpu->arch.ia32_xss;
>
> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index
> > 0099e10..ef19a11 100644
> > --- a/arch/x86/kvm/cpuid.c
> > +++ b/arch/x86/kvm/cpuid.c
> > @@ -70,6 +70,7 @@ u64 kvm_supported_xcr0(void)
> > /* These are scattered features in cpufeatures.h. */
> > #define KVM_CPUID_BIT_AVX512
> > From v1:
> > - remove guest-only mode because guest-only mode can be covered by
> > host-guest mode;
> > - always set "use GPA for processor tracing" in secondary execution
> > control if it can be;
> > - trap RTIT_CTL read/write. Forbid write this msr when VMXON in L1
> > hypervisor.
>
> > HI Paolo, Thanks for your clarify. Have understood. So, we should set
> > "use GPA for processor tracing" in any way( if we can do it) even in
> > system mode. There don't have problem in no nested but have problem in
> > nested if not set this bit. Still talking with hardware designer but
> >
> On 19/10/2017 07:54, Kang, Luwei wrote:
> >>> Get it. I have feedback to hardware architect. I hope it can be applied
> >>> but it may need wait a long time.
> >> Note that the hardware need not do anything. However it would be
> >> nice if the
> Nested virtualization is interesting. We would like the nested
> hypervisor to be forced to set the "use GPA for processor tracing"
> secondary execution control whenever "enable EPT" is set and
> RTIT_CTL is nonzero. There is no way to encode that in
> IA32_VMX_PROCBAS
> >> Nested virtualization is interesting. We would like the nested
> >> hypervisor to be forced to set the "use GPA for processor tracing"
> >> secondary execution control whenever "enable EPT" is set and RTIT_CTL
> >> is nonzero. There is no way to encode that in
> >> IA32_VMX_PROCBASED_CTLS2,
> On 16/10/2017 14:09, Luwei Kang wrote:
> > 2. Enabling use of EPT to redirect PT output.
> > — This enables the VMM to elect to virtualize the PT output buffer using
> > EPT. In this mode, the CPU will treat PT output
> addresses as Guest Physical Addresses (GPAs) and translate them using EPT.
> On October 16, 2017 8:14:11 AM EDT, Luwei Kang wrote:
> >From: Chao Peng
> >
> >Trap for Intel processor trace is none sense. Pass through to guest
> >directly.
>
>
> And none of those MSRs can be subverted by the guest? That is none of these
> should be filtered / audited first?
>
Curre
> Expose AVX512DQ, AVX512BW, AVX512VL feature to guest.
> Its spec can be found at:
> https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
>
> Signed-off-by: Luwei Kang
> ---
> arch/x86/kvm/cpuid.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a
56 matches
Mail list logo
