Reading virtio docs, I came across two sentences that may provide a way forward:
1) "Virtual queues, being virtual, are actually implemented as rings to traverse the guest-to-hypervisor transition. But this could be implemented any way, as long as both the guest and hypervisor implement it in the same way.” 2) "virtio has also been used in High-Performance Computing (HPC) research to develop inter-virtual machine (VM) communications through shared memory passing." @Suman, would it be possible to configure the memory resource used by Vrings (possibly DDR memory) so that the PRU memory/shared memory can be reserved as direct shared memory between PRU and ARM processors? The traditional message transported over virtualqueues will be use to setup/configure the shared memory. My purpose is use zero copy techniques by using direct memory sharing between PRU and ARM and avoid the need for vring message passing which require (topic, src, dst, *data & len) parameters for each message transfer. In addition, pru_rpmsg_send does a lot of work, such as pru_virtqueue_get_avail_buf(), preparing the message buffer and then finally pru_virtqueue_kick(). Using direct shared memory, both PRU and ARM can define a message structure/protocol that solves this one use case without breaking the existing framework. If RPMSG implements mmap(), then we might have a solution that should works for TJF. One additional thought; if RPMSG embraces zero copy, then this could be extended to eventually support vmsplice which would make for some very powerful features. Regards, John > On Jun 27, 2016, at 3:26 AM, TJF <jeli.freih...@gmail.com> wrote: > > @John3909: > > Am Montag, 27. Juni 2016 11:19:13 UTC+2 schrieb john3909: > While I haven’t tried this, I don’t believe there is anything in the > RemoteProc/RPMSG framework that prevents you from doing this now. You can > still use RemoteProc to load/start/stop your PRU firmware and you don’t have > to use virtio or rpmsg, but rather create a new KM to do just this. Suman > does this make sense? > So, thinking a little more about this, this new KM would support mmap() so > that your userspace app/lib could access this memory directly. Linux is out > of the way and yet everything is still secure ;-) > > Good John, you're closing up to this discussion. You're at this point now > (three days ago): > > [Suman: Right, the basic infrastructure is already there and you would need > only to build upon it. For eg., at the moment, all you would need is a small > kernel module, use pruss_request_mem_region to gain ownership of PRU > memories, export it to userspace and use it however you want. The interrupts > would have to go through kernel though. Maybe it is the same module that > exports the above desired sysfs interfaces too.] > > Am I reading right here? My message is: > Reduce resource consumption on a small SoC. > And your advice is: > Add a further module to a bloated framework. > > Go ahead! Once you're on track, it wouldn't need any "childish antics" any > more. I can hardly wait reading your opinion on the PRU virus issues. > > BR > > -- > For more options, visit http://beagleboard.org/discuss > <http://beagleboard.org/discuss> > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/a0fcf7b0-3682-4c4f-90de-a00fcfbdf0c1%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/a0fcf7b0-3682-4c4f-90de-a00fcfbdf0c1%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/67DAA936-BF28-42A5-8241-35FC3D17CD1D%40gmail.com. For more options, visit https://groups.google.com/d/optout.
