Re: [PATCH RFC 06/12] remoteproc: virtio: add bounce buffering for data buffers

On Fri, Sep 25, 2026 at 09:05:43PM +0200, Francesco Valla wrote:

Hi Robin, Mathieu,

On Fri, Sep 25, 2026 at 05:48:25PM +0100, Robin Murphy wrote:

quoted

On 25/09/2026 4:07 pm, Mathieu Poirier wrote:

quoted

On Wed, Sep 23, 2026 at 06:05:35PM +0200, Francesco Valla wrote:

quoted

On Wed, Sep 23, 2026 at 08:44:41AM -0600, Mathieu Poirier wrote:

quoted

On Tue, 22 Sept 2026 at 13:39, Francesco Valla [off-list ref] wrote:

quoted

On Tue, Sep 22, 2026 at 09:58:53AM -0600, Mathieu Poirier wrote:

quoted

On Wed, Sep 16, 2026 at 11:10:51PM +0200, Francesco Valla wrote:

quoted

Depending on the driver originating them, data buffers used for virtio
communication can either:

   - already be allocated from the coherent memory area that is
     accessible by the remote processor; this is the case of rpmsg
     and the rproc flavor of virtio-console;
   - be allocated from generic kmem, and thus not accessible directly by
     the remote processor.

Exploiting the map operations, which are used by the virtio framework
when VIRTIO_F_ACCESS_PLATFORM is part of a vdev's feature flags, add
bounce buffering for the second case: when the map() callback is called
for a buffer, one or more pages of coherent memory are allocated and
data is copied to them, then they are exposed to the remote processor;
the data is  then bounced back on unmap().

The first case is not impacted, since buffers already suitable for
remote transmission are passed through.

With the bounce buffering in place, any kind of virtio device can be
supported through the remoteproc-virtio transport, at least from a
data exchange standpoint.

Is this _necessary_ for the imx93 platform you are implementing feature for?

If I don't want to fundamentally change how the remoteproc integration
works (i.e.: using buffers only from a pre-shared area), yes. While in
my test environment the Cortex-M33 serving as remoteproc is able to
access the whole RAM space, that is not always the case.

The first sentence tells me it is mandatory while the second says it
is not.  I understand the use case but don't want to bloat the
subsystem with code that is trying to address a problem you currently
don't have.

Let me rephrase: while on i.MX93 the Cortex-M33 can theoretically access
the whole RAM space, that is not a good idea from a security point of
view and can be the source of a number of bugs. The target is to
statically define a static shared memory area (as I am doing on i.MX95)
and only use that.

As Robin pointed out, have you looked at using a restricted-dma-pool for that?
Note that I am not familiar with the concept but open to go that way if it can
work for us.

Robin, can you point us to a simple example we could look at?

The only in-tree example is mt8192-asurada.dtsi, but even there the
fundamental principle seems exactly the same - the system interconnect is
locked down such that there's only a particular region of "shared" memory
that PCIe DMA can access, so the restricted pool is placed there, and in
that case can occupy the entire region since the wifi adapter only really
does streaming DMA - restricted pools have some limited ability to act as a
fallback for coherent allocations, which won't work for everything, but does
happen to be enough for that wifi driver.

Here it would be a case of reserving some of the shared region for a
restricted pool alongside the "vdevbuffer" coherent pool, adding it to the
memory-region list of the relevant device(s), and usually that would then
just work, since the setup is all done automatically by the core DT code.
However I know remoteproc does some funky stuff with child devices, so it's
quite possible there might need to be something more done there. But still
far, far less than reimplementing a whole other bounce-buffering system.

Thanks,
Robin.

I took a look at the restricted-memory-pool - with which I wasn't
familiar - and seems exactly what is needed here.

I am working on a new prototype with it - if everything works as
expected (I still did not have time to try it) it should only need some
very limited glue code, cutting the modifications in the
remoteproc_virtio driver by 95%. I'll let you knwow.

Quick update: it works, with minimal glue code as expected. I am
preparing a v2 based on restricted-memory-pool, but it will take some
days, as I am addressing the other topics pointed out by Mathieu. I plan
to propose an update to the documentation too, since the setup is not so
straightforward.

Thank you again.

Regards,
Francesco