Hi Baolu,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Monday, November 5, 2018 1:32 PM
> Subject: [PATCH v4 03/12] iommu/vt-d: Move page table helpers into header
>
> So that they could also be used in other source files.
Just a refine. :)
"This patch moves page table helpers to h
Hi Baolu,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Monday, November 5, 2018 1:32 PM
> Subject: [PATCH v4 10/12] iommu/vt-d: Add first level page table interface
>
> This adds an interface to setup the PASID entries for first
This patch adds interface to setup the PASID entries
Hi Baolu,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Monday, November 5, 2018 1:32 PM
> Subject: [PATCH v4 08/12] iommu/vt-d: Pass pasid table to context mapping
>
> So that the pasid related info, such as the pasid table and the
> maximum of pasid could be used during setting up
Hi Baolu,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Monday, November 5, 2018 1:32 PM
>
> This adds the interfaces to setup or tear down the structures
> for second level page table translations. This includes types
> of second level only translation and pass through.
A little bi
Hi Baolu,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Monday, November 5, 2018 1:32 PM
> Subject: [PATCH v4 05/12] iommu/vt-d: Reserve a domain id for FL and PT modes
>
> Vt-d spec rev3.0 (section 6.2.3.1) requires that each pasid
> entry for first-level or pass-through translation
Hi Baolu,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Monday, November 5, 2018 1:32 PM
[...]
> ---
> drivers/iommu/dmar.c| 83 +++--
> drivers/iommu/intel-svm.c | 76 --
> drivers/iommu/intel_irq_remapping.
Hi,
On 10/20/18 2:11 AM, Jean-Philippe Brucker wrote:
+static inline void *ioasid_find(struct ioasid_set *set, ioasid_t ioasid)
+{
+ return -ESRCH;
return NULL;
Best regards,
Lu Baolu
+}
+#endif /* CONFIG_IOASID */
+#endif /* __LINUX_IOASID_H */
__
Hi Joerg,
On 11/7/18 12:25 AM, j...@8bytes.org wrote:
On Mon, Oct 22, 2018 at 12:50:56PM +0100, Robin Murphy wrote:
To me, that sounds like a very good argument for having separate "attach as
primary domain" and "attach as aux domain" APIs.
I agree with that, overloading iommu_attach_device()
Hi,
On 11/6/18 6:40 PM, James Sewart wrote:
Hey Lu,
Would you be able to go into more detail about the issues with
allowing IOMMU_DOMAIN_DMA to be allocated via domain_alloc?
This door is closed because intel iommu driver does everything for
IOMMU_DOMAIN_DMA: allocating a domain and setup the
Hi Alex,
On 11/7/18 7:53 AM, Alex Williamson wrote:
On Mon, 5 Nov 2018 15:34:06 +0800
Lu Baolu wrote:
A parent device might create different types of mediated
devices. For example, a mediated device could be created
by the parent device with full isolation and protection
provided by the IOMM
On Mon, Oct 8, 2018 at 1:04 AM Christoph Hellwig wrote:
>
> No need to duplicate the code - map_sg is equivalent to map_page
> for each page in the scatterlist.
>
> Signed-off-by: Christoph Hellwig
> ---
> kernel/dma/swiotlb.c | 34 --
> 1 file changed, 12 inserti
Hi Robin,
On Tue, Nov 06, 2018 at 06:27:39PM +, Robin Murphy wrote:
> > I re-ran the test to get some accuracy within the function and got:
> > 1) pages = __iommu_dma_alloc_pages(count, alloc_sizes >> PAGE_SHIFT, gfp);
> > // reduced from 422 usec to 56 usec == 366 usec less
> > 2) if (!(p
On Mon, 5 Nov 2018 15:34:06 +0800
Lu Baolu wrote:
> A parent device might create different types of mediated
> devices. For example, a mediated device could be created
> by the parent device with full isolation and protection
> provided by the IOMMU. One usage case could be found on
> Intel plat
On Tue, Nov 6, 2018 at 3:54 AM, Robin Murphy wrote:
> of_dma_configure() was *supposed* to be following the same logic as
> acpi_dma_configure() and only setting bus_dma_mask if some range was
> specified by the firmware. However, it seems that subtlety got lost in
> the process of fitting it into
Hi Christoph,
On Sun, Nov 04, 2018 at 07:50:01AM -0800, Christoph Hellwig wrote:
> On Thu, Nov 01, 2018 at 02:35:00PM -0700, Nicolin Chen wrote:
> > The __GFP_ZERO will be passed down to the generic page allocation
> > routine which zeros everything page by page. This is safe to be a
> > generic w
Supported guest address witdh (SGAW) only indicates
what the iommu's capabilities are wrt page table levels
for second level page-tables. IOMMU should pick the
right level depending on the Maximum Guest Address Width
(MGAW).
For pass-through translation type, address width must be
programmed with
Hi Geert,
On 2018-11-06 7:44 pm, Geert Uytterhoeven wrote:
Hi Christoph et al,
On Tue, Oct 23, 2018 at 1:40 AM Linux Kernel Mailing List
wrote:
Commit: b4ebe6063204da58e48600b810a97c29ae9e5d12
Parent: 7d21ee4c719f00896767ce19c4c01a56374c2ced
Refname:refs/heads/master
Web:
Hi Christoph et al,
On Tue, Oct 23, 2018 at 1:40 AM Linux Kernel Mailing List
wrote:
> Commit: b4ebe6063204da58e48600b810a97c29ae9e5d12
> Parent: 7d21ee4c719f00896767ce19c4c01a56374c2ced
> Refname:refs/heads/master
> Web:
> https://git.kernel.org/torvalds/c/b4ebe6063204da58e48
Hi,
On Tue, Nov 06, 2018 at 11:54:15AM +, Robin Murphy wrote:
> of_dma_configure() was *supposed* to be following the same logic as
> acpi_dma_configure() and only setting bus_dma_mask if some range was
> specified by the firmware. However, it seems that subtlety got lost in
> the process of f
On 02/11/2018 23:36, Nicolin Chen wrote:
On Fri, Nov 02, 2018 at 04:54:07PM +, Robin Murphy wrote:
On 01/11/2018 21:35, Nicolin Chen wrote:
The __GFP_ZERO will be passed down to the generic page allocation
routine which zeros everything page by page. This is safe to be a
generic way but not
On Mon, Oct 22, 2018 at 12:50:56PM +0100, Robin Murphy wrote:
> To me, that sounds like a very good argument for having separate "attach as
> primary domain" and "attach as aux domain" APIs.
I agree with that, overloading iommu_attach_device() to support
aux-domains is not going to be a maintainab
On Mon, Nov 05, 2018 at 10:18:58AM +0800, Lu Baolu wrote:
> When handling page request without pasid event, go to "no_pasid"
> branch instead of "bad_req". Otherwise, a NULL pointer deference
> will happen there.
>
> Cc: Ashok Raj
> Cc: Jacob Pan
> Cc: Sohil Mehta
> Signed-off-by: Lu Baolu
> -
On Wed, Oct 17, 2018 at 11:13:22AM +0200, Simon Horman wrote:
> From: Hai Nguyen Pham
>
> Support the R-Car E3 (r8a77990) IPMMU.
>
> Signed-off-by: Hai Nguyen Pham
> Signed-off-by: Kazuya Mizuguchi
> [simon: rebased; dropped no longer required IOMMU_OF_DECLARE hunk]
> Signed-off-by: Simon Horm
On Thu, Oct 11, 2018 at 04:56:42PM +0100, Robin Murphy wrote:
> The original motivation for iommu_map_sg() was to give IOMMU drivers the
> chance to map an IOVA-contiguous scatterlist as efficiently as they
> could. It turns out that there isn't really much driver-specific
> business involved there
On 05/11/2018 14:58, Christoph Hellwig wrote:
On Fri, Nov 02, 2018 at 04:36:13PM -0700, Nicolin Chen wrote:
What if the pages came from highmem? I know that doesn't happen on arm64
today, but the point of this code *is* to be generic, and other users will
arrive eventually.
Hmm, so it probably
of_dma_configure() was *supposed* to be following the same logic as
acpi_dma_configure() and only setting bus_dma_mask if some range was
specified by the firmware. However, it seems that subtlety got lost in
the process of fitting it into the differently-shaped control flow, and
as a result the for
Hey Lu,
Would you be able to go into more detail about the issues with
allowing IOMMU_DOMAIN_DMA to be allocated via domain_alloc?
Cheers,
James.
On Fri, Nov 2, 2018 at 2:43 AM Lu Baolu wrote:
>
> Hi,
>
> On 10/30/18 10:18 PM, James Sewart via iommu wrote:
> > Hey,
> >
> > I’ve been investigati
27 matches
Mail list logo
