From patchwork Wed Feb 8 08:27:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Xuquan (Euler)" X-Patchwork-Id: 9561961 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 D367860236 for ; Wed, 8 Feb 2017 08:29:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BFDCF1FE84 for ; Wed, 8 Feb 2017 08:29:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B2D0528467; Wed, 8 Feb 2017 08:29:36 +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 262EC1FE84 for ; Wed, 8 Feb 2017 08:29:35 +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 1cbNbS-00012b-Hb; Wed, 08 Feb 2017 08:27:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbNbR-00012T-Bd for xen-devel@lists.xen.org; Wed, 08 Feb 2017 08:27:49 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id 8B/69-31649-486DA985; Wed, 08 Feb 2017 08:27:48 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRWlGSWpSXmKPExsVi9XuGg27ztVk RBpfmW1ks+biYxYHR4+ju30wBjFGsmXlJ+RUJrBkLbq1kKpgqWrFx0m+WBsZNgl2MXBxCAmcY Jfav+8sK4WxglDjwqoWxi5GTg01AV2L76VOsILaIgKfEtFsXWUCKmAUuMUr0Hr3JBpIQFnCXO L54MlSRh8SrbTMYIewkiWtPL4LVsAioSPz9uxDI5uDgFQiW+HA/F2LZO2aJ7Uteg8U5BUIkfv UIgJQzCohJfD+1hgnEZhYQl5g7bRbYeAkBQYlFs/cwQ9hiEv92PWSDsBUl9vR9YIWo15FYsPs TG4StLbFs4Wuwel6g3pMzn7BA1EtKHFxxA+wXCYELjBJ/b++ESphK7Hryl2kCo/gsJLtnIZk7 C8ncWUjmLmBkWcWoUZxaVJZapGtorpdUlJmeUZKbmJmja2hgrJebWlycmJ6ak5hUrJecn7uJE RhjDECwg/Hlac9DjJIcTEqivIynZkUI8SXlp1RmJBZnxBeV5qQWH2KU4eBQkuDNuwqUEyxKTU +tSMvMAUY7TFqCg0dJhDcRJM1bXJCYW5yZDpE6xagoJc5rB5IQAElklObBtcESzCVGWSlhXka gQ4R4ClKLcjNLUOVfMYpzMCoJ82aCTOHJzCuBm/4KaDET0OLrp8EWlyQipKQaGGd9bZ70jvO/ 3aPahYfelTL8/btCxoNxuf+OWuamNqmDsrdzfGrEc6ubXk9cvWqF58etdmXT4+YbfTaZXhgkr CTw6sUWnqXSPY//JG5gXfXo04cmxdOmOY8LtjOWsrM32izmDShtjjitsJhFlmH9/DNrSxZuEM 0xYtzu8/xA5fvjxlnvD9hxTFdiKc5INNRiLipOBAAQOMW6KwMAAA== X-Env-Sender: xuquan8@huawei.com X-Msg-Ref: server-15.tower-31.messagelabs.com!1486542462!80498735!1 X-Originating-IP: [58.251.152.64] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 44710 invoked from network); 8 Feb 2017 08:27:47 -0000 Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com) (58.251.152.64) by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 8 Feb 2017 08:27:47 -0000 Received: from 172.24.1.136 (EHLO szxemi412-hub.china.huawei.com) ([172.24.1.136]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYS84980; Wed, 08 Feb 2017 16:27:20 +0800 (CST) Received: from SZXEMI506-MBX.china.huawei.com ([169.254.5.247]) by szxemi412-hub.china.huawei.com ([10.86.210.35]) with mapi id 14.03.0235.001; Wed, 8 Feb 2017 16:27:12 +0800 From: "Xuquan (Quan Xu)" To: "Tian, Kevin" , Jan Beulich Thread-Topic: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL Thread-Index: AQHSbLRB4GrLEGPSIkuiqONC4BxadaE0uyqA//+AhQCAAALNgIAF0/aAgAcIRmCABNjLEIAYXHaAgACG5KA= Date: Wed, 8 Feb 2017 08:27:11 +0000 Message-ID: References: <56880ae2-198c-a8e5-1d2c-a440193c6e65@citrix.com> <587783DB020000780012F65C@prv-mh.provo.novell.com> In-Reply-To: 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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.589AD671.00FB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.247, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 045c1068da48f335a30d0dad44027452 Cc: "yang.zhang.wz@gmail.com" , Andrew Cooper , "xen-devel@lists.xen.org" , "Gao, Chao" Subject: Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL 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 February 08, 2017 2:51 PM, Tian, Kevin wrote: >> From: Xuquan (Quan Xu) [mailto:xuquan8@huawei.com] >> Sent: Monday, January 23, 2017 6:57 PM >> >> On January 20, 2017 5:09 PM, Quan Xu wrote: >> >btw, for PIR.. I find that there might be a bug in >> >__vmx_deliver_posted_interrupt()... >> >why test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu)) ?? >> > >> >static void __vmx_deliver_posted_interrupt(struct vcpu *v) { ... >> > if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, >> >&softirq_pending(cpu)) ... >> >} >> > >> >Suppose that vCPUx is in guest mode, there are two (even more) >> >interrupts to vCPUx.. >> >As the bit is set when delivers the first interrupt... the second >> >interrupt is pending until next VM entry -- by PIR to vIRR.. >> > >> >> Jan , Kevin >> Correct me if I am wrong... >> >> Quan > >I don't quite understand the point here. Can you elaborate? > Assumed vCPU is in guest_mode.. When apicv is enabled, hypervisor calls vmx_deliver_posted_intr(), then __vmx_deliver_posted_interrupt() to deliver interrupt, but no vmexit (also no vcpu_kick() ).. In __vmx_deliver_posted_interrupt(), it is __conditional__ to deliver posted interrupt. if posted interrupt is not delivered, the posted interrupt is pending until next VM entry -- by PIR to vIRR.. one condition is : In __vmx_deliver_posted_interrupt(), ' if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu))' .. Specifically, we did verify it by RES interrupt, which is used for smp_reschedule_interrupt.. We even cost more time to deliver RES interrupt than no-apicv in average.. If RES interrupt (no. 1) is delivered by posted way (the vcpu is still guest_mode).. when tries to deliver next-coming RES interrupt (no. 2) by posted way, The next-coming RES interrupt (no. 2) is not delivered, as we set the VCPU_KICK_SOFTIRQ bit when we deliver RES interrupt (no. 1).. Then the next-coming RES interrupt (no. 2) is pending until next VM entry -- by PIR to vIRR.. We can fix it as below(I don't think this is a best one, it is better to set the VCPU_KICK_SOFTIRQ bit, but not test it): To be honest, I really spent several days for the original awkward-description:).. Happy Spring Festival!! Quan --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -1846,7 +1846,7 @@ static void __vmx_deliver_posted_interrupt(struct vcpu *v) { unsigned int cpu = v->processor; - if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu)) + if ( !test_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu)) && (cpu != smp_processor_id()) ) send_IPI_mask(cpumask_of(cpu), posted_intr_vector); }