[HVWS] Sensor access from virtual machines

Anup Patel anup at brainfault.org
Wed Sep 19 09:21:52 EDT 2018


On Wed, Sep 19, 2018 at 2:43 PM Gunnar Andersson <gandersson at genivi.org> wrote:
>
>
> Artem, and all,
>
> I received from Artem some early proposal of a protocol for communicating
> with "virtual sensors"  (Thanks!)  We should look at it together soon.
>
> But I wanted first to open some questions here and ask if they make sense to
> you.
>
> This generic protocol definition makes sense to me for a lot of sensors that
> will provide data measurement values of different kinds.  (VIRTIO seems to
> do this quite well also - to generalize the concepts first and provide a
> data transfer principle that can be applied to many different detailed
> hardware, instead of being specific for each.)

I agree, VIRTIO device for sensors looks very promising here.

>
> But I noticed when I was contemplating this I was thinking more low-level...
> How a "sensor" is actually attached to the hardware itself, and then how
> does access to that hardware become virtualized?  Could there be, and should
> there be a low-level API to it from the VM?

If we show VIRTIO sensor device to Guest/VM then VIRTIO backend in
hypervisor will need to have a mechanism to share actual HW sensor data
between multiple Guests/VMs.

>
> What if you drop down to the level of simple microcontrollers with digital
> I/O pins.  Leaving aside for now that small microcontrollers don't usually
> run virtual machines, but the same things turn up also on larger SoCs.  SoCs
> might at least provide some direct I/O pins.
>
> So, if the sensor is not intelligent enough to provide some kind of network
> or serial link, then might it in certain cases it might be as simple as
> digital pin I/O?  Is that actual access hidden totally by the Hypervisor and
> providing the data through a protocol like the one you propose or is there
> interest in a more "direct" access?

Yes, very simplistic sensor available over I/O pins can be abstracted by
Hypervisor.

Let's assume that these are GPIO pins then Guest/VM can have its own
virtual GPIO controller with virtual GPIO pins. The HW GPIO pins can be
mapped to virtual GPIO pins of a Guest/VM. In other words, whenever
Guest/VM reads virtual GPIO pin X it can give state of HW GPIO pin Y.
In fact, this is how GPIO virtualization is done in Xvisor. Most important
thing here is that what kind of virtual GPIO controller will be emulated
for Guest/VM.

Another approach is to give direct (i.e. pass-through) access of all sensor
devices (and GPIO pins) to a particular Guest/VM access. This particular
Guest/VM will provide sensor data to other Guests/VMs in-form of some
inter-VM service.

>
> Transformed into a concrete question: Is there a virtualization standard for
> pin I/O, perhaps mirroring the Linux PINCTRL subsystem?  Maybe I'm
> overthinking this and such I/O will simply be set up as "passthrough" - but
> that's also something that needs then to be decided, and it still needs a
> defined method and API, right?

No, there is no virtualization standard for GPIO (or I/O pin) virtualization but
this is not a big problem because we can always emulate pseudo-GPIO
controller compliant to "DT-based Generic memory-mapped GPIO controller".
Linux already has "Generic driver for memory-mapped GPIO controllers".
(Refer, <linux_source>/drivers/gpio/gpio-mmio.c)

For PINCTRL, PINMUX, CLK, and REGULATOR it's responsibility of
hypervisor to ensure proper configuration before doing device pass-through.
For most cases, device drivers running inside Guest/VMs will not require
access to PINCTRL, PINMUX, CLK, and REGULAGTOR.

Although things might become tricky, if a device driver running inside
Guest/VM requires changing input CLK and/or voltage REGULATOR for
such devices we better access them in hypervisor (instead of Guest/VM
having direct access). We can also emulate dummy CLK and/or REGULATOR
for such device but I am not sure how safe this would be.

>
> Other typical I/O on microcontrollers or SoCs would be things like PWM
> (output) ports, and A/D (input) or D/A (output) conversion.  What do such
> hardware features lead to if we are thinking about the virtual interface to
> them?   Do those need to be handled?
>

We need an virtual interface for PWM ports, A/D (input), and D/A (output)
only if these are to be shared among Guests/VMs. If no sharing is required
then we better do direct (or pass-through) access.

Regards,
Anup



More information about the genivi-projects mailing list