From patchwork Tue Mar 7 14:58:04 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Durrant X-Patchwork-Id: 9609071 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 85C63602B4 for ; Tue, 7 Mar 2017 15:00:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 75A8C26E8A for ; Tue, 7 Mar 2017 15:00:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 68ABE2849C; Tue, 7 Mar 2017 15:00: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 D117126E8A for ; Tue, 7 Mar 2017 15:00:40 +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 1clGZ0-0007xZ-GU; Tue, 07 Mar 2017 14:58:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clGYz-0007xT-Sd for xen-devel@lists.xenproject.org; Tue, 07 Mar 2017 14:58:09 +0000 Received: from [85.158.139.211] by server-11.bemta-5.messagelabs.com id F0/7F-14291-18ACEB85; Tue, 07 Mar 2017 14:58:09 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRWlGSWpSXmKPExsXitHSDvW7DqX0 RBjueyFl83zKZyYHR4/CHKywBjFGsmXlJ+RUJrBkHJjQzFUySr3i0fj97A+NciS5GTg4JAX+J +xPOsIDYbAI6ElOfXmLtYuTgEBFQkbi91wAkzCxQLjHv7jQmEFtYIEbifWM/mM0CVNJyZAI7i M0r4Cbxdut7JoiRchLnj/9kBrGFgGrWT53FBlEjKHFy5hMWiJkSEgdfvGCewMg9C0lqFpLUAk amVYwaxalFZalFuoYGeklFmekZJbmJmTlAnqlebmpxcWJ6ak5iUrFecn7uJkZgKDAAwQ7GNVO dDzFKcjApifK6LdsbIcSXlJ9SmZFYnBFfVJqTWnyIUYaDQ0mCN3w3UE6wKDU9tSItMwcYlDBp CQ4eJRHeabuA0rzFBYm5xZnpEKlTjIpS4rwJIH0CIImM0jy4NlgkXGKUlRLmZQQ6RIinILUoN 7MEVf4VozgHo5IwbwjIFJ7MvBK46a+AFjMBLdZ2BVtckoiQkmpgXHzUh7XTze2N+qmIvKUSce 8tmlf9brftWnhmiWDJlOC/Af9/BH9nbm7I/Ob6561Vj7Bp/jPNR3M+3PjCHcF9RqX3//OsFYF K5gkzRXdJR4dor/D6vfyVSuWGpS9ELKaqWDeu5Ywx09t3ZnPHssQOi4jX3/qn/o9eK9td/jRP z/H+1VfJ+qsmK7EUZyQaajEXFScCAMaWYTp/AgAA X-Env-Sender: prvs=232365128=Paul.Durrant@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1488898686!84653686!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 51812 invoked from network); 7 Mar 2017 14:58:08 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2017 14:58:08 -0000 X-IronPort-AV: E=Sophos;i="5.35,258,1484006400"; d="scan'208";a="420950218" From: Paul Durrant To: Date: Tue, 7 Mar 2017 14:58:04 +0000 Message-ID: <1488898684-8105-1-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 Cc: Andrew Cooper , Paul Durrant , Jan Beulich Subject: [Xen-devel] [PATCH] vlapic/viridian: abort existing APIC assist if any vector is pending in ISR 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 The vlapic code already aborts an APIC assist if an interrupt is deferred because a higher priority interrupt has already been delivered (and hence its vector is pending in the ISR). However, it is also necessary to abort an APIC assist in the case where a higher priority is about to be delivered because, in either case, at least two vectors will be pending in the ISR and hence an EOI is necessary. Also, following on from the above reasoning, the decision to start a new APIC assist should clearly be based upon whether any other vector is pending in the ISR, regardless of whether it is lower or higher in priority. (In fact the code in question cannot be reached if the vector is lower in priority). Thus the single use of vlapic_find_lowest_vector() can be replaced with a call to vlapic_find_highest_isr() and the former function removed. Without this patch, because the logic is flawed, a domain_crash() results when an attempt is made to erroneously start a new APIC assist. Reported-by: Andrew Cooper Signed-off-by: Paul Durrant Reviewed-by: Jan Beulich --- Cc: Andrew Cooper Cc: Jan Beulich --- xen/arch/x86/hvm/vlapic.c | 54 +++++++++++++++++------------------------------ 1 file changed, 19 insertions(+), 35 deletions(-) diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c index 3fa3727..14356a7 100644 --- a/xen/arch/x86/hvm/vlapic.c +++ b/xen/arch/x86/hvm/vlapic.c @@ -95,19 +95,6 @@ static int vlapic_find_highest_vector(const void *bitmap) return (fls(word[word_offset*4]) - 1) + (word_offset * 32); } -static int vlapic_find_lowest_vector(const void *bitmap) -{ - const uint32_t *word = bitmap; - unsigned int word_offset; - - /* Work forwards through the bitmap (first 32-bit word in every four). */ - for ( word_offset = 0; word_offset < NR_VECTORS / 32; word_offset++) - if ( word[word_offset * 4] ) - return (ffs(word[word_offset * 4]) - 1) + (word_offset * 32); - - return -1; -} - /* * IRR-specific bitmap update & search routines. */ @@ -1201,19 +1188,17 @@ int vlapic_has_pending_irq(struct vcpu *v) vlapic_clear_vector(vector, &vlapic->regs->data[APIC_ISR]); isr = vlapic_find_highest_isr(vlapic); - isr = (isr != -1) ? isr : 0; - if ( (isr & 0xf0) >= (irr & 0xf0) ) - { - /* - * There's already a higher priority vector pending so - * we need to abort any previous APIC assist to ensure there - * is an EOI. - */ - viridian_abort_apic_assist(v); - return -1; - } + if ( isr == -1 ) + return irr; - return irr; + /* + * A vector is pending in the ISR so, regardless of whether the new + * vector in the IRR is lower or higher in priority, any pending + * APIC assist must be aborted to ensure an EOI. + */ + viridian_abort_apic_assist(v); + + return ((isr & 0xf0) < (irr & 0xf0)) ? irr : -1; } int vlapic_ack_pending_irq(struct vcpu *v, int vector, bool_t force_ack) @@ -1230,16 +1215,15 @@ int vlapic_ack_pending_irq(struct vcpu *v, int vector, bool_t force_ack) vlapic_test_vector(vector, &vlapic->regs->data[APIC_TMR]) ) goto done; - isr = vlapic_find_lowest_vector(&vlapic->regs->data[APIC_ISR]); - if ( isr >= 0 && isr < vector ) - goto done; - - /* - * This vector is edge triggered and there are no lower priority - * vectors pending, so we can use APIC assist to avoid exiting - * for EOI. - */ - viridian_start_apic_assist(v, vector); + isr = vlapic_find_highest_isr(vlapic); + if ( isr == -1 ) + { + /* + * This vector is edge triggered and no other vectors are pending + * in the ISR so we can use APIC assist to avoid exiting for EOI. + */ + viridian_start_apic_assist(v, vector); + } done: vlapic_set_vector(vector, &vlapic->regs->data[APIC_ISR]);