linux-kernel - Re: [PATCH v13 08/12] KVM: x86: Add Intel PT context switch for each vcpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1810301058060.5984@nanos.tec.linutronix.de>
Date:   Tue, 30 Oct 2018 11:00:31 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Paolo Bonzini <pbonzini@...hat.com>
cc:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Luwei Kang <luwei.kang@...el.com>, kvm@...r.kernel.org,
        x86@...nel.org, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
        rkrcmar@...hat.com, joro@...tes.org, songliubraving@...com,
        peterz@...radead.org, kstewart@...uxfoundation.org,
        gregkh@...uxfoundation.org, thomas.lendacky@....com,
        konrad.wilk@...cle.com, mattst88@...il.com,
        Janakarajan.Natarajan@....com, dwmw@...zon.co.uk,
        jpoimboe@...hat.com, marcorr@...gle.com, ubizjak@...il.com,
        sean.j.christopherson@...el.com, jmattson@...gle.com,
        linux-kernel@...r.kernel.org,
        Chao Peng <chao.p.peng@...ux.intel.com>
Subject: Re: [PATCH v13 08/12] KVM: x86: Add Intel PT context switch for each
 vcpu

On Mon, 29 Oct 2018, Paolo Bonzini wrote:
> On 24/10/2018 12:13, Alexander Shishkin wrote:
> > Luwei Kang <luwei.kang@...el.com> writes:
> >> +	/*
> >> +	 * Set guest state of MSR_IA32_RTIT_CTL MSR (PT will be disabled
> >> +	 * on VM entry when it has been disabled in guest before).
> >> +	 */
> >> +	vmcs_write64(GUEST_IA32_RTIT_CTL, vmx->pt_desc.guest.ctl);
> >> +
> >> +	if (vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) {
> >> +		wrmsrl(MSR_IA32_RTIT_CTL, 0);
> >> +		pt_save_msr(&vmx->pt_desc.host, vmx->pt_desc.addr_range);
> >> +		pt_load_msr(&vmx->pt_desc.guest, vmx->pt_desc.addr_range);
> >> +	}
> >> +}
> > 
> > From my side this is still a NAK, because [1].
> > 
> > [1] https://marc.info/?l=kvm&m=153847567226248&w=2
> 
> Then you should have replied to
> https://marc.info/?l=kvm&m=153865386015249&w=2 instead of having Luwei
> do the work for nothing.
> 
> Quoting from there:
> 
> >> One shouldn't have to enable or disable anything in KVM to stop it from
> >> breaking one's existing workflow. That makes no sense.
> > 
> > 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
> > 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.
> 
> I'd be happier if we found an agreement, but without discussion that
> just won't happen.

So at least we need a way for perf on the host to programmatically detect,
that 'guest traces itself' is enabled, so it can inject that information
into the host data and post processing can tell that. W/o something like
that it's going to be a FAQ.

Thanks,

	tglx