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

[Robin Murphy]

On 25/09/2026 4:07 pm, Mathieu Poirier wrote:
> On Wed, Sep 23, 2026 at 06:05:35PM +0200, Francesco Valla wrote:
>> On Wed, Sep 23, 2026 at 08:44:41AM -0600, Mathieu Poirier wrote:
>>> On Tue, 22 Sept 2026 at 13:39, Francesco Valla <francesco at valla.it> wrote:
>>>>
>>>> On Tue, Sep 22, 2026 at 09:58:53AM -0600, Mathieu Poirier wrote:
>>>>> On Wed, Sep 16, 2026 at 11:10:51PM +0200, Francesco Valla wrote:
>>>>>> 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.