On 12/10/20 2:20 PM, Arnd Bergmann via Stratos-dev wrote:
On Tue, Dec 8, 2020 at 8:12 AM Viresh Kumar via Stratos-dev stratos-dev@op-lists.linaro.org wrote:
Hi Guys,
There are offline discussions going on to assess the possibility of re-using the Linux kernel Greybus framework for Virtio [1] use case, where we can control some of the controllers on the back-end (Host), like SPI, I2C, GPIO, etc, from front-end (VM), using the already well defined Greybus specification [2].
The Greybus specification and kernel source was initially developed for Google's Project ARA [3], and the source code was merged into mainline kernel long time back (in drivers/greybus/ and drivers/staging/greybus/). You can find more information about how Greybus works in this LWN article [4].
Greybus broadly provides two distinct features:
Device discovery: at runtime, with the help of a manifest file (think of it like DT, though it has a different format). This helps the user of the hardware to identify the capabilities of the remote hardware, which it can use.
Remote control/operation: of the IPs present on the remote hardware, using firmware/OS independent operations, these are already well defined for a lot of device types and can be extended if required.
We wanted to share this over email to get some discussion going, so it can be discussed later on the call.
Alex Elder (Cc'd) is one of the Maintainers of the Greybus core in Linux Kernel and I worked on a wide variety of stuff and maintain some of it. Both of us worked in project ARA and would like to see Greybus being used in other applications and would like to contribute towards it.
I think the main capability this would add compared to having a simple virtio device per bus is that you can have a device that is composed of multiple back-ends, e.g. an i2c slave plus a set of GPIOs are tied together for one functionality, this is something we did not discuss in the call today. The downside is that for each remote device, we'd still need to add a binding and a driver to make use of it.
In fact, Greybus has the notion of a "bundle" of connections exactly for this purpose. So really, a device is represented by a bundle of one or more connections (CPorts). Each connection uses a protocol that is specific to a service it provides. Some services represent primitive hardware (like I2C or GPIO or UART). But for example the camera has one CPort representing management and another representing data from the camera.
Greybus drivers register with the Greybus core, and they provide a match table that defines what bundles (devices) should be associated with the driver when they are probed. The bundles and connections, etc. are defined in a module's manifest; for a bundle this includes its vendor id, product id, and class, which are used in matching it with a Greybus device driver.
So basically the manifest provides an encapsulated description of hardware functionality, and built into its design is a way to match that hardware with a (Greybus) driver. This could be adapted for other environments.
As an aside, let me highlight something: - Greybus manifest describes the hardware available in a module - A manifest describes one or more Greybus bundles, each of which represents a device - Greybus device driver has a way to identify which Greybus bundle it should be bound with - A Greybus bundle (device) is implemented with multiple connections, each using a particular protocol All, some, or none of these might be what's really wanted here, but all are part of and possibly implied by the term "Greybus." This is why I ask for clarity and precision about what is really required.
Anyway the questions I have are more about whether using what Greybus as it exists now aligns well with this application. Does the Greybus manifest address what's required to provide virtualized access to real hardware via VirtIO? Does it limit what could be done? Does it provide functionality beyond what is needed? How is this better or worse than using Device Tree (for example)? Is there a more natural way for VirtIO to advertise available hardware?
To be clear, I'm not trying to discourage using Greybus here.
But as I said, I'm viewing things through a Greybus lens. I'm working to understand what the Stratos "model" looks like so I can bridge the divide in my mind between that and Greybus.
-Alex
The alternative is to use a device tree to describe these to the guest kernel at boot time. The advantage is that we only need a really simple drivers for each type of host controller (i2c, spi, ....), and describing the actual devices works just as before, using the existing DT bindings to pass bind the attached device to a driver and add auxiliary information with references to other devices (gpio, irq, device settings), at the cost of needing to configure them at boot time.
Arnd
On Thu, Dec 10, 2020 at 11:08 PM Alex Elder elder@linaro.org wrote:
On 12/10/20 2:20 PM, Arnd Bergmann via Stratos-dev wrote:
On Tue, Dec 8, 2020 at 8:12 AM Viresh Kumar via Stratos-dev stratos-dev@op-lists.linaro.org wrote:
I think the main capability this would add compared to having a simple virtio device per bus is that you can have a device that is composed of multiple back-ends, e.g. an i2c slave plus a set of GPIOs are tied together for one functionality, this is something we did not discuss in the call today. The downside is that for each remote device, we'd still need to add a binding and a driver to make use of it.
In fact, Greybus has the notion of a "bundle" of connections exactly for this purpose. So really, a device is represented by a bundle of one or more connections (CPorts). Each connection uses a protocol that is specific to a service it provides. Some services represent primitive hardware (like I2C or GPIO or UART). But for example the camera has one CPort representing management and another representing data from the camera.
Greybus drivers register with the Greybus core, and they provide a match table that defines what bundles (devices) should be associated with the driver when they are probed. The bundles and connections, etc. are defined in a module's manifest; for a bundle this includes its vendor id, product id, and class, which are used in matching it with a Greybus device driver.
So basically the manifest provides an encapsulated description of hardware functionality, and built into its design is a way to match that hardware with a (Greybus) driver. This could be adapted for other environments.
(we discussed this in person today, but I'll summarize what we talked about here)
The problem we get into though is once we try to make this work for arbitrary i2c or spi devices. The kernel has around 1400 such drivers, and usually we use a device tree description based on a unique string for every such device plus additional properties for things like gpio lines or out-of-band interrupts.
If we want to use greybus manifests in place of device trees, that means either needing to find a way to map DT properties into the manifest, or have the same data in another format for each device we might want to use behind greybus, and adapting the corresponding drivers to understand this additional format.
Using simple virtio based hosts for each bus type (i2c, spi, uart, ...) means we can use every existing driver with its normal DT bindings (or ACPI tables for those so inclined), but we lose the ability to hotplug those devices.
As an aside, let me highlight something:
- Greybus manifest describes the hardware available in a module
- A manifest describes one or more Greybus bundles, each of which represents a device
- Greybus device driver has a way to identify which Greybus bundle it should be bound with
- A Greybus bundle (device) is implemented with multiple connections, each using a particular protocol
All, some, or none of these might be what's really wanted here, but all are part of and possibly implied by the term "Greybus." This is why I ask for clarity and precision about what is really required.
Anyway the questions I have are more about whether using what Greybus as it exists now aligns well with this application. Does the Greybus manifest address what's required to provide virtualized access to real hardware via VirtIO? Does it limit what could be done?
One limitation I can think of is that the manifest might have problems describing connections to another device, for example you might have i2c connected display brightness settings and touchscreen input for a screen, but cannot describe which video device they represent because the display and gpu devices are not part of the same bundle but are separate virtio devices.
Does it provide functionality beyond what is needed? How is this better or worse than using Device Tree (for example)? Is there a more natural way for VirtIO to advertise available hardware?
To be clear, I'm not trying to discourage using Greybus here.
But as I said, I'm viewing things through a Greybus lens. I'm working to understand what the Stratos "model" looks like so I can bridge the divide in my mind between that and Greybus.
Arnd
On 16-12-20, 14:54, Arnd Bergmann wrote:
The problem we get into though is once we try to make this work for arbitrary i2c or spi devices. The kernel has around 1400 such drivers, and usually we use a device tree description based on a unique string for every such device plus additional properties for things like gpio lines or out-of-band interrupts.
If we want to use greybus manifests in place of device trees, that means either needing to find a way to map DT properties into the manifest, or have the same data in another format for each device we might want to use behind greybus, and adapting the corresponding drivers to understand this additional format.
I am a bit confused about this. I don't think we need to expose all that information over the manifest.
The SPI controller will be accessible by the host OS (lets say both host and guest run Linux), the host will give/pass a manifest to the guest and the guest will send simple commands like read/write to the host. The Guest doesn't need minute details of how the controller is getting programmed, which is the responsibility of the host side controller driver which will have all this information from the DT passed from bootloader anyway. And so the manifest shouldn't be required to have equivalent of all DT properties.
Isn't it ?
stratos-dev@op-lists.linaro.org
-
Alex Elder -
Arnd Bergmann -
Viresh Kumar