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:08:47 +0000 From: Yuval Mintz <Yuval.Mintz@...gic.com> To: Eli Cohen <eli@....mellanox.co.il> CC: "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 >>>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. If you're not planning on adding a logic to set this, why do we need to add a parameter to pci_enable_sriov() - given that all callers use the exact same logic? [And I don't really think we'd want different devices to behave differently by default; That would be confusing for users.] >>>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. What I meant is that device is unbinded after initial probe, But in the scenario I've stated above, the VF will become binded once it's returned to the hypervisor. Now, I understand that what you're trying to achieve - but my question is whether what you're REALLY trying to achieve is the ability to have VFs which would only be binded to VMs and never to hypervisor [by default]?-- 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