From patchwork Fri Sep 23 08:35:24 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Razvan Cojocaru X-Patchwork-Id: 9347743 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E7C63607F2 for ; Fri, 23 Sep 2016 08:37:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D8BA02A01F for ; Fri, 23 Sep 2016 08:37:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CD51A2A61A; Fri, 23 Sep 2016 08:37:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 40E452A01F for ; Fri, 23 Sep 2016 08:37:41 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnLxC-0006pg-TC; Fri, 23 Sep 2016 08:35:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnLxB-0006pS-OW for xen-devel@lists.xenproject.org; Fri, 23 Sep 2016 08:35:29 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 4C/01-13924-059E4E75; Fri, 23 Sep 2016 08:35:28 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRWlGSWpSXmKPExsUSfTxjoW7Ayyf hBpN6hSy+b5nM5MDocfjDFZYAxijWzLyk/IoE1oypt7awFpwUrbi+fTFrA+NswS5GTg4hAXeJ S6vWsHYxcgHZaxkl7uz5wwzh3GWUOHmjjQmiykNi58puFojEekaJxokXGEESwgJ2EjNnnmYGs UUEgiROX/7NBFH0iU1ixYr/7CAJZgFXiZUPn7KA2GwChhKrN7awgdi8Ak4Sr58dAbNZBFQlVq xZD1YjKhAucfpvIztEjaDEyZlPwOKcAvYSZxb8ZoOYqS7xZ94lZghbXmL72zlgtoRAjsShZQe AbA4gW0rif6sSyD0SAr0sEhu+drBC1MhIPJp4k20Co+gsJCtmIRk7C8nYBYzMqxg1ilOLylKL dI3M9JKKMtMzSnITM3N0DQ1M9XJTi4sT01NzEpOK9ZLzczcxAqOjnoGBcQfj7cl+hxglOZiUR Hkb9z0JF+JLyk+pzEgszogvKs1JLT7EKMPBoSTBu+E5UE6wKDU9tSItMwcYpzBpCQ4eJRHeVy Bp3uKCxNzizHSI1ClGRSlx3ikgCQGQREZpHlwbLDVcYpSVEuZlZGBgEOIpSC3KzSxBlX/FKM7 BqCTMOxNkCk9mXgnc9FdAi5mAFn+7A7a4JBEhJdXA2PR0Ws5i3w9rKh2uKLxa9GlHyfPV2z9K WB+K6nn6ctWMT7sXrtJIUxc7lBF7MJPX3zZ969GX8QJzFy4Vi3RcH/5L4Gx8yFMV1yMN4WnCl SIll97WH7v6LGaea8H/hfu+PRRjC1uy1OPUj1l7JLiWfjx0S6qpT+C5N9MjnlNdnGFcMYnvbP bHBSuxFGckGmoxFxUnAgDsTxMJCAMAAA== X-Env-Sender: rcojocaru@bitdefender.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1474619727!60918707!1 X-Originating-IP: [91.199.104.161] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18408 invoked from network); 23 Sep 2016 08:35:28 -0000 Received: from mx01.bbu.dsd.mx.bitdefender.com (HELO mx01.bbu.dsd.mx.bitdefender.com) (91.199.104.161) by server-8.tower-206.messagelabs.com with DHE-RSA-AES128-GCM-SHA256 encrypted SMTP; 23 Sep 2016 08:35:28 -0000 Received: (qmail 7540 invoked from network); 23 Sep 2016 11:35:26 +0300 Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103) by mx01.bbu.dsd.mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP; 23 Sep 2016 11:35:26 +0300 Received: from smtp03.buh.bitdefender.org (smtp.bitdefender.biz [10.17.80.77]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 1EB657FC38 for ; Fri, 23 Sep 2016 11:35:26 +0300 (EEST) Received: (qmail 29101 invoked from network); 23 Sep 2016 11:35:26 +0300 Received: from 86-121-14-161.rdsnet.ro (HELO ?192.168.228.119?) (rcojocaru@bitdefender.com@86.121.14.161) by smtp03.buh.bitdefender.org with SMTP; 23 Sep 2016 11:35:26 +0300 To: Jan Beulich , Tamas K Lengyel References: <57E27BB90200007800110F8B@prv-mh.provo.novell.com> <57E2B8EC020000780011126A@prv-mh.provo.novell.com> <57E2C22D0200007800111310@prv-mh.provo.novell.com> <57E3B8F702000078001116DB@prv-mh.provo.novell.com> <57E3DC41020000780011194D@prv-mh.provo.novell.com> <57E502C60200007800111D86@prv-mh.provo.novell.com> From: Razvan Cojocaru Message-ID: Date: Fri, 23 Sep 2016 11:35:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <57E502C60200007800111D86@prv-mh.provo.novell.com> X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.6 on smtp03.buh.bitdefender.org, sigver: 7.67338 X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: Build: [Engines: 2.15.6.911, Dats: 433101, Stamp: 3], Multi: [Enabled, t: (0.000008, 0.002920)], BW: [Enabled, t: (0.000007,0.000001)], RBL DNSBL: [Disabled], APM: [Enabled, Score: 500, t: (0.003030), Flags: 85D2ED72; NN_FORGED_THUNDERBIRD_2; NN_LEGIT_VALID_REPLY; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS], SGN: [Enabled, t: (0.008444)], URL: [Enabled, t: (0.000005)], RTDA: [Enabled, t: (0.010682), Hit: No, Details: v2.3.11; Id: 2m1ghjn.1aspl0o00.3ac6i], total: 0(775) X-BitDefender-CF-Stamp: none Cc: "xen-devel@lists.xenproject.org" Subject: Re: [Xen-devel] Question about VPID during MOV-TO-CR3 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 09/23/16 11:24, Jan Beulich wrote: >>>> On 22.09.16 at 19:18, wrote: >> So I verified that when CPU-based load exiting is enabled, the TLB >> flush here is critical. Without it the guest kernel crashes at random >> points during boot. OTOH why does Xen trap every guest CR3 update >> unconditionally? While we have features such as the vm_event/monitor >> that may choose to subscribe to that event, Xen traps it even when >> that is not in use. Is that trapping necessary for something else? > > Where do you see this being unconditional? construct_vmcs() > clearly avoids setting these intercepts when using EPT. Are you > perhaps suffering from > > /* Trap CR3 updates if CR3 memory events are enabled. */ > if ( v->domain->arch.monitor.write_ctrlreg_enabled & > monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) ) > v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING; > > in vmx_update_guest_cr()? That'll be rather something for you > or Razvan to explain. Outside of nested VMX I don't see any > other enabling of that intercept (didn't check AMD code on the > assumption that you're working on Intel hardware). I did touch that line, but that was mostly a mechanical change in commit 712bdd01: vmx_update_cpu_exec_control(v); @@ -2010,7 +2012,7 @@ static int vmx_cr_access(unsigned long exit_qualification) unsigned long old = curr->arch.hvm_vcpu.guest_cr[0]; curr->arch.hvm_vcpu.guest_cr[0] &= ~X86_CR0_TS; vmx_update_guest_cr(curr, 0); - hvm_event_cr0(curr->arch.hvm_vcpu.guest_cr[0], old); + hvm_event_crX(CR0, curr->arch.hvm_vcpu.guest_cr[0], old); HVMTRACE_0D(CLTS); break; } The basic logic has remained untouched. The logic has been added in commit df402bb9, by Joe Epstein. It's of course open to debate. Thanks, Razvan diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 74f563f..af257db 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -57,6 +57,7 @@ #include #include #include +#include #include static bool_t __initdata opt_force_ept; @@ -1262,7 +1263,8 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned int cr) v->arch.hvm_vmx.exec_control |= cr3_ctls; /* Trap CR3 updates if CR3 memory events are enabled. */ - if ( v->domain->arch.monitor.mov_to_cr3_enabled ) + if ( v->domain->arch.monitor.write_ctrlreg_enabled & + monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) ) v->arch.hvm_vmx.exec_control |= CPU_BASED_CR3_LOAD_EXITING;