On Sat, Nov 12, 2011 at 11:04 AM, Stepan Moskovchenko
wrote:
> Yes, the scatterlist is allowed to have different page sizes. But, they are
> required to have a length that is a multiple of 4K. If a page in the list is
An element in scatterlist may not be aligned by 4K but I think IOMMU driver
mus
On 11/11/2011 5:24 AM, Joerg Roedel wrote:
On Thu, Nov 10, 2011 at 01:12:00PM -0800, Stepan Moskovchenko wrote:
I have been experimenting with an iommu_map_range call, which maps a
given scatterlist of discontiguous physical pages into a contiguous
virtual region at a given IOVA. This has some p
On Fri, Nov 11, 2011 at 01:27:28PM +, David Woodhouse wrote:
> On Fri, 2011-11-11 at 13:58 +0100, Joerg Roedel wrote:
> > For AMD IOMMU there is a feature called not-present cache. It says that
> > the IOMMU caches non-present entries as well and needs an IOTLB flush
> > when something is mappe
On Fri, 2011-11-11 at 13:58 +0100, Joerg Roedel wrote:
> For AMD IOMMU there is a feature called not-present cache. It says that
> the IOMMU caches non-present entries as well and needs an IOTLB flush
> when something is mapped (meant for software implementations of the
> IOMMU).
> So it can't be r
On Thu, Nov 10, 2011 at 01:12:00PM -0800, Stepan Moskovchenko wrote:
> I have been experimenting with an iommu_map_range call, which maps a
> given scatterlist of discontiguous physical pages into a contiguous
> virtual region at a given IOVA. This has some performance advantages
> over just callin
On Thu, Nov 10, 2011 at 07:28:39PM +, David Woodhouse wrote:
> ... which implies that a mapping, once made, might *never* actually get
> torn down until we loop and start reusing address space? That has
> interesting security implications.
Yes, it is a trade-off between security and performan
On 11/10/2011 9:09 AM, Joerg Roedel wrote:
The plan is to have a single DMA-API implementation for all IOMMU
drivers (X86 and ARM) which just uses the IOMMU-API. But to make this
performing reasonalbly well a few changes to the IOMMU-API are
required. I already have some ideas which we can disc
On Thu, 2011-11-10 at 18:09 +0100, Joerg Roedel wrote:
> The requirement for the DMA-API is, that the IOTLB must be consistent
> with existing mappings, and only with the parts that are really mapped.
> The unmapped parts are not important.
>
> This allows nice optimizations like your 'batched unm
On Thu, Nov 10, 2011 at 03:28:50PM +, David Woodhouse wrote:
> Which brings me to another question I have been pondering... do we even
> have a consensus on exactly *when* the IOTLB should be flushed?
Well, sort of, there is still the outstanding idea of the
iommu_commit() interface for the I
On Thu, 2011-11-10 at 14:17 +0800, Kai Huang wrote:
> And another question: have we considered the IOTLB flush operation? I
> think we need to implement similar logic when flush the DVMA range.
> Intel VT-d's manual says software needs to specify the appropriate
> mask value to flush large pages, b
On Thu, Nov 10, 2011 at 10:35:34PM +0800, cody wrote:
> Yes I totally agree page-size is not required for unmap operations
> and should not be added as parameter to map/unmap operations. I am
> not saying the unmap operation, but the IOTLB flush operation. My
> point is we also may also need to add
On 11/10/2011 09:08 PM, Joerg Roedel wrote:
On Thu, Nov 10, 2011 at 08:16:16PM +0800, cody wrote:
On 11/10/2011 03:31 PM, Ohad Ben-Cohen wrote:
On Thu, Nov 10, 2011 at 8:17 AM, Kai Huang wrote:
Seems the unmap function don't take phys as parameter, does this mean
domain->op
On Thu, Nov 10, 2011 at 08:16:16PM +0800, cody wrote:
> On 11/10/2011 03:31 PM, Ohad Ben-Cohen wrote:
> >On Thu, Nov 10, 2011 at 8:17 AM, Kai Huang wrote:
> >>Seems the unmap function don't take phys as parameter, does this mean
> >>domain->ops->unmap will walk through the page table to find out t
On 11/10/2011 03:31 PM, Ohad Ben-Cohen wrote:
On Thu, Nov 10, 2011 at 8:17 AM, Kai Huang wrote:
Seems the unmap function don't take phys as parameter, does this mean
domain->ops->unmap will walk through the page table to find out the
actual page size?
The short answer is yes, and fur
On Thu, Nov 10, 2011 at 8:17 AM, Kai Huang wrote:
> Seems the unmap function don't take phys as parameter, does this mean
> domain->ops->unmap will walk through the page table to find out the
> actual page size?
The short answer is yes, and furthermore, we also consider to remove
the size param f
>
> -int iommu_unmap(struct iommu_domain *domain, unsigned long iova, int
> gfp_order)
> +size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t
> size)
> {
> - size_t size, unmapped;
> + size_t unmapped_page, unmapped = 0;
> + unsigned int min_pagesz;
>
>
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to d
17 matches
Mail list logo
