lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 11 Jul 2022 11:48:06 -0700 From: Jakub Kicinski <kuba@...nel.org> To: Martin Habets <habetsm.xilinx@...il.com> Cc: Bjorn Helgaas <helgaas@...nel.org>, davem@...emloft.net, pabeni@...hat.com, edumazet@...gle.com, netdev@...r.kernel.org, ecree.xilinx@...il.com, linux-pci@...r.kernel.org, virtualization@...ts.linux-foundation.org Subject: Re: [PATCH net-next v2 0/2] sfc: Add EF100 BAR config support On Mon, 11 Jul 2022 14:38:54 +0100 Martin Habets wrote: > > Normally drivers rely on the PCI Vendor and Device ID to learn the > > number of BARs and their layouts. I guess this series implies that > > doesn't work on this device? And the user needs to manually specify > > what kind of device this is? > > When a new PCI device is added (like a VF) it always starts of with > the register layout for an EF100 network device. This is hardcoded, > i.e. it cannot be customised. > The layout can be changed after bootup, and only after the sfc driver has > bound to the device. > The PCI Vendor and Device ID do not change when the layout is changed. > > For vDPA specifically we return the Xilinx PCI Vendor and our device ID > to the vDPA framework via struct vdpa_config_opts. So it's switching between ethernet and vdpa? Isn't there a general problem for configuring vdpa capabilities (net vs storage etc) and shouldn't we seek to solve your BAR format switch in a similar fashion rather than adding PCI device attrs, which I believe is not done for anything vDPA-related? > > I'm confused about how this is supposed to work. What if the driver > > is built-in and claims a device before the user can specify the > > register layout? > > The bar_config file will only exist once the sfc driver has bound to > the device. So in fact we count on that driver getting loaded. > When a new value is written to bar_config it is the sfc driver that > instructs the NIC to change the register layout. When you say "driver bound" you mean the VF driver, right? > > What if the user specifies the wrong layout and the > > driver writes to the wrong registers? > > We have specific hardware and driver requirements for this sort of > situation. For example, the register layouts must have some common > registers (to ensure some compatibility). > A layout that is too different will require a separate device ID. > A driver that writes to the wrong register is a bug. > > Maybe the name "bar_config" is causing most of the confusion here. > Internally we also talk about "function profiles" or "personalities", > but we thought such a name would be too vague.
Powered by blists - more mailing lists