From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13D75494833 for ; Thu, 6 Aug 2026 19:47:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786045665; cv=none; b=RjOpkH/gPLtqiht6cIWKi5BvQfGnjQYWfFCclDI5ew2jWwA3YD3SIE11t01wNhWKffib+8MUmNrnJhpfHe4TAFoPcm90wn0ThGgkIwRNlAtVECp9rCqsjygznPB8Px90nbCDTLz+lB1OF8k5vop03xluSsy39RRzZ29jCBeVSQM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786045665; c=relaxed/simple; bh=a9GePtSgIas837wyg13CpFZrQH6LYH/QdAFKmNODC/s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=a5y6f0ey+Hj6T1psPdYaP9y78KHM2V0UkUWFH3Twi+lVzI4getTKAxqgZbFoZvyDEqIOP+wcpCx/sWyi5U7Rc3aGOhTBqBxwECwTG9FcKkeFKwkosbknYkzUGJzM9ssHK1Riy7J87d0AAFEiJm2M/09s1grkakUONBhhaH1gRls= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=dc/0PQQx; arc=none smtp.client-ip=209.85.222.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="dc/0PQQx" Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-92e55b62640so141344285a.0 for ; Thu, 06 Aug 2026 12:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1786045661; x=1786650461; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=i4zn10CTEB0hgDoZsByJF29MpPwaAKvjrTCMgqoaY6Y=; b=dc/0PQQxJm5jidQF/9G4/cMRNCKdH/Qw5lYByTQju24kLACqVICtk+qqxOiSAswMOz g0NP7REBbpbSyMCAQdMGBbxaPQwP5cUksdNuRawOpVCCU/RGAbrCobfJDdUD7q+GGnID y/4YPrKqfG5K0EyztVZqgIlq8tlg6x4SJTibeOTktQyIIdlQi3ekOD9dZb9I5CTErs19 TolAodeGPGvyqJ3hu1M2aOTYWWXT1Z9omDbaW9eYRKvO7Cc3CvF3tKxIYvVE36VXeAha 7FBuNLaph5PN3WZXUHprMM/BFm8QEqrsG+vIy3Vl4nzlfH/SFBH+iubKHPH1BOnuyEH1 RX8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786045661; x=1786650461; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=i4zn10CTEB0hgDoZsByJF29MpPwaAKvjrTCMgqoaY6Y=; b=AAxiqtyugtHokxhzvUjmvMaTOwNn0h4kitAu3T4BNfNnWBUseBN6aQUWCBtyaxs+oF Bho3TEvpy9MTp9CIYwVaKw/VRmntCWIPXqrwCpeslXgJ55fWqsbAEi75QopzbvtdgCV7 j1i7jx8LUNvMUunssBVaecydQF4I3K7XGDxnzGmdWVul2fVzqtmHajlYC+FOjtJ9bYLD wPN4U0anRYh4NYMZUGJPkBx6aAK4wSiQvIogJ2ETSv+WMxbpZTTnMpQ9MnAGLTVQ6nXB 4nV9YeAVHrMD5SnCv7trZ9EWaExK1xQyWgNpuEPLfJz/AjMsYgN3iWei98kamsmHdY/K 2QOQ== X-Forwarded-Encrypted: i=1; AHgh+RoLkPnL8a/Ju1CmXZ4x2E4ZMYcnsM0G1BFbqKtWXeYxgZbPF5VYlAzy8/8Hsy2HcM2KoutwDo2qCUUVV3o=@vger.kernel.org X-Gm-Message-State: AOJu0Yw72dlDlxJGaG7pzjoK6gjFUaNmbFanS6BEUzBoltNiUrK7lE0N JiGAWFWfJIQAqfTqGeT96tD15ffWqMF/NHgACpBsXgt4gl99/9Z9l5Zh0EkBJQHZrypct4t5Cvd td+Bj X-Gm-Gg: AR+sD11utgLOeLs+pWONELy3GdL/Fn24BP/mS6tF8y1BNsFyGsCr/bH0LuWTnxjpr5k d7zeTJ4HokeOoGsm63wlMQ4ki9VqmU8KdiHR9uLlF067uxx05LWfSgee6OXij8lWvZNpm8mVUip 6fkJm6iBIxndV5YtLBsJfKiZuOXfjKp9jvGtlduCwT6Zn0KzMkG2YIJr6jBPkbjPOs7GAi959Yz D0YfA87HC/4rUG7jiB/0ya7QxIT4HKFdBKqagT9MLxk9RU7hI5NqrV6ygCdWcRMp366wSB0oykD ovjs94hLgZ8LaAPh/aq9j9a3/VdAUj0c/99yaZBTivBfdvTIH89lpC2GMHaCChgzkjlXXnFZt3U X6NdL8VcEcAiH/qknkGjNsvpbt/2Ao7WytGQb/1y0WXuTiBZkCqZsoiBNzCL87hln3/KgXDlFSz OJ+5kg3ORTFSq0c6I1TF7Ck2h3+xwWIG8idnCB2Q== X-Received: by 2002:a05:620a:a915:b0:92e:5f90:c0de with SMTP id af79cd13be357-936490c7c2amr1707105185a.22.1786045661363; Thu, 06 Aug 2026 12:47:41 -0700 (PDT) Received: from ziepe.ca ([142.166.156.215]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93657e1afefsm333826785a.30.2026.08.06.12.47.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 12:47:40 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1ws443-00000000hmj-3UT1; Thu, 06 Aug 2026 16:47:39 -0300 Date: Thu, 6 Aug 2026 16:47:39 -0300 From: Jason Gunthorpe To: Alex Williamson Cc: Samiullah Khawaja , bhelgaas@google.com, Kevin Tian , Leon Romanovsky , dmatlack@google.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/1] vfio/pci: Disable sriov on PF device close Message-ID: <20260806194739.GH28508@ziepe.ca> References: <20260805003355.728299-1-skhawaja@google.com> <20260805003355.728299-2-skhawaja@google.com> <20260805090323.01b1a36f@shazbot.org> 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: <20260805090323.01b1a36f@shazbot.org> On Wed, Aug 05, 2026 at 09:03:23AM -0600, Alex Williamson wrote: > On Wed, 5 Aug 2026 00:33:55 +0000 > Samiullah Khawaja wrote: > > > When userspace closes a VFIO device file descriptor, the vfio driver > > performs a hardware reset on the PCIe device to ensure it is returned to > > a clean state. However, if the closed device is an SR-IOV Physical > > Function (PF), it may have instantiated Virtual Functions (VFs) that are > > actively bound to host kernel drivers (or other vfio instances). > > Wait, what? We actively try to prevent VFs from a vfio-pci owned PF > from being bound to host drivers other than vfio-pci. You need to > overwrite the imposed driver_override to make this happen and you're in > a very precarious security model to have the VF owned by a trusted > in-kernel driver while the PF is owned by userspace. Maybe, it really depends on the device. I can easially see someone using a device where this would be safe. mlx5 for instance is pretty OK. So I don't really mind someone doing this, we should block it and warn it and so on, but like noiommu and the other vfio insecure modes, why not give an opt in? > It's possible there are gaps that closing the PF can interrupt the VFs > and we need to defer a reset until the VFs are closed, Oh definately, when running in a SRIOV mode it is really problematic for the PF to reset while there are any active VFs. The PF controls a number of shared items (MMIO, ATS, etc) and when it blips everyone is at risk of unexpected fairly catastrophic system crashing errors related to the shared items going away. So resetting the PF device unconditionally when vfio closes is definately wrong in principal. I can see it maybe working for simple systems, especially ones that don't MCE.. I don't think we can skip the PF reset on close because of dev_set reasons and leave a rouge device for the next user, so the thing looks somewhat troubled? Adding the sriov disable here at least makes it defensibly safe, that we do still clear the PF on close, and we don't take risks that the active VFs will crash the system during the FLR blip. Though I understand it was not the original intention, I feel we have ended up in a strange place with the SRIOV PF feature .. Jason