From patchwork Wed Dec 21 05:44:08 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Xuquan (Euler)" X-Patchwork-Id: 9482501 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 EE1A060772 for ; Wed, 21 Dec 2016 05:47:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DE5EE27FB3 for ; Wed, 21 Dec 2016 05:47:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D26CE280B0; Wed, 21 Dec 2016 05:47:28 +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 3FBDD27FB3 for ; Wed, 21 Dec 2016 05:47:27 +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 1cJZhd-0007YQ-EF; Wed, 21 Dec 2016 05:44:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJZhc-0007YK-M4 for xen-devel@lists.xen.org; Wed, 21 Dec 2016 05:44:36 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id 57/E2-14064-3C61A585; Wed, 21 Dec 2016 05:44:35 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRWlGSWpSXmKPExsVi9XuGg+5hsag Ig4UNQhZLPi5mcWD0OLr7N1MAYxRrZl5SfkUCa8aJw4oFSyUqmh/vZ2lgPC7cxcjFISRwilHi 4pcJzBDOBkaJpesOMHUxcnKwCehKbD99ihXEFhEwl9i6ZAsjSBGzwDxmie8L17CBJIQFXCWaL rxmgSjykrgx8z5Ug57E1i3dYINYBFQl2vZMAKvhFQiWuLxgIjOIzSggJvH91BqwGmYBcYm502 aB9UoICEosmr2HGcIWk/i36yEbhK0osafvAytEvY7Egt2f2CBsbYllC18zQ8wXlDg58wkLRL2 kxMEVN1gmMArPQrJiFpL2WUjaZyFpX8DIsopRozi1qCy1SNfYQC+pKDM9oyQ3MTNH19DAVC83 tbg4MT01JzGpWC85P3cTIzAC6hkYGHcwTljld4hRkoNJSZR30s/ICCG+pPyUyozE4oz4otKc1 OJDjDIcHEoSvP6iURFCgkWp6akVaZk5wFiESUtw8CiJ8DaCpHmLCxJzizPTIVKnGBWlxHmDQR ICIImM0jy4Nlj8X2KUlRLmZWRgYBDiKUgtys0sQZV/xSjOwagkzJsIMoUnM68EbvoroMVMQIs XdoeDLC5JREhJNTAqnQ65smpb/oHWNWn71OcGX1v8Ri5N6ClnUIausVGE3Nyq/W0+kUXsT32m dz54l5Iioa0mt0P4fff+6rlpsi3fX/559N3r162NHp7pIkLS2YqOx4rtHF13uRzLLJB/2fn9z 76Mjwe3hgvuKZx9QPNLstvhRuaWrvKTXuXfDXvOpMzYMfHcpmYlluKMREMt5qLiRACi/3ur+g IAAA== X-Env-Sender: xuquan8@huawei.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1482299069!62512399!1 X-Originating-IP: [58.251.152.64] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 42973 invoked from network); 21 Dec 2016 05:44:33 -0000 Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com) (58.251.152.64) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 21 Dec 2016 05:44:33 -0000 Received: from 172.24.1.47 (EHLO SZXEMI402-HUB.china.huawei.com) ([172.24.1.47]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWS15142; Wed, 21 Dec 2016 13:44:17 +0800 (CST) Received: from SZXEMI506-MBX.china.huawei.com ([169.254.5.247]) by SZXEMI402-HUB.china.huawei.com ([10.83.65.54]) with mapi id 14.03.0235.001; Wed, 21 Dec 2016 13:44:08 +0800 From: "Xuquan (Quan Xu)" To: "xen-devel@lists.xen.org" Thread-Topic: [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue Thread-Index: AdJbTT5AO+J/dMCISJ6crC6Sp0Dm5w== Date: Wed, 21 Dec 2016 05:44:08 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.69.246] MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "yang.zhang.wz@gmail.com" , Lan Tianyu , "Tian, Kevin" , "Nakajima, Jun" , Andrew Cooper , George Dunlap , "Xuquan \(Quan Xu\)" , Jan Beulich , "Gao, Chao" Subject: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue 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 When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest with high payload (with 2vCPU, captured from xentrace, in high payload, the count of IPI interrupt increases rapidly between these vCPUs). If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1) are both pending (index of bit set in vIRR), unfortunately, the IPI intrrupt is high priority than periodic timer interrupt. Xen updates IPI interrupt bit set in vIRR to guest interrupt status (RVI) as a high priority and apicv (Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root operation without a VM-Exit. Within VMX non-root operation, if periodic timer interrupt index of bit is set in vIRR and highest, the apicv delivers periodic timer interrupt within VMX non-root operation as well. But in current code, if Xen doesn't update periodic timer interrupt bit set in vIRR to guest interrupt status (RVI) directly, Xen is not aware of this case to decrease the count (pending_intr_nr) of pending periodic timer interrupt, then Xen will deliver a periodic timer interrupt again. And that we update periodic timer interrupt in every VM-entry, there is a chance that already-injected instance (before EOI-induced exit happens) will incur another pending IRR setting if there is a VM-exit happens between virtual interrupt injection (vIRR->0, vISR->1) and EOI-induced exit (vISR->0), since pt_intr_post hasn't been invoked yet, then the guest receives more periodic timer interrupt. So we set eoi_exit_bitmap for intack.vector when it's higher than pending periodic time interrupts. This way we can guarantee there's always a chance to post periodic time interrupts when periodic time interrupts becomes the highest one. Signed-off-by: Quan Xu Acked-by: Kevin Tian --- xen/arch/x86/hvm/vmx/intr.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) -- 1.8.3.4 diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c index 639a705..0cf26b4 100644 --- a/xen/arch/x86/hvm/vmx/intr.c +++ b/xen/arch/x86/hvm/vmx/intr.c @@ -315,9 +315,13 @@ void vmx_intr_assist(void) * Set eoi_exit_bitmap for periodic timer interrup to cause EOI-induced VM * exit, then pending periodic time interrups have the chance to be injected * for compensation + * Set eoi_exit_bitmap for intack.vector when it's higher than pending + * periodic time interrupts. This way we can guarantee there's always a chance + * to post periodic time interrupts when periodic time interrupts becomes the + * highest one */ if (pt_vector != -1) - vmx_set_eoi_exit_bitmap(v, pt_vector); + vmx_set_eoi_exit_bitmap(v, intack.vector); /* we need update the RVI field */ __vmread(GUEST_INTR_STATUS, &status); @@ -334,7 +338,8 @@ void vmx_intr_assist(void) __vmwrite(EOI_EXIT_BITMAP(i), v->arch.hvm_vmx.eoi_exit_bitmap[i]); } - pt_intr_post(v, intack); + if ( intack.vector == pt_vector ) + pt_intr_post(v, intack); } else {