From: mail.kai.huang@gmail.com (cody)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
Date: Thu, 10 Nov 2011 22:35:34 +0800 [thread overview]
Message-ID: <4EBBE136.4030404@gmail.com> (raw)
In-Reply-To: <20111110130801.GC13213@amd.com>
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<mail.kai.huang@gmail.com> 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 from domain->ops->unmap entirely at some point.
>>>
>>> We had a long discussion about it, please see:
>>>
>>> https://lkml.org/lkml/2011/10/10/234
>>>
>> Yes I've seen your discussion, I followed this thread from beginning:)
>>
>> How about the IOTLB flush? As I said I think we need to consider
>> that IOMMU (even does not exist now) may have some limitation on
>> IOTLB flush, and hiding page size from IOTLB flush code may hurt
>> performance, or even worse, trigger undefined behaviors.
>>
> We can only care about IOMMUs that exist today or ones that will exist
> and we already know of.
> In general for the hardware I know of a page-size is not required for
> implementing unmap operations. Requiring this would imply that any user
> of the IOMMU-API needs to keeps track of the page-sizes used to map a
> given area.
> This would be a huge burden which is not really necessary because the
> IOMMU driver already has this information and can return it to the user.
> So if you want to change that you need a very good reason for it.
>
>
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 similar logic in IOTLB flush code (such as
in Intel IOMMU dirver) to grantee that when issuing IOTLB flush command
for large page, we will still meet the hardware limitation of flushing
large page. Seems for Intel IOMMU the only limitation is the mask value
(indicating number of 4k-pages) cannot be smaller than the value to
cover large page, and seems current Intel IOMMU driver code has covered
this case well. I am not familiar with how AMD IOMMU issues IOTLB flush
command, it should be able to handle this large page case too. So at
this moment, this patch should not have any issues :)
-cody
> Joerg
>
>
next prev parent reply other threads:[~2011-11-10 14:35 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 11:27 [PATCH v4 0/7] iommu: split mapping to page sizes as supported by the hardware Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 1/7] iommu/core: stop converting bytes to page order back and forth Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware Ohad Ben-Cohen
2011-11-10 6:17 ` Kai Huang
2011-11-10 7:31 ` Ohad Ben-Cohen
2011-11-10 12:16 ` cody
2011-11-10 13:08 ` Joerg Roedel
2011-11-10 14:35 ` cody [this message]
2011-11-10 14:51 ` Joerg Roedel
2011-11-10 15:28 ` David Woodhouse
2011-11-10 17:09 ` Joerg Roedel
2011-11-10 19:28 ` David Woodhouse
2011-11-11 12:58 ` Joerg Roedel
2011-11-11 13:27 ` David Woodhouse
2011-11-11 14:18 ` Joerg Roedel
[not found] ` <20111111131728.GG13213@amd.com>
2011-11-24 12:52 ` Changing IOMMU-API for generic DMA-mapping " Marek Szyprowski
2011-11-24 15:27 ` 'Joerg Roedel'
2011-11-10 21:12 ` [PATCH v4 2/7] iommu/core: split mapping to page sizes as " Stepan Moskovchenko
2011-11-11 13:24 ` Joerg Roedel
2011-11-12 2:04 ` Stepan Moskovchenko
2011-11-13 1:43 ` KyongHo Cho
2011-10-17 11:27 ` [PATCH v4 3/7] iommu/omap: announce supported page sizes Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 4/7] iommu/msm: " Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 5/7] iommu/amd: " Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 6/7] iommu/intel: " Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 7/7] iommu/core: remove the temporary pgsize settings Ohad Ben-Cohen
2011-11-08 12:57 ` [PATCH v4 0/7] iommu: split mapping to page sizes as supported by the hardware Ohad Ben-Cohen
2011-11-08 14:01 ` Joerg Roedel
2011-11-08 14:03 ` Ohad Ben-Cohen
2011-11-08 16:23 ` Joerg Roedel
2011-11-08 16:43 ` Ohad Ben-Cohen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EBBE136.4030404@gmail.com \
--to=mail.kai.huang@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).