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: > > 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. > > 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
