Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp2828931rwl; Thu, 13 Apr 2023 11:23:19 -0700 (PDT) X-Google-Smtp-Source: AKy350asB1zMlkfr6YXTbAuenNbOZLNOEvm1dg/3EZr3F34x/w+MkVlXe4YbmTyKVIFWlIfdFht3 X-Received: by 2002:a17:90a:1286:b0:246:bb61:4a5b with SMTP id g6-20020a17090a128600b00246bb614a5bmr3016204pja.8.1681410199520; Thu, 13 Apr 2023 11:23:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681410199; cv=none; d=google.com; s=arc-20160816; b=owP/oXvdWDocLMNvozEv8WY3C0dDs31pcEzDPQMhHsWo6uD2Fl2e4YQc38nfbcP8uq XZeiA4qQYMhgiDaM2G10Zi4YxMQQ2TQFliMnc8j1WRY835w6t3G+V+DJyPJx6fUkkduQ GPDdbJDHM/tkm2ygaPjAMaCaBRLSz9LDP6iuGJJ/prm8aYuFpPI8Tov7uOLN4LNzF/M4 DVKWuzFqXSL1exShYAHGIyubviIi6eVKs1tcpMdILpyw7xufnv6T66nGT367VnBsJpZE mTw5v7xWER5BEHHTh7SOjf35BG6j4qnupXKMNwlVKxSm41oW0RNksvCpM6usRz7k9qCW BAoA== 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:dkim-signature :dkim-filter; bh=6YfKtjnCRgFmVE/Ca0ZyR4QZiE7Jis7k6H6rAsEAPZU=; b=mPyd2Mt5+yEJMcZceEpHIa/I7eJHtBShsKgKjmIz7UJGxlwDB7dkwwDwhXIKCOn7VI orVHHccYsHKQKTRAjH+2fEi8RUtXkcPgZHeDZfx9gBx8/8AgXSnaIaK4fp4EgX/iYMVC Y2w02M7KEiaB3riS7o7i0CkXfVZ1x8neGJPOlCcO4KsIdAw5e4sle9q/QbBdvTVEvjDt VPoeV/76MsDysntw9qLOfWazYgEUdGTOFnJacR58EVJE61OtNjkTURHQamR4SAElMbxh Fy93x+EbWCIndtAJc6zw9ZrdMihTY0lEq4qDrG4Xa+Ifp1b5Fkf8HcoG5pCLm807Fnwk UFog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=S3Gvqc1R; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t29-20020a63225d000000b005184eb693a1si2668104pgm.94.2023.04.13.11.23.05; Thu, 13 Apr 2023 11:23:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=S3Gvqc1R; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229961AbjDMSKj (ORCPT + 99 others); Thu, 13 Apr 2023 14:10:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbjDMSKh (ORCPT ); Thu, 13 Apr 2023 14:10:37 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C769D30DA; Thu, 13 Apr 2023 11:10:36 -0700 (PDT) Received: from skinsburskii.localdomain (c-67-170-100-148.hsd1.wa.comcast.net [67.170.100.148]) by linux.microsoft.com (Postfix) with ESMTPSA id 0BCD621779C8; Thu, 13 Apr 2023 11:10:36 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 0BCD621779C8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1681409436; bh=6YfKtjnCRgFmVE/Ca0ZyR4QZiE7Jis7k6H6rAsEAPZU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=S3Gvqc1RaHcz6snRbXHmQXTM0SYsvqF6oKohYBa/7Z3LmFcoJCmeLnxrr98lCB766 3Msmz7+likaFw4hI6mtDPrDjYlo+Z1rG8z4f37PptiyClJvRc2351MYL1MKxdZBo17 qwfYfpxymamCaFZQMh8xwCSViKCQS+f/fl6hiA2c= Date: Wed, 12 Apr 2023 09:36:16 -0700 From: Stanislav Kinsburskii To: Thomas Gleixner Cc: Stanislav Kinsburskii , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] x86/hyperv: Expose an helper to map PCI interrupts Message-ID: <20230412163616.GA1535@skinsburskii.localdomain> References: <168079806973.14175.17999267023207421381.stgit@skinsburskii.localdomain> <168079870998.14175.16015623662679754647.stgit@skinsburskii.localdomain> <87o7nrzy9e.ffs@tglx> <20230412161951.GA894@skinsburskii.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230412161951.GA894@skinsburskii.localdomain> X-Spam-Status: No, score=-18.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_24_48, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 12, 2023 at 09:19:51AM -0700, Stanislav Kinsburskii wrote: > On Thu, Apr 13, 2023 at 03:51:09PM +0200, Thomas Gleixner wrote: > > On Thu, Apr 06 2023 at 09:33, Stanislav Kinsburskii wrote: > > > This patch moves > > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#submittingpatches > > https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#changelog > > > > Thanks. I'll elaborate on the reationale in the next revision. > > > > a part of currently internal logic into the new > > > hv_map_msi_interrupt function and makes it globally available helper, > > > which will be used to map PCI interrupts in case of root partition. > > > > > -static int hv_map_msi_interrupt(struct pci_dev *dev, int cpu, int vector, > > > - struct hv_interrupt_entry *entry) > > > +/** > > > + * hv_map_msi_interrupt() - "Map" the MSI IRQ in the hypervisor. > > > > So if you need to put "" on Map then maybe your function is > > misnomed. Either it maps or it does not, right? > > > > Thanks, I'll remove the quotation marks in the next update. > > > > + * @data: Describes the IRQ > > > + * @out_entry: Hypervisor (MSI) interrupt entry (can be NULL) > > > + * > > > + * Map the IRQ in the hypervisor by issuing a MAP_DEVICE_INTERRUPT hypercall. > > > + */ > > > +int hv_map_msi_interrupt(struct irq_data *data, > > > + struct hv_interrupt_entry *out_entry) > > > { > > > - union hv_device_id device_id = hv_build_pci_dev_id(dev); > > > + struct msi_desc *msidesc; > > > + struct pci_dev *dev; > > > + union hv_device_id device_id; > > > + struct hv_interrupt_entry dummy, *entry; > > > + struct irq_cfg *cfg = irqd_cfg(data); > > > + const cpumask_t *affinity; > > > + int cpu, vector; > > > + > > > + msidesc = irq_data_get_msi_desc(data); > > > + dev = msi_desc_to_pci_dev(msidesc); > > > + device_id = hv_build_pci_dev_id(dev); > > > + affinity = irq_data_get_effective_affinity_mask(data); > > > + cpu = cpumask_first_and(affinity, cpu_online_mask); > > > > The effective affinity mask of MSI interrupts consists only of online > > CPUs, to be accurate: it has exactly one online CPU set. > > > > But even if it would have only offline CPUs then the result would be: > > > > cpu = nr_cpu_ids > > > > which is definitely invalid. While a disabled vector targeted to an > > offline CPU is not necessarily invalid. > > > > Thank you for diving into this logic. > > Although this patch only tosses the code and doens't make any functional > changes, I guess if the fix for the the cpu is found has is required, it > has to be in a separated patch. > > Would you mind to elaborate more of the problem(s)? > Do you mean that the result of cpumask_first_and has to be checked for not > being >= nr_cpus_ids? > Or do you mean there is no need to check the affinity against > cpu_online_mask at all ans we can simply take any first bit from the > effective affinity mask? > > Also, could ou elaborate more on the disabled vector target to an > offline CPU? Is there any use case for such scenario (in this case we > might want to support it)? > > I guess the goal of this code is to make sure that hypervisor on't be > configured to deliver MSI to an online CPU. > I'm sorry, there were a lot of typos. Let me try again: Thank you for diving into this logic. Although this patch only tosses the code and doens't make any functional changes, I guess if the fix for the used cpu id is required, it has to be in a separated patch. Would you mind to elaborate more of the problem(s)? Do you mean that the result of cpumask_first_and has to be checked for not being >= nr_cpus_ids? Or do you mean that there is no need to check the irq affinity against cpu_online_mask at all and we can simply take any first bit from the effective affinity mask? Also, could you elaborate more on the disabled vector targeting an offline CPU? Is there any use case for such scenario (in this case we might want to support it)? I guess the goal of this code is to make sure that hypervisor won't be configured to deliver an MSI to an offline CPU. Thanks, Stanislav > Thanks, > Stanislav > > > Thanks, > > > > tglx