From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 47131C982FA for ; Wed, 23 Sep 2026 10:37:50 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1430154.1652756 (Exim 4.92) (envelope-from ) id 1x9KM2-0006Pj-O6; Wed, 23 Sep 2026 10:37:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1430154.1652756; Wed, 23 Sep 2026 10:37:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KM2-0006Pc-Kf; Wed, 23 Sep 2026 10:37:34 +0000 Received: by outflank-mailman (input) for mailman id 1430154; Wed, 23 Sep 2026 10:37:33 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x9KM1-0006PE-9C for xen-devel@lists.xenproject.org; Wed, 23 Sep 2026 10:37:33 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1x9KM0-00DV8g-23; Wed, 23 Sep 2026 10:37:32 +0000 Received: from 224.pool85-54-217.dynamic.orange.es ([85.54.217.224] helo=localhost) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x9KM1-007YNz-0R; Wed, 23 Sep 2026 10:37:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date; bh=pRiwT0funSy0byFkZn08jBZ6KbTXmhhCcw9QDik8O8Q=; b=vVVIvluZHWArWsp+wCYAGSogFQ DXxGgEKx3daxNQDFWB/b135z2/7j+7nA1TXJpQRH8wABR4tC3I4FeM0Onsp5h7JReshmpZh3x1PF0 zsu8AKdkgyPyhBujsRKlOJ6QCmdZXUfEG8fvIf0I5ef6BZ+0bYjYqV4TSScDpA1yaB64=; Date: Wed, 23 Sep 2026 12:37:31 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Teddy Astie , Julian Vetter Subject: Re: [PATCH 2/6] x86/pass-through: no locking around pt_irq_{create,destroy}_bind() Message-ID: References: <92b0a72a-44df-424f-acbe-58d7167f1c4d@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <92b0a72a-44df-424f-acbe-58d7167f1c4d@suse.com> On Tue, Sep 08, 2026 at 03:01:51PM +0200, Jan Beulich wrote: > The questionable use of pcidevs_lock() there was discussed more than once. > It really is pointless: The functions synchronize primarily via the per- > domain event lock. They also may already be called with the global PCI > devices lock not held: See hvm/vmsi.c:vpci_msi_update(), > hvm/vmsi.c:vpci_msi_arch_update(), and hvm/vmsi.c:vpci_msi_disable(). > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/domctl.c > +++ b/xen/arch/x86/domctl.c > @@ -636,10 +636,7 @@ long arch_do_domctl( > ret = -EPERM; > else if ( is_iommu_enabled(d) ) > { > - pcidevs_lock(); > ret = pt_irq_create_bind(d, bind); > - pcidevs_unlock(); pt_irq_create_bind() might call into msixtbl_pt_register() which requires either the pcidevs_lock() or the per-domain d->pci_lock lock to be taken, which I think is not the case in the context here? Adding such locking aroiund the calls would mimic the vPCI context, where d->pci_lock is also taken while executing the vPCI handlers. Thanks, Roger.