> From: Robin Murphy
> Sent: Tuesday, March 15, 2022 6:49 PM
>
> On 2022-03-14 19:44, Matthew Rosato wrote:
> > s390x will introduce an additional domain type that is used for
> > managing IOMMU owned by KVM. Define the type here and add an
> > interface for allocating a specified type vs the
Hi Jason,
On Wed, 16 Mar 2022 19:15:50 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 16, 2022 at 01:50:04PM -0700, Jacob Pan wrote:
>
> > I guess a list of (device, pasid) tuples as you suggested could work
> > but it will have duplicated device entries since each device could have
> > multiple
On Wed, Mar 16, 2022 at 10:23:26PM +, Luck, Tony wrote:
> Kernel users (ring0) can supply any PASID when they use
> the ENQCMDS instruction. Is that what you mean when you
> say "real applications"?
I'm not talking about ENQCMD at all
I'm saying I don't see much utility to have two PASIDs
> I would expect real applications will try to use the same PASID for
> the same IOVA map to optimize IOTLB caching.
On Intel a ring3 application only gets to use one PASID.
The ENQCMD instruction pick up the PASID for the process
from the IA32_PASID MSR (set by OS when first access,
and on
On Wed, Mar 16, 2022 at 01:50:04PM -0700, Jacob Pan wrote:
> I guess a list of (device, pasid) tuples as you suggested could work but it
> will have duplicated device entries since each device could have multiple
> PASIDs. right?
Is assigning the same iommu_domain to multiple PASIDs of the same
Hi Kevin,
On Wed, 16 Mar 2022 07:41:34 +, "Tian, Kevin"
wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 15, 2022 10:33 PM
> >
> > On Mon, Mar 14, 2022 at 10:07:07PM -0700, Jacob Pan wrote:
> > > + /*
> > > + * Each domain could have multiple devices attached with
> > > shared
Hi Kevin,
On Wed, 16 Mar 2022 07:39:09 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Tuesday, March 15, 2022 1:07 PM
> > +static int intel_iommu_attach_dev_pasid(struct iommu_domain *domain,
> > + struct device *dev, ioasid_t
> > pasid) +{
> > +
Hi Jason,
On Tue, 15 Mar 2022 20:04:57 -0300, Jason Gunthorpe wrote:
> On Tue, Mar 15, 2022 at 03:36:20PM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Tue, 15 Mar 2022 11:33:22 -0300, Jason Gunthorpe
> > wrote:
> > > On Mon, Mar 14, 2022 at 10:07:07PM -0700, Jacob Pan wrote:
> > > > +
[Public]
> -Original Message-
> From: Robin Murphy
> Sent: Wednesday, March 16, 2022 14:18
> To: Limonciello, Mario ; Mika Westerberg
>
> Cc: michael.ja...@intel.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; yehezkel...@gmail.com; iommu@lists.linux-
>
On 2022-03-16 18:34, Limonciello, Mario wrote:
[Public]
Can the USB4 CM make the device links in the DVSEC case perhaps too? I
would
think we want that anyway to control device suspend ordering.
If I had something discrete to try I'd dust off the DVSEC patch I wrote
before to
try it, but
[Public]
> > Can the USB4 CM make the device links in the DVSEC case perhaps too? I
> would
> > think we want that anyway to control device suspend ordering.
> >
> > If I had something discrete to try I'd dust off the DVSEC patch I wrote
> before to
> > try it, but alas all I have is integrated
On 2022-03-16 17:53, Limonciello, Mario wrote:
[Public]
There is a way to figure out the "tunneled" PCIe ports by looking at
certain properties and we do that already actually. The BIOS has the
following under these ports:
[Public]
> -Original Message-
> From: Limonciello, Mario
> Sent: Wednesday, March 16, 2022 12:54
> To: Robin Murphy ; Mika Westerberg
>
> Cc: michael.ja...@intel.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; yehezkel...@gmail.com; iommu@lists.linux-
> foundation.org;
[Public]
> >>>
> >>> There is a way to figure out the "tunneled" PCIe ports by looking at
> >>> certain properties and we do that already actually. The BIOS has the
> >>> following under these ports:
> >>>
> >>>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> >>>
On 2022-03-16 17:37, Mika Westerberg wrote:
Hi Mario,
On Wed, Mar 16, 2022 at 05:24:38PM +, Limonciello, Mario wrote:
[Public]
On Wed, Mar 16, 2022 at 02:49:09PM +, Robin Murphy wrote:
What we want is to make sure the Tunneled PCIe ports get the full
IOMMU
protection. In case of
Hi Mario,
On Wed, Mar 16, 2022 at 05:24:38PM +, Limonciello, Mario wrote:
> [Public]
>
> > On Wed, Mar 16, 2022 at 02:49:09PM +, Robin Murphy wrote:
> > > > What we want is to make sure the Tunneled PCIe ports get the full
> > IOMMU
> > > > protection. In case of the discrete above it is
[Public]
> On Wed, Mar 16, 2022 at 02:49:09PM +, Robin Murphy wrote:
> > > What we want is to make sure the Tunneled PCIe ports get the full
> IOMMU
> > > protection. In case of the discrete above it is also fine if all the
> > > devices behind the PCIe root port get the full IOMMU
Hi,
On Wed, Mar 16, 2022 at 02:49:09PM +, Robin Murphy wrote:
> > What we want is to make sure the Tunneled PCIe ports get the full IOMMU
> > protection. In case of the discrete above it is also fine if all the
> > devices behind the PCIe root port get the full IOMMU protection. Note in
> >
[Public]
> -Original Message-
> From: Mika Westerberg
> Sent: Wednesday, March 16, 2022 07:45
> To: Robin Murphy
> Cc: andreas.noe...@gmail.com; michael.ja...@intel.com;
> yehezkel...@gmail.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org;
On 2022-03-16 12:45, Mika Westerberg wrote:
Hi Robin,
On Wed, Mar 16, 2022 at 11:25:51AM +, Robin Murphy wrote:
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device
we care about. Furthermore, the
On Wed, Mar 16, 2022 at 08:41:27AM +, Tian, Kevin wrote:
> 1) When the kernel wants a more scalable way of using IDXD e.g. having
> multiple CPUs simultaneously submitting works in a lockless way to a
> shared work queue via a new instruction (ENQCMD) which carries
> PASID.
IMHO the
Hi Robin,
On Wed, Mar 16, 2022 at 11:25:51AM +, Robin Murphy wrote:
> Even if an IOMMU might be present for some PCI segment in the system,
> that doesn't necessarily mean it provides translation for the device
> we care about. Furthermore, the presence or not of one firmware flag
> doesn't
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device
we care about. Furthermore, the presence or not of one firmware flag
doesn't imply anything about the IOMMU driver's behaviour, which may
still depend on other
> From: Jacob Pan
> Sent: Wednesday, March 16, 2022 5:24 AM
>
> Hi Jason,
>
> On Tue, 15 Mar 2022 14:05:07 -0300, Jason Gunthorpe
> wrote:
>
> > On Tue, Mar 15, 2022 at 09:31:35AM -0700, Jacob Pan wrote:
> >
> > > > IMHO it is a device mis-design of IDXD to require all DMA be PASID
> > > >
Hi,
On Tue, Mar 15, 2022 at 01:36:11PM -0500, Limonciello, Mario wrote:
> + Christian Kellner (Bolt userspace maintainer)
>
> On 3/15/2022 13:07, Robin Murphy wrote:
> > On 2022-03-15 16:54, Limonciello, Mario via iommu wrote:
> > > [Public]
> > >
> > >
> > > > On Tue, Mar 15, 2022 at
> From: Jason Gunthorpe
> Sent: Tuesday, March 15, 2022 10:22 PM
>
> On Tue, Mar 15, 2022 at 11:16:41AM +, Robin Murphy wrote:
> > On 2022-03-15 05:07, Jacob Pan wrote:
> > > DMA mapping API is the de facto standard for in-kernel DMA. It operates
> > > on a per device/RID basis which is not
> From: Jacob Pan
> Sent: Tuesday, March 15, 2022 1:07 PM
>
> With the availability of a generic device-PASID-domain attachment API,
> there's no need to special case RID2PASID. Use the API to replace
> duplicated code.
>
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/intel/iommu.c | 18
On 2022/3/12 1:55, John Garry wrote:
>> +
>> +static int hisi_ptt_alloc_trace_buf(struct hisi_ptt *hisi_ptt)
>
> no caller
>
>> +{
>> + struct hisi_ptt_trace_ctrl *ctrl = _ptt->trace_ctrl;
>> + struct device *dev = _ptt->pdev->dev;
>> + int i;
>> +
>> + hisi_ptt->trace_ctrl.buf_index
> From: Jason Gunthorpe
> Sent: Tuesday, March 15, 2022 10:33 PM
>
> On Mon, Mar 14, 2022 at 10:07:07PM -0700, Jacob Pan wrote:
> > + /*
> > +* Each domain could have multiple devices attached with shared or
> per
> > +* device PASIDs. At the domain level, we keep track of unique
> From: Jacob Pan
> Sent: Tuesday, March 15, 2022 1:07 PM
> +static int intel_iommu_attach_dev_pasid(struct iommu_domain *domain,
> + struct device *dev, ioasid_t pasid)
> +{
> + struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> + struct
On 2022/3/12 1:27, John Garry wrote:
> On 08/03/2022 08:49, Yicong Yang wrote:
>> The DMA of HiSilicon PTT device can only work with identical mapping.
>
> nit: I'd have "DMA operations of the HiSilicon PTT device can only work
> properly with identity mappings".
>
>> So add a quirk for the
31 matches
Mail list logo
