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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 11 Nov 2020 02:17:48 +0000 From: "Tian, Kevin" <kevin.tian@...el.com> To: Jason Gunthorpe <jgg@...dia.com>, "Raj, Ashok" <ashok.raj@...el.com> CC: Thomas Gleixner <tglx@...utronix.de>, "Williams, Dan J" <dan.j.williams@...el.com>, "Jiang, Dave" <dave.jiang@...el.com>, "Bjorn Helgaas" <helgaas@...nel.org>, "vkoul@...nel.org" <vkoul@...nel.org>, "Dey, Megha" <megha.dey@...el.com>, "maz@...nel.org" <maz@...nel.org>, "bhelgaas@...gle.com" <bhelgaas@...gle.com>, "alex.williamson@...hat.com" <alex.williamson@...hat.com>, "Pan, Jacob jun" <jacob.jun.pan@...el.com>, "Liu, Yi L" <yi.l.liu@...el.com>, "Lu, Baolu" <baolu.lu@...el.com>, "Kumar, Sanjay K" <sanjay.k.kumar@...el.com>, "Luck, Tony" <tony.luck@...el.com>, "kwankhede@...dia.com" <kwankhede@...dia.com>, "eric.auger@...hat.com" <eric.auger@...hat.com>, "parav@...lanox.com" <parav@...lanox.com>, "rafael@...nel.org" <rafael@...nel.org>, "netanelg@...lanox.com" <netanelg@...lanox.com>, "shahafs@...lanox.com" <shahafs@...lanox.com>, "yan.y.zhao@...ux.intel.com" <yan.y.zhao@...ux.intel.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>, "Ortiz, Samuel" <samuel.ortiz@...el.com>, "Hossain, Mona" <mona.hossain@...el.com>, "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org> Subject: RE: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection > From: Jason Gunthorpe <jgg@...dia.com> > Sent: Tuesday, November 10, 2020 10:24 PM > > On Tue, Nov 10, 2020 at 06:13:23AM -0800, Raj, Ashok wrote: > > > This isn't just for idxd, as I mentioned earlier, there are vendors other > > than Intel already working on this. In all cases the need for guest direct > > manipulation of interrupt store hasn't come up. From the discussion, it > > seems like there are devices today or in future that will require direct > > manipulation of interrupt store in the guest. This needs additional work > > in both the device hardware providing the right plumbing and OS work to > > comprehend those. > > We'd want to see SRIOV's assigned to guests to be able to use > IMS. This allows a SRIOV instance in a guest to spawn SIOV's which is > useful. Does your VF support both MSI/IMS or IMS only? If it is the former can't we adopt a phased approach or parallel effort between forcing guest to use MSI and adding hypercall to enable IMS on VF? Finding a way to disable IMS is anyway required per earlier discussion when hypercall is not available, and it could still provide a functional though suboptimal model for such VFs. > > SIOV's assigned to guests could use IMS, but the use cases we see in > the short term can be handled by using SRIOV instead. > > I would expect in general for SIOV to use MSI-X emulation to expose > interrupts - it would be really weird for a SIOV emulator to do > something else and we should probably discourage that. > I agree with this point. This leaves hardware gaps in IOMMU and root complex less an immediate blocker and to be addressed in the long term. Thanks Kevin
Powered by blists - more mailing lists