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 <[email protected]> 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.
