Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Kang, Luwei" <luwei.kang@intel.com>
To:     Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>
CC:     "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>, "hpa@zytor.com" <hpa@zytor.com>,
        "rkrcmar@redhat.com" <rkrcmar@redhat.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "songliubraving@fb.com" <songliubraving@fb.com>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "kstewart@linuxfoundation.org" <kstewart@linuxfoundation.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
        "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
        "mattst88@gmail.com" <mattst88@gmail.com>,
        "Janakarajan.Natarajan@amd.com" <Janakarajan.Natarajan@amd.com>,
        "dwmw@amazon.co.uk" <dwmw@amazon.co.uk>,
        "jpoimboe@redhat.com" <jpoimboe@redhat.com>,
        "marcorr@google.com" <marcorr@google.com>,
        "ubizjak@gmail.com" <ubizjak@gmail.com>,
        "Christopherson, Sean J" <sean.j.christopherson@intel.com>,
        "jmattson@google.com" <jmattson@google.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Chao Peng <chao.p.peng@linux.intel.com>,
        "luwei.k.kang@gmail.com" <luwei.k.kang@gmail.com>
Subject: RE: [Resend PATCH v13 08/12] KVM: x86: Add Intel PT context switch
 for each vcpu
Thread-Topic: [Resend PATCH v13 08/12] KVM: x86: Add Intel PT context switch
 for each vcpu
Thread-Index: AdR0rAQHUo9emJqwT66yVxiBuC3ogg==
Date:   Mon, 5 Nov 2018 02:05:28 +0000
Message-ID: <82D7661F83C1A047AF7DC287873BF1E172BDF8D0@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> >> 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
> >> workflow is broken?
> >>
> >>> There already are controls in perf that enable/disable guest tracing.
> >>
> >> You are confusing "tracing guest from the host" and "the guest can
> >> trace itself".  This patchset is adding support for the latter, and
> >> that
> 
> I'm not confusing anything. In the terminology that you're using, the latter breaks the former. This cannot happen.
> 
> >> affects directly whether the tracing CPUID leaf can be added to the
> >> guest.  Therefore it's not perf that can decide whether to turn it
> >> on; KVM must know it when /dev/kvm is opened, which is why it is a
> >> module parameter.
> 
> There is a control in the perf event attribute that enables tracing the guest. If this control is enabled, the kvm needs to stay away from any
> PT related MSRs. Conversely, if kvm is using PT (or, as you say, "the guest is tracing itself"), the host should not be allowed to ask for tracing
> the guest at the same time.

I think what you mentioned "perf event attribute" is "struct perf_event_attr -> exclude_host/exclude_guest" parameter.
Parameter "exclude_host" can use for vPMU in pmc_reprogram_counter() to make the counter disabled before VM-exit; Parameter "exclude_guest" can use for PMU in host to make the counter not include the value in Guest;
For the implementation of vPMU, there have some counters on each logical CPU, and host and guest can using different counter at same time, Not make Guest "stay from" PMU. Is that right? I think this "perf event attribute" not fit for Intel PT.

Intel PT is different, there just have one serials of MSRs in each logical CPU. So this hardware just can be used by host OR guest. In Host-Guest mode, PT feature will be exposed to guest and guest detect this feature certainly can use it like native any way. 
"If this control is enabled, the kvm needs to stay away from any PT related MSRs."
If we pay for a ICL virtual machine support Intel PT from Cloud Vendor but can't be used. Cloud vendor say that Host (or other virtual machine) is using this feature so you can't use it. Why? 

Currently, Intel SDM support three mode of tracing (System-Wide Tracing, Host-Only Tracing and Guest-Only Tracing). below is copy from SDM:
System-Wide Tracing (35.5.2.1): When a host or VMM configures Intel PT to collect trace packets of the entire system, it can leave the relevant VMX controls clear to allow VMX-specific packets to provide information across VMX transitions. 
Host-Only Tracing (35.5.2.2): Trace packets in VMX non-root operation are not desired, the VMM can use the VM-entry MSR-load area to load IA32_RTIT_CTL (clearing TraceEn) to disable trace-packet generation in guests, and use the VM-exit MSR-load area to load IA32_RTIT_CTL to set TraceEn.
Guest-Only Tracing (35.5.2.3): A VMM can configure trace-packet generation while in VMX non-root operation for guests executing normally. 

In Host mode we need to disable PT before VM-entry (no matter if PT is support/enabled or not in guest) and Load Guest PT status if PT is supported in Guest. The Host-Guest mode in this patch set just combined the Host-Only mode and Guest-Only mode to Host-Guest mode because there don't have conflict in these two mode.

As for Host PT will be disable before VM-entry and Host can't aware this behavior. I think this is use case limitation of different working mode and please EXPECT this happened. PT MUST be disabled before VM-entry and switch to Guest PT status in Host-Guest mode (following the description in SDM). Or please use default System-Wide mode.

Thanks,
Luwei Kang