From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AAF4C330D35 for ; Thu, 5 Feb 2026 21:27:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770326835; cv=none; b=eKtsfu0e4QdcsXE9CdmLVHlNRe1P4csSvg9eEonk6FtpSbnOIqrzr5sUN0KrAlIejIZ/sIO7iDIX4cX4OMInNckUsp+yk8l/OXbT7hB3W8/CQRnQpqnbnRKwQm9eD+Lk5pu1xKd6NY6wHBcWgkBe8qx6EhcdhYTWyNRMDsqr5pA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770326835; c=relaxed/simple; bh=onUcEIsNRNpDK4k+ZwYKjhl/82j2tz+8TXLBfpER88U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=W5wwuyqUz7MZWgcNPNiqZxMIEUZYRA+v6fN3PaPU/yZ7W3Ae1Qzu81REgu0exCLQiRWoRc+JBJNydDbPu5iM5lBvbbrE+Rsi6paqCBLoQv+x4RCmOMoV14Ny82/kgoTf5D00TPR9i+tvRFBZ4PGsmAbCNhAHQvhQAbI6PnU4pVA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=IkiV7WEJ; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=t5/opbZR; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="IkiV7WEJ"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="t5/opbZR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770326834; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rGchRpNtHpsURPrx/vVHrgmCPFSkjjSjv6Ar1R+yRYU=; b=IkiV7WEJpTiUrUhfoG8JMj94girazSGWjdLGAtGZEOv7sed9e42/rXhlHFO8DCuriBG8Qj 2aEkFF04gs/+SnxlVIazVjrJe5qSwrQeFG3dn8Rm3mbcKdqs9ljGO0MHYsNTsuaJ0FPoNO fm36TnwoajBXyO71WZarSqwjfXP5EOE= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-115-XWfg6IiLPaCG-jqzV_wzXQ-1; Thu, 05 Feb 2026 16:27:13 -0500 X-MC-Unique: XWfg6IiLPaCG-jqzV_wzXQ-1 X-Mimecast-MFC-AGG-ID: XWfg6IiLPaCG-jqzV_wzXQ_1770326833 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-503915b0a88so1538211cf.1 for ; Thu, 05 Feb 2026 13:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770326833; x=1770931633; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=rGchRpNtHpsURPrx/vVHrgmCPFSkjjSjv6Ar1R+yRYU=; b=t5/opbZR5FktdI9ygVqVAfgHLxwRfyRQ9NuHv98/ycoStCB9zUWEHlHfMBMVSsDxgF VXAi5Kq3m8BctAP0SZvwowe+kEeWZ2Pq+ntDwPxquLqS8+eQU88WYEiY/iPU2VVA0/sl cA5ibjdHOaPqBcgQD4gzE3Ao7BwvmCLmyQkRFsZ14nyghgqJp+bxncP7inURSiBie1Hp C+UgLJE16ZEOUBNXt0ezMuuSquzZJNyDYl+pup6rYS1nmCFycmZ8J7pObGd8uFM7/x9+ zl8zo56ORyiXr668sVXC3/78MXRklSFalR2JU1VMaRuhJjf00azAFnBBBJvpVCvEmu8O aXAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770326833; x=1770931633; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rGchRpNtHpsURPrx/vVHrgmCPFSkjjSjv6Ar1R+yRYU=; b=ZgrwcTQwKqAOKqXd85YLbgQKpf6na5Y+K/0UQPI6y8umsdSF5oYEOsmxLeiPBxtqgO 7tZvTgm0S4VIW+RIFexlyfOMDsEbyelquDONHceFewmEB4gfDoFp70gsUXC9F5ipOwSQ XVy5kQv0PvRKGZSoVgFsk1YKxuGg3gRj5OUmSI2A7pNhcZUQC2A3u0Wccu/svomkEjm5 wuvofuC4RbjQCRm5rC6F4drqaUbUpA9Sefc4PgezYw5/7SbprPZj6sEOzP1FJPpteLvw eycnFLDdrOM9Oftw4uEhTpJpgsSTKVkYUQrA1mK94Ti4FqOV1jbhcSVxwQQMFWvZ0kni eIOQ== X-Forwarded-Encrypted: i=1; AJvYcCUBw5Z64bQMGd64TATvCFtvt62uFaR0GrJy78LN5cukIHz9G1d3axOH+KKFtydLuS46dgLsMTSh3O9g7ZA=@vger.kernel.org X-Gm-Message-State: AOJu0Yzkq/4Zueo3tmkigxhoTvN3HgkZErzThNt6Vj4Fp8VBqzBBrx0B oTOmHTcZ4vZ4nS85CHjRySuJEZlDPJZZzflus9q4dIrtTz91YQedBb1+suQQdVL1/dK26a0EltP kavM7Ca8odHHHLYnlA2XqjpFwenCLizDvgS6adXV9mkIj1mx646QGn0j4eu1iclG6rA== X-Gm-Gg: AZuq6aICkAC1qxi5XoV3pJDZyR8dtdmzY1TGS8vYkZBgjJgDqTmEyF/w2Vv+JlLyrGr /wd8Pg+WFHrZhl9FR6id42I9J/aGNg3m1YJKcmhVaXmLSsW11PvGnZ2rh9fcfri1cV5rQeC67Qm JC1C0j1MLDV21fJ+MSmc90o5cC4HgpgyOduz70FGi74nlFTn2ZOMghw/in++8Y0HsyQTfPLcvDw BPlXinth5zy8JJsdQi8hgKMj2EnpzjFYdKsFVfVmFYLPc3je8jT4OUi6QtbiPq5+7zVohfpZWyS 83MbioUYqr7o3/f9DzZuk5HVlkjnatuAJ4XEF2XZRjqpFNd3zbyZQW34S6yoxyaJMASLyBj5F+x nkWVEzpkGaw== X-Received: by 2002:ac8:598f:0:b0:4ee:1b0e:861a with SMTP id d75a77b69052e-506398477b3mr7896221cf.13.1770326832978; Thu, 05 Feb 2026 13:27:12 -0800 (PST) X-Received: by 2002:ac8:598f:0:b0:4ee:1b0e:861a with SMTP id d75a77b69052e-506398477b3mr7895841cf.13.1770326832454; Thu, 05 Feb 2026 13:27:12 -0800 (PST) Received: from localhost ([2607:f2c0:b010:9000:f569:ac10:227c:5156]) by smtp.gmail.com with UTF8SMTPSA id d75a77b69052e-506392902eesm3841121cf.21.2026.02.05.13.27.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Feb 2026 13:27:11 -0800 (PST) Date: Thu, 5 Feb 2026 16:27:10 -0500 From: Peter Colberg To: Jason Gunthorpe Cc: Danilo Krummrich , Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?B?QmrDtnJu?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Abdiel Janulgue , Daniel Almeida , Robin Murphy , Greg Kroah-Hartman , Dave Ertman , Ira Weiny , Leon Romanovsky , linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Alexandre Courbot , Alistair Popple , Joel Fernandes , John Hubbard , Zhi Wang Subject: Re: [PATCH 3/8] rust: pci: add {enable,disable}_sriov(), to control SR-IOV capability Message-ID: Mail-Followup-To: Jason Gunthorpe , Danilo Krummrich , Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?B?QmrDtnJu?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Abdiel Janulgue , Daniel Almeida , Robin Murphy , Greg Kroah-Hartman , Dave Ertman , Ira Weiny , Leon Romanovsky , linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Alexandre Courbot , Alistair Popple , Joel Fernandes , John Hubbard , Zhi Wang References: <20251119-rust-pci-sriov-v1-0-883a94599a97@redhat.com> <20251119-rust-pci-sriov-v1-3-883a94599a97@redhat.com> <20251121232833.GH233636@ziepe.ca> <20260106012236.GR125261@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260106012236.GR125261@ziepe.ca> Hi Jason, On Mon, Jan 05, 2026 at 09:22:36PM -0400, Jason Gunthorpe wrote: > On Tue, Dec 23, 2025 at 02:17:12PM -0500, Peter Colberg wrote: > > Further, enable_sriov() is prevented during remove() using a new > > flag inhibit_enable in the pci_sriov structure that is set before > > and cleared after the PF driver is unbound from the device. > > Doesn't this need something concurrent safe like a revocable? Thank you for the follow-up and apologies for the delay. I have now posted a v2 series that takes a different approach from what was described earlier, after discussing this further with Danilo. In the v2 patch [1], when the new PCI driver flag managed_sriov is set, which is always the case for Rust, SR-IOV is disabled twice if needed: once before the unbind() callback for a well-behaved driver, and a second time after unbind() for a broken (but nevertheless using safe APIs only) driver that re-enables SR-IOV during unbind(). Together with commit a995fe1a3aa7 ("rust: driver: drop device private data post unbind") which ensures that the device private data for the PF device is still alive until after the function pci_iov_remove() is called and forcibly re-disables SR_IOV if needed, this upholds the safety guarantee which pci::Device::physfn() depends on. As an alternative for preventing SR-IOV management during unbind(), I briefly considered adding a new context, e.g., CoreInternal => Core => CoreUnbind => Bound => Normal, where {enable,disable}_sriov() are implemented by Core but not CoreUnbind, but discarded that solution since it seems too specific to this case to warrant the complexity. Thanks, Peter [1] https://lore.kernel.org/rust-for-linux/20260205-rust-pci-sriov-v2-1-ef9400c7767b@redhat.com/ > > Jason >