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: Sun, 7 Dec 2014 20:42:43 +0200 From: Eli Cohen <eli@....mellanox.co.il> To: Yuval Mintz <Yuval.Mintz@...gic.com> Cc: Eli Cohen <eli@....mellanox.co.il>, "bhelgaas@...gle.com" <bhelgaas@...gle.com>, David Miller <davem@...emloft.net>, linux-pci <linux-pci@...r.kernel.org>, netdev <netdev@...r.kernel.org>, "ogerlitz@...lanox.com" <ogerlitz@...lanox.com>, "yevgenyp@...lanox.com" <yevgenyp@...lanox.com>, Donald Dutile <ddutile@...hat.com> Subject: Re: [PATCH RFC] pci: Control whether VFs are probed on pci_enable_sriov On Sun, Dec 07, 2014 at 05:05:06PM +0000, Yuval Mintz wrote: > > >This can save host side resource usage by VF instances which would be > >eventually probed to VMs. > > >Use a parameter to pci_enable_sriov to control that policy, and modify > >all current callers such that they retain the same functionality. > > What's the end-game here? How eventually would this be controlled? You can probe any VF at the hypervisor through sysfs files (bind/unbind). You can also pass them through to a VM. Nothing changes. > > >Use a one shot flag on struct pci_device which is cleared after the > >first probe is ignored so subsequent attempts go through. > > Does a one-shot flag suffice? E.g., consider assigning a VF to VM and > than shutting down the VM. Assuming this feature is disabled, > the VF didn't appear on the hypervisor prior to the assignment but > will appear after its shutdown. Sorry, I don't follow you here. Please clarify. To be clear, the functionality proposed here is really one shot. It just prevents calling probe once; besides that nothing changes. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists