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 DD443C3600B for ; Wed, 26 Mar 2025 14:52:34 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 993EC10E6E6; Wed, 26 Mar 2025 14:52:34 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="YvEEf/hk"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) by gabe.freedesktop.org (Postfix) with ESMTPS id E93FC10E6DF; Wed, 26 Mar 2025 14:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1743000753; x=1774536753; h=from:date:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=kMWBFtvP0kEE/trvo0qGsOmq8xhchyKSw1YVss2QtLk=; b=YvEEf/hk7OPwYSPoeBL39D0ZFQUfkn00k8f4PW1v4XQo71kzQiXhNiGh PiygvvF9hmde1Gwe67blZtf5vwNwmsZY12hDLhduHgWSY2/VNM38JxQGA CLXMVQvwV/y69ClRzw5cr6Ilk8jjojeplyNKMa4Kuz09+9oh0gET8TDZc ywW1yqHqty2NkSEbqXcUoS04lurU+Mc55Py1+9RsMTZOc1YygFfSFwgpe dLjQzfQdahxdmyCo89qMQxgkzJj6z5CvvliOFZBLD0iZxtKdWf0VL3w/C WJ/xI4+vX6Ch6Z3rLyosJ1tP6mBw50gq9OwIpmG7KFWW//EKZQnSK06+s A==; X-CSE-ConnectionGUID: o5lN9rFnSEaIJHTQxRySwg== X-CSE-MsgGUID: 1Zg+b6rZSiq2vl0o5Bg5zw== X-IronPort-AV: E=McAfee;i="6700,10204,11385"; a="44455140" X-IronPort-AV: E=Sophos;i="6.14,278,1736841600"; d="scan'208";a="44455140" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2025 07:52:32 -0700 X-CSE-ConnectionGUID: /xCYhiUWTT+6GflWnlz/Pw== X-CSE-MsgGUID: I5/SSNZdRc6H47G3BpwTZg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,278,1736841600"; d="scan'208";a="124596406" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.245.5]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2025 07:52:26 -0700 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Date: Wed, 26 Mar 2025 16:52:22 +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 1/6] PCI/IOV: Restore VF resizable BAR state after reset In-Reply-To: Message-ID: References: <20250320110854.3866284-1-michal.winiarski@intel.com> <20250320110854.3866284-2-michal.winiarski@intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-657385912-1743000742=: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-657385912-1743000742=:942 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 26 Mar 2025, Ilpo J=C3=A4rvinen wrote: > On Thu, 20 Mar 2025, Micha=C5=82 Winiarski wrote: >=20 > > Similar to regular resizable BAR, VF BAR can also be resized, e.g. by > > the system firmware or the PCI subsystem itself. > >=20 > > Add the capability ID and restore it as a part of IOV state. > > > > See PCIe r4.0, sec 9.3.7.4. >=20 > Usually it's best o refer to latest gen doc, the section number seems to= =20 > be the same also in r6.2. Actually, it isn't. r6.2 9.3.7 does specify capability IDs so I though you= =20 be refering to that section, but there's no 9.3.7.4 section at all. -- i. > This didn't refer to spec section that specified VF Rebar ext capability > (7.8.7) though. I think it should and it would also be good to mention th= e=20 > capability layout is the same as with the rebar cap. >=20 > > Signed-off-by: Micha=C5=82 Winiarski > > Reviewed-by: Ilpo J=C3=A4rvinen > > Reviewed-by: Christian K=C3=B6nig > > --- > > drivers/pci/iov.c | 30 +++++++++++++++++++++++++++++- > > drivers/pci/pci.h | 1 + > > include/uapi/linux/pci_regs.h | 1 + > > 3 files changed, 31 insertions(+), 1 deletion(-) > >=20 > > diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c > > index 121540f57d4bf..bf95387993cd5 100644 > > --- a/drivers/pci/iov.c > > +++ b/drivers/pci/iov.c > > @@ -7,6 +7,7 @@ > > * Copyright (C) 2009 Intel Corporation, Yu Zhao > > */ > > =20 > > +#include > > #include > > #include > > #include > > @@ -830,6 +831,7 @@ static int sriov_init(struct pci_dev *dev, int pos) > > =09pci_read_config_byte(dev, pos + PCI_SRIOV_FUNC_LINK, &iov->link); > > =09if (pci_pcie_type(dev) =3D=3D PCI_EXP_TYPE_RC_END) > > =09=09iov->link =3D PCI_DEVFN(PCI_SLOT(dev->devfn), iov->link); > > +=09iov->vf_rebar_cap =3D pci_find_ext_capability(dev, PCI_EXT_CAP_ID_V= F_REBAR); > > =20 > > =09if (pdev) > > =09=09iov->dev =3D pci_dev_get(pdev); > > @@ -868,6 +870,30 @@ static void sriov_release(struct pci_dev *dev) > > =09dev->sriov =3D NULL; > > } > > =20 > > +static void sriov_restore_vf_rebar_state(struct pci_dev *dev) > > +{ > > +=09unsigned int pos, nbars, i; > > +=09u32 ctrl; > > + > > +=09pos =3D dev->sriov->vf_rebar_cap; > > +=09if (!pos) > > +=09=09return; > > + > > +=09pci_read_config_dword(dev, pos + PCI_REBAR_CTRL, &ctrl); > > +=09nbars =3D FIELD_GET(PCI_REBAR_CTRL_NBAR_MASK, ctrl); > > + > > +=09for (i =3D 0; i < nbars; i++, pos +=3D 8) { > > +=09=09int bar_idx, size; > > + > > +=09=09pci_read_config_dword(dev, pos + PCI_REBAR_CTRL, &ctrl); > > +=09=09bar_idx =3D FIELD_GET(PCI_REBAR_CTRL_BAR_IDX, ctrl); > > +=09=09size =3D pci_rebar_bytes_to_size(dev->sriov->barsz[bar_idx]); > > +=09=09ctrl &=3D ~PCI_REBAR_CTRL_BAR_SIZE; > > +=09=09ctrl |=3D FIELD_PREP(PCI_REBAR_CTRL_BAR_SIZE, size); > > +=09=09pci_write_config_dword(dev, pos + PCI_REBAR_CTRL, ctrl); >=20 > I started to wonder if we'd still want to have the VF Rebar ones in=20 > uapi/linux/pci_regs.h (despite the same capability layout): >=20 > /* > * PCI Resizable BAR and PCI VF Resizable BAR extended capabilities have= =20 > * the same layout of fields. > */ > #define PCI_VF_REBAR_CTRL=09=09PCI_REBAR_CTRL > #define PCI_VF_REBAR_CTRL_BAR_IDX=09PCI_REBAR_CTRL_BAR_IDX > etc. >=20 > as then it would be possible grep to pick up only the relevant lines. >=20 > I'd not duplicate _SHIFT defines though. FIELD_PREP/GET() in general does= =20 > not need _SHIFT defines at all and they are just duplicated information. >=20 > > +=09} > > +} > > + > > static void sriov_restore_state(struct pci_dev *dev) > > { > > =09int i; > > @@ -1027,8 +1053,10 @@ resource_size_t pci_sriov_resource_alignment(str= uct pci_dev *dev, int resno) > > */ > > void pci_restore_iov_state(struct pci_dev *dev) > > { > > -=09if (dev->is_physfn) > > +=09if (dev->is_physfn) { > > +=09=09sriov_restore_vf_rebar_state(dev); > > =09=09sriov_restore_state(dev); > > +=09} > > } > > =20 > > /** > > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h > > index b81e99cd4b62a..adc54bb2c8b34 100644 > > --- a/drivers/pci/pci.h > > +++ b/drivers/pci/pci.h > > @@ -482,6 +482,7 @@ struct pci_sriov { > > =09u16=09=09subsystem_vendor; /* VF subsystem vendor */ > > =09u16=09=09subsystem_device; /* VF subsystem device */ > > =09resource_size_t=09barsz[PCI_SRIOV_NUM_BARS];=09/* VF BAR size */ > > +=09u16=09=09vf_rebar_cap;=09/* VF Resizable BAR capability offset */ > > =09bool=09=09drivers_autoprobe; /* Auto probing of VFs by driver */ > > }; > > =20 > > diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_reg= s.h > > index ba326710f9c8b..bb2a334e50386 100644 > > --- a/include/uapi/linux/pci_regs.h > > +++ b/include/uapi/linux/pci_regs.h > > @@ -745,6 +745,7 @@ > > #define PCI_EXT_CAP_ID_L1SS=090x1E=09/* L1 PM Substates */ > > #define PCI_EXT_CAP_ID_PTM=090x1F=09/* Precision Time Measurement */ > > #define PCI_EXT_CAP_ID_DVSEC=090x23=09/* Designated Vendor-Specific */ > > +#define PCI_EXT_CAP_ID_VF_REBAR 0x24=09/* VF Resizable BAR */ > > #define PCI_EXT_CAP_ID_DLF=090x25=09/* Data Link Feature */ > > #define PCI_EXT_CAP_ID_PL_16GT=090x26=09/* Physical Layer 16.0 GT/s */ > > #define PCI_EXT_CAP_ID_NPEM=090x29=09/* Native PCIe Enclosure Manageme= nt */ >=20 > Reviewed-by: Ilpo J=C3=A4rvinen >=20 >=20 --8323328-657385912-1743000742=:942--