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;
>
>
16 matches
Mail list logo
