linux-kernel - Re: [PATCH 0/9] XSHM: Shared Memory Driver for ST-E Thor M7400 LTE modem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201203221657.09820.arnd@arndb.de>
Date:	Thu, 22 Mar 2012 16:57:09 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Sjur BRENDELAND <sjur.brandeland@...ricsson.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	"sjurbren@...il.com" <sjurbren@...il.com>,
	"Ohad Ben-Cohen" <ohad@...ery.com>
Subject: Re: [PATCH 0/9] XSHM: Shared Memory Driver for ST-E Thor M7400 LTE modem

On Thursday 22 March 2012, Sjur BRENDELAND wrote:
> Hi Arnd,
> 
> I've got some updates since my last reply from December...
> 
> [Arnd]
> >>> Also, to what degree is the protocol design flexible? Is the modem
> >>> side fixed, so you have to live with any shortcomings of the interface,
> >>> or are you at this point able to improve both sides when something
> >>> is found to be lacking?
> 
> I have started working on the next generation shared memory interface for
> ST-Ericsson modems. So the interface design is now flexible! This means that
> I can be open to input and new ideas, at least for the next month or two.
> I'm hoping (if time allows) to prototype and post some patches while working
> on the specification.

Ok, very good.

> [Sjur]
> >> However for the long term perspective: we expect this interface to evolve
> >> for future products, so suggestions and input for improvements is welcome.
> >> rpmsg or at least the use of virtio-ring combined with a true end-to-end
> >> zero copy is something we definitely are interested to look into for the
> >> future.
> 
> My current idea for the new interface design is to use Virtio channels for
> transporting CAIF frames. The CAIF interface could be implemented as a
> virtio-driver using separate RX and TX rings.
> 
> For uplink traffic (TX) we could (initially) copy SKB into a buffer located in
> the shared-memory area, and add the buffer to the Virtio-ring. We will need
> to manage a fixed size buffer pool of uplink data buffers. (I don't think we
> will be able to access the kernel memory from the modem, so I cannot put SKB
> content directly on the virtio-ring as virtio-net does)
> 
> For Downlink payload (RX) I'm planning on using a reversed virtio-ring.
> The modem has its own sophisticated memory allocator for payload and
> implements mechanisms for efficient buffer handling inside the modem.
> The modem could add the payload buffer on the virtual-ring without
> copying and kick the host.

Remoteproc and rpmsg are now in the arm-soc tree and will be merged
upstream for v3.4, I suggest you discuss with Ohad how to best hook in
there.

What is the limitation for the addressing here, i.e. why can't the
modem access all of the host memory?

> [Sjur:]
> >>>> The driver for the stream channel is implemented as a character device
> ...
> [Arnd:]
> > My feeling is that a character device is not the ideal implementation here,
> > but I'm not sure what is. One option I can see is to declare the stream
> > interface part of the configuration logic and do everything through netlink,
> > packetizing the stream data in netlink frames. Alternatively, a tty port
> > device might be more appropriate than a plain chardev. Both of these
> > are likely a bit slower than what you have today, but my impression is that
> > performance is not the main design goal for the stream interface. If it is,
> > the best option would probably be to allow user space to mmap the buffer and
> > do the implementation in an application outside of the kernel.
> 
> For the stream interface it's tempting to reuse the ring buffer interface
> to the modem from last time. But perhaps the Virtio-console could be as the
> user-space interface, with a slim virtual device underneath feeding data
> from the ring-buffer into a virtual-ring...?

sounds doable, but again Ohad may have better suggestions as well.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/