On Mon, Sep 27, 2021 at 09:42:58AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 8:40 PM
> >
> > > > Ie the basic flow would see the driver core doing some:
> > >
> > > Just double confirm. Is there concern on having the driver core to
> > > call
On 2021/9/27 17:42, Tian, Kevin wrote:
+int iommu_device_set_dma_hint(struct device *dev, enum dma_hint hint)
+{
+ struct iommu_group *group;
+ int ret;
+
+ group = iommu_group_get(dev);
+ /* not an iommu-probed device */
+ if (!group)
+ return 0;
+
+
From: Arnd Bergmann
clang-14 notices that a comparison is never true when
CONFIG_PHYS_ADDR_T_64BIT is disabled:
drivers/iommu/mtk_iommu.c:553:34: error: result of comparison of constant
5368709120 with expression of type 'phys_addr_t' (aka 'unsigned int') is always
false
From: Jan Beulich
[ Upstream commit 9074c79b62b6e0d91d7f716c6e4e9968eaf9e043 ]
While the hypervisor hasn't been enforcing this, we would still better
avoid issuing requests with GFNs not aligned to the requested order.
Instead of altering the value also in the call to panic(), drop it
there for
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:40 PM
>
> > > Ie the basic flow would see the driver core doing some:
> >
> > Just double confirm. Is there concern on having the driver core to
> > call iommu functions?
>
> It is always an interesting question, but I'd say iommu
> From: Jason Gunthorpe
> Sent: Monday, September 27, 2021 7:54 PM
>
> On Mon, Sep 27, 2021 at 09:42:58AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, September 22, 2021 8:40 PM
> > >
> > > > > Ie the basic flow would see the driver core doing some:
> > > >
> > >
> From: Lu Baolu
> Sent: Monday, September 27, 2021 7:34 PM
>
> On 2021/9/27 17:42, Tian, Kevin wrote:
> > +int iommu_device_set_dma_hint(struct device *dev, enum dma_hint hint)
> > +{
> > + struct iommu_group *group;
> > + int ret;
> > +
> > + group = iommu_group_get(dev);
> > + /* not
Hi Christoph:
Gentile ping. The swiotlb and shared memory mapping changes in this
patchset needs your reivew. Could you have a look?
Thanks.
On 9/22/2021 6:34 PM, Tianyu Lan wrote:
Hi Christoph:
This patch follows your purposal in the previous discussion.
Could you have a look?
On Mon, Sep 27, 2021 at 09:42:58AM +, Tian, Kevin wrote:
> +static int iommu_dev_viable(struct device *dev, void *data)
> +{
> + enum dma_hint hint = *data;
> + struct device_driver *drv = READ_ONCE(dev->driver);
> +
> + /* no conflict if the new device doesn't do DMA */
> +
From: Arnd Bergmann
Now that SCM can be a loadable module, we have to add another
dependency to avoid link failures when ipa or adreno-gpu are
built-in:
aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
ipa_main.c:(.text+0xfc4): undefined reference to
On Mon, Sep 27, 2021 at 01:00:08PM +, Tian, Kevin wrote:
> > I think for such a narrow usage you should not change the struct
> > device_driver. Just have pci_stub call a function to flip back to user
> > mode.
>
> Here we want to ensure that kernel dma should be blocked
> if the group is
On Thu, Sep 16, 2021 at 05:40:59PM -0600, Logan Gunthorpe wrote:
> Introduce pci_mmap_p2pmem() which is a helper to allocate and mmap
> a hunk of p2pmem into userspace.
>
> Pages are allocated from the genalloc in bulk and their reference count
> incremented. They are returned to the genalloc
s/pci_find_dvsec_capability/pci_find_dvsec_capability()/ in subject
and commit log.
On Thu, Sep 23, 2021 at 10:26:44AM -0700, Ben Widawsky wrote:
> Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
> Extended Capability with the specified DVSEC ID.
"specified Vendor ID and
On Thu, Sep 16, 2021 at 05:40:53PM -0600, Logan Gunthorpe wrote:
> This interface is superseded by support in dma_map_sg() which now supports
> heterogeneous scatterlists. There are no longer any users, so remove it.
>
> Signed-off-by: Logan Gunthorpe
Acked-by: Bjorn Helgaas
Ditto.
> ---
>
On Thu, Sep 16, 2021 at 05:40:42PM -0600, Logan Gunthorpe wrote:
> Attempt to find the mapping type for P2PDMA pages on the first
> DMA map attempt if it has not been done ahead of time.
>
> Previously, the mapping type was expected to be calculated ahead of
> time, but if pages are to come from
On Thu, Sep 16, 2021 at 05:40:43PM -0600, Logan Gunthorpe wrote:
> pci_p2pdma_map_type() will be needed by the dma-iommu map_sg
> implementation because it will need to determine the mapping type
> ahead of actually doing the mapping to create the actual iommu mapping.
I don't expect this to go
On Thu, Sep 16, 2021 at 05:40:44PM -0600, Logan Gunthorpe wrote:
> Add pci_p2pdma_map_segment() as a helper for simple dma_map_sg()
> implementations. It takes an scatterlist segment that must point to a
> pci_p2pdma struct page and will map it if the mapping requires a bus
> address.
>
> The
On Mon, Sep 27, 2021 at 10:42 PM Bjorn Andersson
wrote:
> On Mon 27 Sep 13:15 PDT 2021, Arnd Bergmann wrote:
> > On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson
> > wrote:
> >
> > An easier option might be to find a way to build QCOM_SCM without
> > RESET_CONTROLLER for compile testing
On Thu, Sep 23, 2021 at 04:17:05PM -0700, Andy Lutomirski wrote:
> > + fpregs_lock();
> > +
> > + /*
> > +* If the task's FPU doesn't need to be loaded or is valid, directly
> > +* write the IA32_PASID MSR. Otherwise, write the PASID state and
> > +* the MSR will be loaded from the
On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson
wrote:
> On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > - To avoid a circular dependency chain involving RESET_CONTROLLER
> >and PINCTRL_SUNXI, change the 'depends on RESET_CONTROLLER' in
> >the latter
On Mon 27 Sep 13:15 PDT 2021, Arnd Bergmann wrote:
> On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson
> wrote:
> > On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > - To avoid a circular dependency chain involving RESET_CONTROLLER
> > >and
On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Now that SCM can be a loadable module, we have to add another
> dependency to avoid link failures when ipa or adreno-gpu are
> built-in:
>
> aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
>
On 2021-09-27 12:53 p.m., Bjorn Helgaas wrote:
> Acked-by: Bjorn Helgaas
>
> Ditto.
Thanks Bjorn, I'll make these changes and add your Acks for subsequent
postings.
Logan
___
iommu mailing list
iommu@lists.linux-foundation.org
Hi Eric,
> This is based on Jean-Philippe's
> [PATCH v14 00/10] iommu: I/O page faults for SMMUv3
> https://www.spinics.net/lists/arm-kernel/msg886518.html
> (including the patches that were not pulled for 5.13)
>
Jean's patches have been merged to v5.14.
Do you anticipate IOMMU/VFIO part patches
Please spell out "register block indicator" in the subject so that the
shortlog remains somewhat readable.
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky wrote:
>
> In preparation for passing around the Register Block Indicator (RBI) as
> a parameter, it is desirable to convert the type to an
On 9/27/21 2:02 PM, Luck, Tony wrote:
> Or are you thinking of a helper that does both the check
> and the update ... so the code here could be:
>
> update_one_xsave_feature(XFEATURE_PASID, _val, sizeof(msr_val));
>
> With the helper being something like:
>
> void
On Mon, Sep 27, 2021 at 10:26:43PM +0800, Tianyu Lan wrote:
> Hi Christoph:
> Gentile ping. The swiotlb and shared memory mapping changes in this
> patchset needs your reivew. Could you have a look?
I'm a little too busy for a review of such a huge patchset right now.
That being said here are
On Mon, 2021-09-27 at 14:18 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> clang-14 notices that a comparison is never true when
> CONFIG_PHYS_ADDR_T_64BIT is disabled:
>
> drivers/iommu/mtk_iommu.c:553:34: error: result of comparison of
> constant 5368709120 with expression of type
28 matches
Mail list logo
