linux-kernel - Re: [PATCH 1/7] remoteproc: resource table overhaul

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAK=WgbahzGHmvszw6HBgihN4NcPA8ceaQCNSOk_FC61bToxBXQ@mail.gmail.com>
Date:	Mon, 21 May 2012 17:00:40 +0300
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Michal Simek <monstr@...str.eu>
Cc:	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Brian Swetland <swetland@...gle.com>,
	Iliyan Malchev <malchev@...gle.com>,
	Arnd Bergmann <arnd@...db.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Mark Grosen <mgrosen@...com>,
	John Williams <john.williams@...alogix.com>,
	Loic PALLARDY <loic.pallardy@...ricsson.com>,
	Ludovic BARRE <ludovic.barre@...ricsson.com>,
	Omar Ramirez Luna <omar.luna@...aro.org>,
	Guzman Lugo Fernando <fernando.lugo@...com>,
	Anna Suman <s-anna@...com>, Clark Rob <rob@...com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Saravana Kannan <skannan@...eaurora.org>,
	David Brown <davidb@...eaurora.org>,
	Kieran Bingham <kieranbingham@...il.com>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH 1/7] remoteproc: resource table overhaul

Hi Michal,

On Mon, May 21, 2012 at 4:02 PM, Michal Simek <monstr@...str.eu> wrote:
> I have looked at it and tested on latest and greatest and the problem is
> still there.

Ok, I see why this is happening.

We're now allocating the vrings' DMA in ->find_vqs() just before we
boot the remote processor, and we release it on ->del_vqs(). These are
the virtio handlers for setting up and tearing down the vrings, so it
makes sense to do so, but as a result, we still don't get the early
carveout allocation you wanted.

> I have looked at the code and path is
> rproc_fw_config_virtio -> rproc_handliefirtion_rsc -> rproc_handle_vdev

Please note that rproc_handle_vdev doesn't allocate any DMA at this
point, and the allocation path is now quite different - it begins with
virtio_rpmsg_bus probing and then calling into the ->find_vqs()
handler.

> For me it is necessary to ensure that dma_alloc_coherent in
> rproc_alloc_vring is called after carveout allocation
> just because dma_alloc_cohorent takes mermory from preallocated pool which
> starts at 0x0.

ok.

> I also don't have
> any other advance mechanism how to ensure mapping for the second arm core.

Probably the best way to ensure this (without it breaking unexpectedly
again as remoteproc evolves) is to have separate sub-devices for
different kind of memories, which remoteproc could then look up using
something like device_find_child().

Ludovic is exploring this direction too, because STE also needs to
bind specific memory regions with predefined purposes, without
depending on the order of DMA allocations.

I think Ludovic already has a preliminary patch which he may be able
to share with you.

> Here is log which I need to get. Look at attached patch which exactly show
> you what I need to do which I have tested.

Yes, I see. Another temporary approach might be moving the vrings'
allocations to the rproc_handle_rsc table (in the RSC_VDEV slot), but
I'm not sure we want to merge this as well because this solution too
is only hiding the real issue and not solving it permanently.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/