From nobody Mon Feb 9 16:34:19 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=none (zohomail.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail(p=none dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1582719658; cv=none; d=zohomail.com; s=zohoarc; b=mVgp9KnOK9mcYPKl+6zv7n03uND4Bskq4fQzbBUocrNNwFVF2NRou/On0wTJRfQR5/qyG97MVk7IY4q70jVxI3lPaKDZ92X9BOxXWBcoFoewNkICtPo0l7RsczktXuCbDkxOHBeoHkj5u3V/WpGhXb4S4gEhiJ/8l/57DeQjKAo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1582719658; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=wGNIrgQPDZvWtbJj6V6ti6zGYdDNwZITEQhLdmu+FyY=; b=O9kAQ0HYNxF9i1tLs5cWj0ahm9q2DrAMWFqd/CwrbumD7M5rVGckyETk4CVAqO2Of7zK40MWD/QbSbay1YsZxCMO9/jBW3IRHYkJEy2gBfHpM6v4ThFuPW1Ia27/3B/F7D+bR4FifZZoaz3zgKwbMALMhXp6UPmDDelmlYObB20= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=none (zohomail.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1582719658183923.8956243306595; Wed, 26 Feb 2020 04:20:58 -0800 (PST) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1j6vfj-0008C8-Q8; Wed, 26 Feb 2020 12:20:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1j6vfi-0008Be-Ft for xen-devel@lists.xenproject.org; Wed, 26 Feb 2020 12:20:14 +0000 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 56eda4ea-5892-11ea-8cb6-bc764e2007e4; Wed, 26 Feb 2020 12:20:14 +0000 (UTC) X-Inumbo-ID: 56eda4ea-5892-11ea-8cb6-bc764e2007e4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1582719614; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=QLqmgx5Dkvpg14/6NDnlCJdFLL9NI3RbIxt80YtkH4I=; b=Z9Ijaim4l29uKt5mVxSX/2b6ZA+RRgNQHnzPPXA9WWI5zqFME++UWrJR lkTG17SQUa/NuM98REEgJu97wqEbc7t8m5RgxjgTrUdxoE9DggOV4YeYk T7CuZNwa53H9k1NJxdbEk1PxSo7py4vn4OFYQ3APTSciI8icP1j4yCXCD o=; Authentication-Results: esa3.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 (zohomail.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Received-SPF: None (esa3.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=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa3.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=esa3.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 (esa3.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=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: 7FvUuyh9OnB47C8WqBEivpz7Zd9bsnWTM+La+rItXbcLbixPYrP/U5rkJHjTa5OZJBXPTZX+fs tPv9qLdBl8N2ULd5+R1sj1nlgFQ9ybSzI/eif+lZQ0qzpTBhwo19zi/DsuDqmBLbZf9aDWFhWi 5BjHckAQUjtH5FCbcvUeZF7fmpVJU9SIsRwDr03/YXsXN1vmuoFHK5ip66yxBimMuWETdditkk nYNTQseSRQV0Sx0SILMTbYKef9ysokbO7L3AlG+sFuC6QZ1/UiJnZOtLf7prBzuryUZzzGovZW Fxw= X-SBRS: 2.7 X-MesageID: 13014362 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.70,488,1574139600"; d="scan'208";a="13014362" From: Roger Pau Monne To: Date: Wed, 26 Feb 2020 13:19:21 +0100 Message-ID: <20200226121921.28627-5-roger.pau@citrix.com> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200226121921.28627-1-roger.pau@citrix.com> References: <20200226121921.28627-1-roger.pau@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH v4 4/4] x86/smp: do not use scratch_cpumask when in interrupt or exception context 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 , Sander Eikelenboom , Wei Liu , Jan Beulich , Roger Pau Monne Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Using scratch_cpumask in send_IPI_mask is not safe in IRQ or exception context because it can nest, and hence send_IPI_mask could be overwriting another user scratch cpumask data when used in such contexts. Instead introduce a new cpumask to be used by send_IPI_mask, and disable interrupts while using it. Fallback to not using the scratch cpumask (and hence not attemping to optimize IPI sending by using a shorthand) when in IRQ or exception context. Note that the scratch cpumask cannot be used when non-maskable interrupts are being serviced (NMI or #MC) and hence fallback to not using the shorthand in that case, like it was done previously. Fixes: 5500d265a2a8 ('x86/smp: use APIC ALLBUT destination shorthand when p= ossible') Reported-by: Sander Eikelenboom Signed-off-by: Roger Pau Monn=C3=A9 --- Changes since v3: - Do not use a dedicated cpumask, and instead prevent usage when in IRQ context. Changes since v2: - Fallback to the previous IPI sending mechanism in #MC or #NMI context. Changes since v1: - Don't use the shorthand when in #MC or #NMI context. --- xen/arch/x86/smp.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c index 55d08c9d52..fa9bfe4d54 100644 --- a/xen/arch/x86/smp.c +++ b/xen/arch/x86/smp.c @@ -69,6 +69,18 @@ void send_IPI_mask(const cpumask_t *mask, int vector) bool cpus_locked =3D false; cpumask_t *scratch =3D this_cpu(scratch_cpumask); =20 + if ( in_irq() ||=C2=A0in_mce() || in_nmi() ) + { + /* + * When in IRQ, NMI or #MC context fallback to the old (and simple= r) + * IPI sending routine, and avoid doing any performance optimizati= ons + * (like using a shorthand) in order to avoid using the scratch + * cpumask which cannot be used in interrupt context. + */ + alternative_vcall(genapic.send_IPI_mask, mask, vector); + return; + } + /* * This can only be safely used when no CPU hotplug or unplug operatio= ns * are taking place, there are no offline CPUs (unless those have been --=20 2.25.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel