Received: by 10.223.185.111 with SMTP id b44csp432058wrg; Fri, 9 Mar 2018 07:22:44 -0800 (PST) X-Google-Smtp-Source: AG47ELtKr3zBKRbnnwEbUE48U2CPmyqe1pBuWdMnVsQWNAmf5o6lF7wC3R3BsBExJ040CHRnRzGM X-Received: by 2002:a17:902:aa83:: with SMTP id d3-v6mr27795694plr.36.1520608963966; Fri, 09 Mar 2018 07:22:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520608963; cv=none; d=google.com; s=arc-20160816; b=qqSB7dSmGgZLzx2vvyZKOftjysgIUuBTA194AMKlSJscLNIeiTm6rEQhi53xjpGFP8 x6XPCRghN0RJFqlWFMCH1Pw0q2dF8AG8VNiuop5T3Z8Yu2Ogrkzug15JGGg+RHdjZ50n setdwwN4f7F8A6hnNzk7mEJDOYvi07e17fqgPUUfTa8bwDvbjRolycuP12i1xNDnKVhH ydwPhp7NVpn1Q6bWcMfkBRx2bAN3EUX+kQ7euT4UnUZnmY5b4pwLR/7Cw7LLhqkZUTZz BgmTgglXW89GUvbyTF+G4/UNr7MIFBtWsG682I+mi1xubW42mz3m7eYBYjvxjg5vJkuN IGEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from:arc-authentication-results; bh=p47Nwk9lnOgoUpA4HRz1ybO3xcUFpRjLmBV8kKrf0Hg=; b=avQNLvmVVzwvtLV5m8hO7WFXd0qknWYYaI+hWLkodJmCdtwYj4ttcwBDYIpPn06nEw TFO1+yu40NnOPFqroJuWxNEV0Zx6A+DNfIdAcM3N25z+vcgoU86tQUDmjf6sS6WTL7D4 1EIl1QWCF61rMysCVZdSp/rPUj2XByi/OG0vVPDN8rBnSC4iL/5JQIb5eK2hjhB8BfIl ciGlHgRx5IbduPNhKL0k5/VFuUDgVyd99FC87R3c5GNxg5wc+F6/SvMbHj2qw9D5eicC Rd0/oNxo2yS6RmGcmAc1OBZ4M2RSHoszz9dhhxZei8EuOYq2w30iFHXkiFciM1TKaRvi T5CA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b16si837621pgs.810.2018.03.09.07.22.29; Fri, 09 Mar 2018 07:22:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751290AbeCIPVZ (ORCPT + 99 others); Fri, 9 Mar 2018 10:21:25 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:43874 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751102AbeCIPVX (ORCPT ); Fri, 9 Mar 2018 10:21:23 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 19828BD9E; Fri, 9 Mar 2018 15:21:23 +0000 (UTC) Received: from vitty.brq.redhat.com.redhat.com (unknown [10.43.2.155]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C3CCB2026DFD; Fri, 9 Mar 2018 15:21:20 +0000 (UTC) From: Vitaly Kuznetsov To: Radim =?utf-8?B?S3LEjW3DocWZ?= Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, Paolo Bonzini , "K. Y. Srinivasan" , "Michael Kelley \(EOSG\)" , Roman Kagan , "Denis V . Lunev" Subject: Re: [PATCH v2 2/3] x86/kvm/hyper-v: remove stale entries from vec_bitmap/auto_eoi_bitmap on vector change References: <20180301141514.3482-1-vkuznets@redhat.com> <20180301141514.3482-3-vkuznets@redhat.com> <20180308210804.GN12290@flask> Date: Fri, 09 Mar 2018 16:21:19 +0100 In-Reply-To: <20180308210804.GN12290@flask> ("Radim \=\?utf-8\?B\?S3LEjW3DocWZ\?\= \=\?utf-8\?B\?Iidz\?\= message of "Thu, 8 Mar 2018 22:08:04 +0100") Message-ID: <87muzhe0ls.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 09 Mar 2018 15:21:23 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 09 Mar 2018 15:21:23 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'vkuznets@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Radim Krčmář writes: > 2018-03-01 15:15+0100, Vitaly Kuznetsov: >> When a new vector is written to SINx we update vec_bitmap/auto_eoi_bitmap >> but we forget to remove old vector from these masks (in case it is not >> present in some other SINTx). >> >> Signed-off-by: Vitaly Kuznetsov >> Reviewed-by: Roman Kagan >> --- >> arch/x86/include/uapi/asm/hyperv.h | 2 ++ >> arch/x86/kvm/hyperv.c | 32 ++++++++++++++++++++++---------- >> 2 files changed, 24 insertions(+), 10 deletions(-) >> >> diff --git a/arch/x86/include/uapi/asm/hyperv.h b/arch/x86/include/uapi/asm/hyperv.h >> index 197c2e6c7376..62c778a303a1 100644 >> --- a/arch/x86/include/uapi/asm/hyperv.h >> +++ b/arch/x86/include/uapi/asm/hyperv.h >> @@ -318,6 +318,8 @@ typedef struct _HV_REFERENCE_TSC_PAGE { >> #define HV_SYNIC_SINT_COUNT (16) >> /* Define the expected SynIC version. */ >> #define HV_SYNIC_VERSION_1 (0x1) >> +/* Valid SynIC vectors are 16-255. */ >> +#define HV_SYNIC_FIRST_VALID_VECTOR (16) >> >> #define HV_SYNIC_CONTROL_ENABLE (1ULL << 0) >> #define HV_SYNIC_SIMP_ENABLE (1ULL << 0) >> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c >> index 05f414525538..6d14f808145d 100644 >> --- a/arch/x86/kvm/hyperv.c >> +++ b/arch/x86/kvm/hyperv.c >> @@ -74,13 +74,30 @@ static bool synic_has_vector_auto_eoi(struct kvm_vcpu_hv_synic *synic, >> return false; >> } >> >> +static void synic_update_vector(struct kvm_vcpu_hv_synic *synic, >> + int vector) >> +{ >> + if (vector < HV_SYNIC_FIRST_VALID_VECTOR) >> + return; >> + >> + if (synic_has_vector_connected(synic, vector)) >> + __set_bit(vector, synic->vec_bitmap); >> + else >> + __clear_bit(vector, synic->vec_bitmap); >> + >> + if (synic_has_vector_auto_eoi(synic, vector)) >> + __set_bit(vector, synic->auto_eoi_bitmap); >> + else >> + __clear_bit(vector, synic->auto_eoi_bitmap); >> +} >> + >> static int synic_set_sint(struct kvm_vcpu_hv_synic *synic, int sint, >> u64 data, bool host) >> { >> - int vector; >> + int vector, old_vector; >> >> vector = data & HV_SYNIC_SINT_VECTOR_MASK; >> - if (vector < 16 && !host) >> + if (vector < HV_SYNIC_FIRST_VALID_VECTOR && !host) >> return 1; >> /* >> * Guest may configure multiple SINTs to use the same vector, so >> @@ -88,18 +105,13 @@ static int synic_set_sint(struct kvm_vcpu_hv_synic *synic, int sint, >> * bitmap of vectors with auto-eoi behavior. The bitmaps are >> * updated here, and atomically queried on fast paths. >> */ >> + old_vector = synic_read_sint(synic, sint) & HV_SYNIC_SINT_VECTOR_MASK; >> >> atomic64_set(&synic->sint[sint], data); >> >> - if (synic_has_vector_connected(synic, vector)) >> - __set_bit(vector, synic->vec_bitmap); >> - else >> - __clear_bit(vector, synic->vec_bitmap); >> + synic_update_vector(synic, old_vector); >> >> - if (synic_has_vector_auto_eoi(synic, vector)) >> - __set_bit(vector, synic->auto_eoi_bitmap); >> - else >> - __clear_bit(vector, synic->auto_eoi_bitmap); >> + synic_update_vector(synic, vector); > > This looks like it solves the problem when we get two SINTs with the > same vector back-to-back , but shouldn't these bits really be cleared on > EOI (either auto or manual)? Hmm, I was trying to address the following issue: guest programs SynIC's SINTx with some vector but later re-programs it with a different one. Without the patch synic->vec_bitmap and synic->auto_eoi_bitmap keep stale data. If there's no concurrent interrupt than we're safe, but what happens if there is one... kvm_hv_synic_send_eoi() already goes through all SINTx but we already updated vector so it won't find any. We could've added something like 'old_vector' but what if the request with this vector came _after_ we re-programed SynIC (and, so, it wasn't meant to be serviced by SynIC?)? -- Vitaly