public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
To: David Cohen <dacohen@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	"Guzman Lugo, Fernando" <fernando.lugo@ti.com>,
	Hiroshi.DOYU@nokia.com,
	Michael Jones <michael.jones@matrix-vision.de>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap: iommu: disallow mapping NULL address
Date: Wed, 09 Mar 2011 09:55:50 +0200	[thread overview]
Message-ID: <4D773286.9070408@maxwell.research.nokia.com> (raw)
In-Reply-To: <AANLkTi=5TRJo74c4zJtbRH=ybp2rrMkBvP6oZzvW1G=3@mail.gmail.com>

David Cohen wrote:
> On Tue, Mar 8, 2011 at 10:31 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>> Hi David,
>>
>> On Monday 07 March 2011 22:35:31 David Cohen wrote:
>>> On Mon, Mar 7, 2011 at 11:19 PM, Laurent Pinchart wrote:
>>>> On Monday 07 March 2011 20:41:21 David Cohen wrote:
>>>>> On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando wrote:
>>>>>> On Mon, Mar 7, 2011 at 1:19 PM, David Cohen wrote:
>>>>>>> On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando wrote:
>>>>>>>> On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones wrote:
>>>>>>>>> From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00
>>>>>>>>> 2001 From: Michael Jones <michael.jones@matrix-vision.de>
>>>>>>>>> Date: Mon, 7 Mar 2011 13:36:15 +0100
>>>>>>>>> Subject: [PATCH] omap: iommu: disallow mapping NULL address
>>>>>>>>>
>>>>>>>>> commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping
>>>>>>>>> the NULL address if da_start==0.  Force da_start to exclude the
>>>>>>>>> first page.
>>>>>>>>
>>>>>>>> what about devices that uses page 0? ipu after reset always starts
>>>>>>>> from 0x00000000 how could we map that address??
>>>>>>>
>>>>>>> from 0x0? The driver sees da == 0 as error. May I ask you why do you
>>>>>>> want it?
>>>>>>
>>>>>> unlike DSP that you can load a register with the addres the DSP will
>>>>>> boot, IPU core always starts from address 0x00000000, so if you take
>>>>>> IPU out of reset it will try to access address 0x0 if not map it,
>>>>>> there will be a mmu fault.
>>>>>
>>>>> Hm. Looks like the iommu should not restrict any da. The valid da
>>>>> range should rely only on pdata.
>>>>> Michael, what about just update ISP's da_start on omap-iommu.c file?
>>>>> Set it to 0x1000.
>>>>
>>>> What about patching the OMAP3 ISP driver to use a non-zero value (maybe
>>>> -1) as an invalid/freed pointer ?
>>>
>>> I wouldn't be comfortable to use 0 (or NULL) value as valid address on
>>> ISP driver.
>>
>> Why not ? The IOMMUs can use 0x00000000 as a valid address. Whether we allow
>> it or not is a software architecture decision, not influenced by the IOMMU
>> hardware. As some peripherals (namely IPU) require mapping memory to
>> 0x00000000, the IOMMU layer must support it and not treat 0x00000000
>> specially. All da == 0 checks to aim at catching invalid address values must
>> be removed, both from the IOMMU API and the IOMMU internals.
> 
> Yes, it can use and IOMMU should not treat is specially. That's the
> aim of my patch:
> [PATCH v2 3/3] omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag
> I'm not advocating to not allow 0x0, but to not use it when user is
> not requesting fixed da. In many sw architecture decisions 0x0 address
> is a special case. To avoid any misuse, IOMMU will not use it unless
> it's requested. If user is not requesting fixed 'da', it's not a
> problem to not give 0x0 anyway. IMO that's the safer option for all
> cases.

I agree.

>>> The 'da' range (da_start and da_end) is defined per VM and specified as
>>> platform data. IMO, to set da_start = 0x1000 seems to be> a correct approach
>>> for ISP as it's the only client for its IOMMU instance.
>>
>> We can do that, and then use 0 as an invalid pointer in the ISP driver. As the
>> IOMMU API will use another value (what about 0xffffffff, as for the userspace
>> mmap() call ?) to mean "invalid pointer", it might be better to use the same
>> value in the ISP driver.
> 
> That can be done, of course. But the main point is in OMAP3 ISP all
> initial register values to read/write from/to memory are 0x0. It means
> sometimes we can catch bugs more easily by not mapping that address.
> So, IMO, OMAP3 ISP should not allow to map first page. But that's a
> special case for this driver only.

I beg to disagree. The ISP isn't so special. The hardware registers
(including DMA destination registers) typically are NULL after reset and
NULL is used by drivers to mark a nonexistent object, for example a
video buffer.

There's a reason why the first page isn't mapped in the system MMU either.

Regards,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com

  reply	other threads:[~2011-03-09  7:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-01 16:41 omap3isp cache error when unloading Michael Jones
2011-03-02 19:18 ` Laurent Pinchart
2011-03-03 16:06   ` Michael Jones
2011-03-04  7:38     ` Sakari Ailus
2011-03-04 10:07       ` Hiroshi DOYU
2011-03-04 13:12     ` David Cohen
2011-03-04 14:39       ` Michael Jones
2011-03-04 15:45         ` David Cohen
2011-03-04 16:49           ` David Cohen
2011-03-07 13:10             ` [PATCH] omap: iommu: disallow mapping NULL address Michael Jones
2011-03-07 19:17               ` Guzman Lugo, Fernando
2011-03-07 19:19                 ` David Cohen
2011-03-07 19:25                   ` Guzman Lugo, Fernando
2011-03-07 19:41                     ` David Cohen
2011-03-07 21:19                       ` Laurent Pinchart
2011-03-07 21:35                         ` David Cohen
2011-03-08  9:07                           ` Hiroshi DOYU
2011-03-08 20:31                           ` Laurent Pinchart
2011-03-08 20:41                             ` Guzman Lugo, Fernando
2011-03-08 20:51                             ` David Cohen
2011-03-09  7:55                               ` Sakari Ailus [this message]
2011-03-08  9:02                       ` Hiroshi DOYU
2011-03-08  9:13                     ` Sakari Ailus
2011-03-08  9:55                       ` David Cohen
2011-03-08 17:49                         ` Guzman Lugo, Fernando
2011-03-08 17:45                       ` Guzman Lugo, Fernando

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=4D773286.9070408@maxwell.research.nokia.com \
    --to=sakari.ailus@maxwell.research.nokia.com \
    --cc=Hiroshi.DOYU@nokia.com \
    --cc=dacohen@gmail.com \
    --cc=fernando.lugo@ti.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=michael.jones@matrix-vision.de \
    /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