On Tue, Jun 23, 2015 at 07:17:44AM +0200, Michael S. Tsirkin wrote:

On Sat, May 16, 2015 at 12:32:10PM +0300, Ohad Ben-Cohen wrote:

quoted

On Thu, May 7, 2015 at 3:28 AM, Edgar E. Iglesias
[off-list ref] wrote:

quoted

On Wed, May 06, 2015 at 03:51:48PM +0930, Rusty Russell wrote:

quoted

"Edgar E. Iglesias" [off-list ref] writes:

quoted

From: "Edgar E. Iglesias" <redacted>

Signed-off-by: Edgar E. Iglesias <redacted>

First off, I have handed maintainership off to Michael S. Tsirkin, so
his word is now law.

That said... there's nothing fundamentally *wrong* with this, but it's
not how standard virtio works.  We decided some time ago that as we're
paravirtualized, we would not be doing address mapping.

rpmsg uses virtio, but it's with a twist: they're not talking to a
host.  Thus my preference, in order, would be:

1) Don't use non-kmalloc addresses.
2) If that's not possible, call these _dma interfaces _rpmsg instead,
   so normal virtio users don't get confused and try to use them.

Thanks Rusty,

That was helpful, I'll see if I can do something in line with nr 2.

AFAICT, #1 will be hard. The remote-processor would have to be
cache-coherent and share memory address-space view with the master
CPU. This is not the common case for remoteproc (unlike when virtio
communication flows between host and guest on the same CPU or SMP system).
Ohad, do you have any thoughts on this?

rpmsg is allocating a large chunk (256KB) of physically-contiguous CMA
memory today, which is exposed via the dma_alloc_coherent API (and set
up in advance by platform-specific code), so if #2 above is
acceptable, it would be easier, yeah.

Thanks,
Ohad.

I'm thinking same as Rusty: I'd prefer 1 but if not possible, I can live
with 2 above.

Thanks all for the feedback,

I'm currently travelling and won't be doing much coding until
august/september. We are using something along the lines of nr 2 at
Xilinx and it's working fine. I'll post something like that in
september if no one beats me to it.

Best regards,
Edgar