Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp1700149pxb; Fri, 10 Sep 2021 11:37:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfH8PG9A0mJ6XI175zvPyZ8fY6+Zg0+Onvz+y5Rh9jahmHMYYFwRwRsAprHwQ4fcfYeTBm X-Received: by 2002:a6b:710f:: with SMTP id q15mr8282837iog.77.1631299056675; Fri, 10 Sep 2021 11:37:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631299056; cv=none; d=google.com; s=arc-20160816; b=CU8nt0Hlc8wDfkcQZliAg5VLwWmIXc2OSlji0Kfsd3fOXenBoxiIdHYeh5Vi4SQvFQ FLmvm5XdbTanEuWMbZR4YMw/9A5de9KqbATjhjW+0fxivgWj7xSD2+XNwQqLqncN4fZ7 4qJ87hSYgksr07Ctz3X2Xw7ehyxZlxdNSG+oJJ/ErE6/XRfnANJe+1lxM6fa5ogtGPd+ rCHufSCsQoC9J9riLpA95WM1BS/0M42EG84NnlCDF8RzsGu+S5cuTid2vSeYFvZKaPe2 YpQBmSL/VeSk23+YpwVy4CPZooGyJzckiHEyLvUfaPfCIFM0TWFN6xb+Uf/sD011g3ZF Zk7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=zhtx2jHO2Z87aFol24mA1+eiErkclDQsj/2ggqYevms=; b=nVmdFJZJvN7QDpdHl01gctySRTwQtKL9OR2pdSqF2qjLFUnybR+s2ckeO3eex/RApq NAG/Q7j08RGpeHh5ueqigxGfe8Fv8zhkm1taYUs1Qjme5LbHniHP+i2r0eGlblpekXal QizQMq9Ksj4hu2xlI1RKlZkevv1+ghUd6W06k0OC5yNp8rFsKLldDf7/gPBUsVCOJZSW wcvx+50wymRSj10RJL5v9AqkSyOuDnEvjwnLT2Rotj9vxHC4OlXKyFGIHc3SDhbfqseO OlGElilTb8s8/CG8RSWjf8CEvpqIvJTjPH+nsLT5AWxE66KiQ/Rs16pVPXwtmVm47wjq d4EA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l24si5675760jaf.107.2021.09.10.11.37.25; Fri, 10 Sep 2021 11:37:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231645AbhIJShr (ORCPT + 99 others); Fri, 10 Sep 2021 14:37:47 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:36721 "EHLO mail-wr1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229476AbhIJShq (ORCPT ); Fri, 10 Sep 2021 14:37:46 -0400 Received: by mail-wr1-f47.google.com with SMTP id g16so3949271wrb.3; Fri, 10 Sep 2021 11:36:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zhtx2jHO2Z87aFol24mA1+eiErkclDQsj/2ggqYevms=; b=IJcvhgoyiIEtnGUTZ7grhq5MvXYuvsC0O4vUHZUG3/Fjh1+gjUhzCnSGP+uhI0ERNY HU0EJBjaOrGN6GFn5EGAAlaa5zW/ccQlo6yNUci2kexZIUT/LDGMj9pCuA5L5Uz2/k6p mAhGiTV81GBvboq7fD4DgvxggxKb6QMAzhHFgNtf/OwOcQMJ3RqJ24RcVI1s9kLt7GGS /nZTbv8gwe+TYBYF/4tBc3K642xjmhRy3aUkm8uHNv53v6kbd0ApAB32yKmpKdr8PtII iaSPMa4U3IvT3CJiKY7Lgkn9IL/CNS0TLhLGfe4d3CJiQo/EyoOu8chMwpjfShmest+N I8+A== X-Gm-Message-State: AOAM531txRWPPgXYZTQJ4VtUzMAjAnSMX/E+xfaLIj0m0LcOXCxa6uI2 xkadwOdFxk+m0qvCIvYHmTK1dJnsXsY= X-Received: by 2002:adf:e10c:: with SMTP id t12mr11455948wrz.36.1631298994269; Fri, 10 Sep 2021 11:36:34 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id l16sm6135813wrh.44.2021.09.10.11.36.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Sep 2021 11:36:33 -0700 (PDT) Date: Fri, 10 Sep 2021 18:36:32 +0000 From: Wei Liu To: Michael Kelley Cc: Wei Liu , Linux on Hyper-V List , KY Srinivasan , Haiyang Zhang , Dexuan Cui , Stephen Hemminger , Linus Torvalds , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Subject: Re: [PATCH 2/2] x86/hyperv: remove on-stack cpumask from hv_send_ipi_mask_allbutself Message-ID: <20210910183632.5i6lu2h23ljofdru@liuwe-devbox-debian-v2> References: <20210908194243.238523-1-wei.liu@kernel.org> <20210908194243.238523-3-wei.liu@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 10, 2021 at 05:25:15PM +0000, Michael Kelley wrote: > From: Wei Liu Sent: Wednesday, September 8, 2021 12:43 PM > > [...] > > -static bool __send_ipi_mask(const struct cpumask *mask, int vector) > > +static bool __send_ipi_mask(const struct cpumask *mask, int vector, > > + bool exclude_self) > > { > > - int cur_cpu, vcpu; > > + int cur_cpu, vcpu, this_cpu = smp_processor_id(); > > struct hv_send_ipi ipi_arg; > > u64 status; > > > > @@ -172,6 +177,8 @@ static bool __send_ipi_mask(const struct cpumask *mask, int vector) > > ipi_arg.cpu_mask = 0; > > > > for_each_cpu(cur_cpu, mask) { > > + if (exclude_self && cur_cpu == this_cpu) > > + continue; > > vcpu = hv_cpu_number_to_vp_number(cur_cpu); > > if (vcpu == VP_INVAL) > > return false; > > @@ -191,7 +198,7 @@ static bool __send_ipi_mask(const struct cpumask *mask, int vector) > > return hv_result_success(status); > > > > do_ex_hypercall: > > - return __send_ipi_mask_ex(mask, vector); > > + return __send_ipi_mask_ex(mask, vector, exclude_self); > > } > > This all looks correct to me, except for one difference compared with the > current code. In the current code, if the cpumask passed to > hv_send_ipi_mask_allbutself() indicates only a single CPU that is "self", > __send_ipi_mask() will detect that the cpumask is now empty, and > correctly return success without making the hypercall. But > the new code will make the hypercall with an empty input mask (both > in the SEND_IPI and SEND_IPI_EX cases). The Hyper-V TLFS is silent > on whether such a hypercall is a no-op that returns success or is an > error. We'll have a problem if it is an error. I think the safest thing > is to enhance the cpumask_empty() test at the beginning of > __send_ipi_mask() to also detect the case where only a single CPU > is specified, and it is "self". This could be done using cpumask_weight() > and checking for zero as the "empty" case. Then check for "1", and if > exclude_self is set, check if it is the "self" CPU. Sure. Making this change should not be too difficult. Wei.