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
| ||
|
Date: Mon, 29 Oct 2018 18:48:15 +0100 From: Paolo Bonzini <pbonzini@...hat.com> To: Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Luwei Kang <luwei.kang@...el.com>, kvm@...r.kernel.org, x86@...nel.org Cc: tglx@...utronix.de, 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 24/10/2018 12:13, Alexander Shishkin wrote: > Luwei Kang <luwei.kang@...el.com> writes: > >> +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 (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. Also, is there an existing interface to write a record into a tracing buffer? Paolo
Powered by blists - more mailing lists