Re: DMA support via gb-netlink and gbridge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






On Tue, Apr 20, 2021 at 3:51 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> A: No.
> Q: Should I include quotations after my reply?
>
> http://daringfireball.net/2007/07/on_top
>

TIL about top-posting. Thanks for enlightening me!

>
> On Mon, Apr 19, 2021 at 02:59:56PM -0400, Kyle Harding wrote:
> > Thanks Greg, I've explained our solution poorly so I'll quote a colleague
> > as I'm too close to the problem at this point!
> >
> > We'd like to essentially run a virtualized vendor kernel to manage a
> > hardware device such as an SDIO wireless card passed through from the host,
> > running a mainline kernel. Network traffic would be routed from host to
> > guest over a virtio interface.
> >
> > Is it possible to use Greybus in this way, or am I misunderstanding the use
> > case of this subsystem?
>
> You could abuse greybus to do something like this, but that feels like a
> ton of extra work when there are already solutions for this type of
> thing today in Linux.  Why not just use some of the existing hardware
> pass-through solutions that are out there that allow virtual kernels to
> have access to hardware directly?  Why try to create yet-another way to
> do this?
>
> But hey, if you want to take the time to write such kernel code, all the
> best!  :)
>
> greg k-h

We've explored options such as VFIO for this use case. Although VFIO works great on PCs with hardware peripherals on an I/O bus such as PCI behind an IOMMU, we're looking to passthrough a platform device (SDIO wireless specifically, but potentially others as well) on an embedded system, such as a Raspberry Pi 4.
We've investigated vfio-platform intended for this, but based on a paper [1] describing the architecture and use cases, it seems to require specific hardware that implements DMA translation functionality, such as an IOMMU or SMMU, along with the appropriate driver. As we understand, a lot of the platforms we support don't have an IOMMU.

The kernel docs [2] describe the programming interface of devices as generally composed of I/O access, interrupts, and DMA.

Devices are the main target of any I/O driver.  Devices typically
create a programming interface made up of I/O access, interrupts,
and DMA.  Without going into the details of each of these, DMA is
by far the most critical aspect for maintaining a secure environment
as allowing a device read-write access to system memory imposes the
greatest risk to the overall system integrity.

This seems to explain the need for an IOMMU to passthrough a device to a virtualized guest, as any DMA done by a device would need guest physical-addresses translated to host-physical addresses.
However, we don't know for certain if the driver for our wireless adapter (mwifiex) uses DMA. Grepping the source shows references to DMA, but the fact that SDIO devices can be connected over a USB bridge seems to indicate it either doesn't, or we're not completely understanding.

We really don't know how feasible this idea is given our hardware constraints. Greybus may very likely be solving an entirely different issue, but it seemed to have enough overlap to be worth investigating. We're looking to understand if this is possible given our hardware constraints, or if we're barking up the wrong tree.

[1]: http://www.fp7-save.eu/papers/EUC2014B.pdf
[2]: https://www.kernel.org/doc/Documentation/driver-api/vfio.rst

Cheers, Kyle
_______________________________________________
greybus-dev mailing list
greybus-dev@xxxxxxxxxxxxxxxx
https://lists.linaro.org/mailman/listinfo/greybus-dev

[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite News]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux