remoteproc DMA API abuse status

remoteproc DMA API abuse status

[Christoph Hellwig]

Hi remoteproc maintainers,

did you make any progress to get remoteproc out of creating fake
devices that fake their dma ops status and the abuse of
dma_declare_coherent_memory in removeproc_virtio?  I remember we had
a discussion on this a long time ago, and there was an unfinished
patchset to change the memory pool handling.  What happened to all that?

Re: remoteproc DMA API abuse status

[Mathieu Poirier]

Good day Christoph,

On Wed, Jun 23, 2021 at 03:43:07PM +0200, Christoph Hellwig wrote:
> Hi remoteproc maintainers,
> 
> did you make any progress to get remoteproc out of creating fake
> devices that fake their dma ops status and the abuse of
> dma_declare_coherent_memory in removeproc_virtio?  I remember we had
> a discussion on this a long time ago, and there was an unfinished
> patchset to change the memory pool handling.  What happened to all that?

I believe the conversation and patchset you are referring to are pre-dating my
time in this subsystem.  To make sure I am looking at the right thing, can you
(or anyone else) point me to that discussion and related patches?  

Thanks,
Mathieu

Re: remoteproc DMA API abuse status

[Arnaud POULIQUEN]

Hello Mathieu,

On 6/24/21 9:35 PM, Mathieu Poirier wrote:
> Good day Christoph,
> 
> On Wed, Jun 23, 2021 at 03:43:07PM +0200, Christoph Hellwig wrote:
>> Hi remoteproc maintainers,
>>
>> did you make any progress to get remoteproc out of creating fake
>> devices that fake their dma ops status and the abuse of
>> dma_declare_coherent_memory in removeproc_virtio?  I remember we had
>> a discussion on this a long time ago, and there was an unfinished
>> patchset to change the memory pool handling.  What happened to all that?
> 
> I believe the conversation and patchset you are referring to are pre-dating my
> time in this subsystem.  To make sure I am looking at the right thing, can you
> (or anyone else) point me to that discussion and related patches?

2 references:

1)Previous discussion thread on the topic:

https://patchwork.kernel.org/project/linux-remoteproc/patch/AOKowLclCbOCKxyiJ71WeNyuAAj2q8EUtxrXbyky5E@cp7-web-042.plabs.ch/

2) My patchset related to the refactoring of remoteproc virtio which tries to
address the point by creating a remoteproc platform driver and declaring a
virtio subnode in the device tree remoteproc node.

https://lkml.org/lkml/2020/4/16/1817

No time yet on my side to come back on the patchset :(

Regards,
Arnaud

> 
> Thanks,
> Mathieu
> 

Re: remoteproc DMA API abuse status

[Christoph Hellwig]

On Fri, Jun 25, 2021 at 09:27:09AM +0200, Arnaud POULIQUEN wrote:
> > I believe the conversation and patchset you are referring to are pre-dating my
> > time in this subsystem.  To make sure I am looking at the right thing, can you
> > (or anyone else) point me to that discussion and related patches?
> 
> 2 references:
> 
> 1)Previous discussion thread on the topic:
> 
> https://patchwork.kernel.org/project/linux-remoteproc/patch/AOKowLclCbOCKxyiJ71WeNyuAAj2q8EUtxrXbyky5E@cp7-web-042.plabs.ch/
> 
> 2) My patchset related to the refactoring of remoteproc virtio which tries to
> address the point by creating a remoteproc platform driver and declaring a
> virtio subnode in the device tree remoteproc node.
> 
> https://lkml.org/lkml/2020/4/16/1817
> 
> No time yet on my side to come back on the patchset :(

I was hoping you'd make some progress on that.  Any way I could help
without having access to the relevant hardware myself?

Re: remoteproc DMA API abuse status

[Mathieu Poirier]

On Fri, Jun 25, 2021 at 09:27:09AM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
> 
> On 6/24/21 9:35 PM, Mathieu Poirier wrote:
> > Good day Christoph,
> > 
> > On Wed, Jun 23, 2021 at 03:43:07PM +0200, Christoph Hellwig wrote:
> >> Hi remoteproc maintainers,
> >>
> >> did you make any progress to get remoteproc out of creating fake
> >> devices that fake their dma ops status and the abuse of
> >> dma_declare_coherent_memory in removeproc_virtio?  I remember we had
> >> a discussion on this a long time ago, and there was an unfinished
> >> patchset to change the memory pool handling.  What happened to all that?
> > 
> > I believe the conversation and patchset you are referring to are pre-dating my
> > time in this subsystem.  To make sure I am looking at the right thing, can you
> > (or anyone else) point me to that discussion and related patches?
> 
> 2 references:
> 
> 1)Previous discussion thread on the topic:
> 
> https://patchwork.kernel.org/project/linux-remoteproc/patch/AOKowLclCbOCKxyiJ71WeNyuAAj2q8EUtxrXbyky5E@cp7-web-042.plabs.ch/
>

I remember that one.  Glad to see there wasn't anything else before that.

> 2) My patchset related to the refactoring of remoteproc virtio which tries to
> address the point by creating a remoteproc platform driver and declaring a
> virtio subnode in the device tree remoteproc node.
> 
> https://lkml.org/lkml/2020/4/16/1817
> 

I thought your current work on refactoring the rpmsg_char driver was part of the
early steps on the way to splitting that patchset up...

> No time yet on my side to come back on the patchset :(
> 

I know the feeling.

Thanks for the info,
Mathieu

Re: remoteproc DMA API abuse status

[Arnaud POULIQUEN]

Hi Mathieu

On 6/28/21 10:14 PM, Mathieu Poirier wrote:
> I thought your current work on refactoring the rpmsg_char driver was part of the
> early steps on the way to splitting that patchset up...

No it is de-correlated. Here the point is the vdev0buffer memory region declared
in rproc that we associate to the rproc_virtio device to be able to use is for
RPMsg.

When I have a look this here is the approach we had trying to fix it (this
correspond to my patchset):

The objective is to suppress the dma_declare_coherent_memory usage.

=> In this case the "vdev0buffer" virtio buffer memory pool has do be associated
to the a virtio device by a declaration in device tree. Probably as a subnode of
the remoteproc device node.


&rproc {
	#address-cells = <1>;
	#size-cells = <0>;

+	vdev@0 {
+		memory-region = <&vdev0vring0>,	<&vdev0vring1>, <&vdev0buffer>;
+		compatible = "rproc-virtio";
+		reg = <0>;
+		status = "okay";
+	};
 };


=> a reproc virtio platform driver compatible should be created (based on
remoteproc core and remote_virtio restructuring). The memory region will be in
this case associated in a clean way to the remoteproc virtio device.

=> As consequence we would have 2 module devices the remoteproc and remoteproc
virtio. Both as to be synchronized to ensure that all is ready  before starting
the remote processor => reuse of the proc->subdev mechanism + (component
bind/unbind similar to DRM?)

The last but not the least we probably have to maintain the legacy a while to
let time to move on this new device tree architecture.

Now the question are:
- Is this the good approach or could a simpler patch can fix the issue.
- how to address models with one big memory pool used (TI implementation)


Regards,
Arnaud