All of lore.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: 34+ 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 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: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 19:41                       ` David Cohen
2011-03-07 21:19                       ` Laurent Pinchart
2011-03-07 21:35                         ` David Cohen
2011-03-07 21:35                           ` David Cohen
2011-03-08  9:07                           ` Hiroshi DOYU
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: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  9:55                         ` David Cohen
2011-03-08 17:49                         ` Guzman Lugo, Fernando
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.