From patchwork Tue Mar 3 17:20:41 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Roger_Pau_Monn=C3=A9?= X-Patchwork-Id: 11418549 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2599B92A for ; Tue, 3 Mar 2020 17:22:06 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 01E9A20863 for ; Tue, 3 Mar 2020 17:22:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="aXApbRft" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 01E9A20863 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1j9BEC-0007QB-Mx; Tue, 03 Mar 2020 17:21:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1j9BEB-0007Q0-3i for xen-devel@lists.xenproject.org; Tue, 03 Mar 2020 17:21:07 +0000 X-Inumbo-ID: 5ca69b04-5d73-11ea-8adc-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5ca69b04-5d73-11ea-8adc-bc764e2007e4; Tue, 03 Mar 2020 17:21:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1583256064; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=1QAshLi++zhF5fDm/vI1ICT9O00yj9QFwHZ8PPKtRbk=; b=aXApbRftJsbWEPVjm7jtyd36rlH+qCjFOjd5Y2jIG5MAnsq3v/4CVk2r cLxzW0RaBoEQ6BXdAviyaQwGeowjKyov9bCJFw1aerDqLIPA+GhK560rL 71Dv9rjQ5+LHawHCv338CPVHGGN1U6vvWC97u6mJmZr93BEPZe9MmKhbf k=; Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@citrix.com; spf=Pass smtp.mailfrom=roger.pau@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender authenticity information available from domain of roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of roger.pau@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ip4:168.245.78.127 ~all" Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: ZwqM2OeeTiVitwRYzVHCLR/OLxlvRyd6sN5Gt91x4E1j1mRgi+U9zZyqnRwsgeiVvyHJeUrszI 0Axf2RPWqFAfe1sUvRBXrMndBXg27ThHZJKO1TTQI8d0qxpJH6PeAt9pdNMn38nd+kxhHpt9DG +0w2Zgunmtxt+mUo9aq2iopkkYhsLFzjf3GL0lCj+XubZx6wn/+sONl4Gq/WxivNAp2Ije/prN Y+FL5iRavqWHCgnao+4p0hK7Cl8piTSnUpXbmoljo6YioSa3Yhodf8MV/hXTZEq/doCoBy/RwJ Zts= X-SBRS: 2.7 X-MesageID: 13775850 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.70,511,1574139600"; d="scan'208";a="13775850" From: Roger Pau Monne To: Date: Tue, 3 Mar 2020 18:20:41 +0100 Message-ID: <20200303172046.50569-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200303172046.50569-1-roger.pau@citrix.com> References: <20200303172046.50569-1-roger.pau@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH v6 1/6] x86/hvm: allow ASID flush when v != current X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Wei Liu , Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Current implementation of hvm_asid_flush_vcpu is not safe to use unless the target vCPU is either paused or the currently running one, as it modifies the generation without any locking. Fix this by using atomic operations when accessing the generation field, both in hvm_asid_flush_vcpu_asid and other ASID functions. This allows to safely flush the current ASID generation. Note that for the flush to take effect if the vCPU is currently running a vmexit is required. Compilers will normally do such writes and reads as a single instruction, so the usage of atomic operations is mostly used as a safety measure. Note the same could be achieved by introducing an extra field to hvm_vcpu_asid that signals hvm_asid_handle_vmenter the need to call hvm_asid_flush_vcpu on the given vCPU before vmentry, this however seems unnecessary as hvm_asid_flush_vcpu itself only sets two vCPU fields to 0, so there's no need to delay this to the vmentry ASID helper. This is not a bugfix as no callers that would violate the assumptions listed in the first paragraph have been found, but a preparatory change in order to allow remote flushing of HVM vCPUs. Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu Acked-by: Jan Beulich --- xen/arch/x86/hvm/asid.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/asid.c b/xen/arch/x86/hvm/asid.c index 8e00a28443..63ce462d56 100644 --- a/xen/arch/x86/hvm/asid.c +++ b/xen/arch/x86/hvm/asid.c @@ -83,7 +83,7 @@ void hvm_asid_init(int nasids) void hvm_asid_flush_vcpu_asid(struct hvm_vcpu_asid *asid) { - asid->generation = 0; + write_atomic(&asid->generation, 0); } void hvm_asid_flush_vcpu(struct vcpu *v) @@ -121,7 +121,7 @@ bool_t hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid) goto disabled; /* Test if VCPU has valid ASID. */ - if ( asid->generation == data->core_asid_generation ) + if ( read_atomic(&asid->generation) == data->core_asid_generation ) return 0; /* If there are no free ASIDs, need to go to a new generation */ @@ -135,7 +135,7 @@ bool_t hvm_asid_handle_vmenter(struct hvm_vcpu_asid *asid) /* Now guaranteed to be a free ASID. */ asid->asid = data->next_asid++; - asid->generation = data->core_asid_generation; + write_atomic(&asid->generation, data->core_asid_generation); /* * When we assign ASID 1, flush all TLB entries as we are starting a new