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: Thu, 1 Apr 2021 13:43:36 +0000 From: "Liu, Yi L" <yi.l.liu@...el.com> To: Jason Gunthorpe <jgg@...dia.com> CC: "Tian, Kevin" <kevin.tian@...el.com>, Jacob Pan <jacob.jun.pan@...ux.intel.com>, Jean-Philippe Brucker <jean-philippe@...aro.org>, LKML <linux-kernel@...r.kernel.org>, Joerg Roedel <joro@...tes.org>, Lu Baolu <baolu.lu@...ux.intel.com>, David Woodhouse <dwmw2@...radead.org>, "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>, "cgroups@...r.kernel.org" <cgroups@...r.kernel.org>, Tejun Heo <tj@...nel.org>, Li Zefan <lizefan@...wei.com>, Johannes Weiner <hannes@...xchg.org>, "Jean-Philippe Brucker" <jean-philippe@...aro.com>, Alex Williamson <alex.williamson@...hat.com>, Eric Auger <eric.auger@...hat.com>, "Jonathan Corbet" <corbet@....net>, "Raj, Ashok" <ashok.raj@...el.com>, "Wu, Hao" <hao.wu@...el.com>, "Jiang, Dave" <dave.jiang@...el.com> Subject: RE: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs > From: Jason Gunthorpe <jgg@...dia.com> > Sent: Thursday, April 1, 2021 9:16 PM > > On Thu, Apr 01, 2021 at 01:10:48PM +0000, Liu, Yi L wrote: > > > From: Jason Gunthorpe <jgg@...dia.com> > > > Sent: Thursday, April 1, 2021 7:47 PM > > [...] > > > I'm worried Intel views the only use of PASID in a guest is with > > > ENQCMD, but that is not consistent with the industry. We need to see > > > normal nested PASID support with assigned PCI VFs. > > > > I'm not quire flow here. Intel also allows PASID usage in guest without > > ENQCMD. e.g. Passthru a PF to guest, and use PASID on it without > ENQCMD. > > Then you need all the parts, the hypervisor calls from the vIOMMU, and > you can't really use a vPASID. This is a diagram shows the vSVA setup. .-------------. .---------------------------. | vIOMMU | | Guest process CR3, FL only| | | '---------------------------' .----------------/ | PASID Entry |--- PASID cache flush - '-------------' | | | V | | CR3 in GPA '-------------' Guest ------| Shadow |--------------------------|-------- v v v Host .-------------. .----------------------. | pIOMMU | | Bind FL for GVA-GPA | | | '----------------------' .----------------/ | | PASID Entry | V (Nested xlate) '----------------\.------------------------------. | | |SL for GPA-HPA, default domain| | | '------------------------------' '-------------' Where: - FL = First level/stage one page tables - SL = Second level/stage two page tables https://lore.kernel.org/linux-iommu/20210302203545.436623-1-yi.l.liu@intel.com/ > > I'm not sure how Intel intends to resolve all of this. > > > > > - this per-ioasid SVA operations is not aligned with the native SVA > usage > > > > model. Native SVA bind is per-device. > > > > > > Seems like that is an error in native SVA. > > > > > > SVA is a particular mode of the PASID's memory mapping table, it has > > > nothing to do with a device. > > > > I think it still has relationship with device. This is determined by the > > DMA remapping hierarchy in hardware. e.g. Intel VT-d, the DMA isolation > is > > enforced first in device granularity and then PASID granularity. SVA makes > > usage of both PASID and device granularity isolation. > > When the device driver authorizes a PASID the VT-d stuff should setup > the isolation parameters for the give pci_device and PASID. yes, both device and PASID is needed to setup VT-d stuff. > Do not leak implementation details like this as uAPI. Authorization > and memory map are distinct ideas with distinct interfaces. Do not mix > them. got you. Let's focus on the uAPI things here and leave implementation details in RFC patches. Thanks, Yi Liu > Jason
Powered by blists - more mailing lists