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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 AE0B2C36008 for ; Wed, 26 Mar 2025 15:11:20 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6C14E10E6EF; Wed, 26 Mar 2025 15:11:16 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="Iu3V0huN"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id 832DB10E6EB; Wed, 26 Mar 2025 15:11:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1743001875; x=1774537875; h=from:date:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=T2vj5fs1lJoyIJWe3E0BaCVb+RTTxO7rAjHyemXklF4=; b=Iu3V0huN/+1HGOhRiDqpSnZEaooVY/iLAcLBrniDSfarMxsoNSRXOrxJ L7Vbzc6Y9xeDxj6qqPQRBvR0ITcsoal00X5wnu0ryyJRwubcmF9d3pmTb 8ESseFAwPVdv7jOyqNkY7FfFthQgPKj1LEMb7vzFMrxM73YE3WPWFsP2u beOLSKtMIDi9cVXytY2Axa/TxnlneyHvYfTSqvgq0XTud5NsSM06Et/2r qH3k/fxMU05pEHDbtIf/Lmd6PHp9bxjnC5YySt+Z92/Vb4S73w61p1pF0 G/94xdeg9j5lTEtbsMmthNYBQ1TV2dDURa58qF/JQPQGQsLPcfVSiolod g==; X-CSE-ConnectionGUID: DQ86r5/CQay63zE8FL4CZA== X-CSE-MsgGUID: xywCGREeTwSp3AGxHLuxhQ== X-IronPort-AV: E=McAfee;i="6700,10204,11385"; a="47950128" X-IronPort-AV: E=Sophos;i="6.14,278,1736841600"; d="scan'208";a="47950128" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2025 08:11:14 -0700 X-CSE-ConnectionGUID: xuZCinpVSzu60sPZ4LJ70g== X-CSE-MsgGUID: ZI+qmaGRThuotURKYdK1wA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,278,1736841600"; d="scan'208";a="124817289" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.245.5]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2025 08:11:08 -0700 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Date: Wed, 26 Mar 2025 17:11:04 +0200 (EET) To: =?ISO-8859-2?Q?Micha=B3_Winiarski?= cc: linux-pci@vger.kernel.org, intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, LKML , Bjorn Helgaas , =?ISO-8859-15?Q?Christian_K=F6nig?= , =?ISO-8859-2?Q?Krzysztof_Wilczy=F1ski?= , Rodrigo Vivi , Michal Wajdeczko , Lucas De Marchi , =?ISO-8859-15?Q?Thomas_Hellstr=F6m?= , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Matt Roper Subject: Re: [PATCH v6 4/6] PCI/IOV: Check that VF BAR fits within the reservation In-Reply-To: <20250320110854.3866284-5-michal.winiarski@intel.com> Message-ID: <4959d675-edd8-a296-661c-6a7bd22fbc0d@linux.intel.com> References: <20250320110854.3866284-1-michal.winiarski@intel.com> <20250320110854.3866284-5-michal.winiarski@intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-1797840117-1743001864=:942" X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1797840117-1743001864=:942 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 20 Mar 2025, Micha=C5=82 Winiarski wrote: > When the resource representing VF MMIO BAR reservation is created, its > size is always large enough to accommodate the BAR of all SR-IOV Virtual > Functions that can potentially be created (total VFs). If for whatever > reason it's not possible to accommodate all VFs - the resource is not > assigned and no VFs can be created. >=20 > The following patch will allow VF BAR size to be modified by drivers at "The following patch" sounds to be like you're referring to patch that=20 follows this description, ie., the patch below. "An upcoming change" is=20 alternative that doesn't suffer from the same problem. > a later point in time, which means that the check for resource > assignment is no longer sufficient. >=20 > Add an additional check that verifies that VF BAR for all enabled VFs > fits within the underlying reservation resource. So this does not solve the case where the initial size was too large to=20 fix and such VF BARs remain unassigned, right? > Signed-off-by: Micha=C5=82 Winiarski > --- > drivers/pci/iov.c | 5 +++++ > 1 file changed, 5 insertions(+) >=20 > diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c > index cbf335725d4fb..861273ad9a580 100644 > --- a/drivers/pci/iov.c > +++ b/drivers/pci/iov.c > @@ -646,8 +646,13 @@ static int sriov_enable(struct pci_dev *dev, int nr_= virtfn) > =20 > =09nres =3D 0; > =09for (i =3D 0; i < PCI_SRIOV_NUM_BARS; i++) { > +=09=09resource_size_t vf_bar_sz =3D > +=09=09=09pci_iov_resource_size(dev, > +=09=09=09=09=09 pci_resource_num_from_vf_bar(i)); Please add int idx =3D pci_resource_num_from_vf_bar(i); > =09=09bars |=3D (1 << pci_resource_num_from_vf_bar(i)); > =09=09res =3D &dev->resource[pci_resource_num_from_vf_bar(i)]; > +=09=09if (vf_bar_sz * nr_virtfn > resource_size(res)) > +=09=09=09continue; Not directly related to this patch, I suspect this could actually try to=20 assign an unassigned resource by doing something like this (perhaps in own= =20 patch, it doesn't even need to be part of this series but can be sent=20 later if you find the suggestion useful): =09=09/* Retry assignment if the initial size didn't fit */ =09=09if (!res->parent && pci_assign_resource(res, idx)) =09=09=09continue; Although I suspect reset_resource() might have been called for the=20 resource and IIRC it breaks the resource somehow but it could have been=20 that IOV resources can be resummoned from that state though thanks to=20 their size not being stored into the resource itself but comes from iov=20 structures. > =09=09if (res->parent) > =09=09=09nres++; > =09} >=20 --=20 i. --8323328-1797840117-1743001864=:942--