Re: Metadata and signalling channels for Zephyr virtio-backends on Xen

[Vincent Guittot <vincent.guittot@xxxxxxxxxx>]

Hi All,

Sorry for the late reply but I was off last week. I will go through
the thread and try to answer open point

On Mon, 7 Feb 2022 at 11:56, Alex Bennée <alex.bennee@xxxxxxxxxx> wrote:
>
>
> Hi Stefano,
>
> Vincent gave an update on his virtio-scmi work at the last Stratos sync
> call and the discussion moved onto next steps. Currently the demo setup
> is intermediated by a double-ended vhost-user daemon running on the
> devbox acting as a go between a number of QEMU instances representing
> the front and back-ends. You can view the architecture with Vincents
> diagram here:
>
>   
> https://docs.google.com/drawings/d/1YSuJUSjEdTi2oEUq4oG4A9pBKSEJTAp6hhcHKKhmYHs/edit?usp=sharing
>
> The key virtq handling is done over the special carve outs of shared
> memory between the front end and guest. However the signalling is
> currently over a virtio device on the backend. This is useful for the
> PoC but obviously in a real system we don't have a hidden POSIX system
> acting as a go between not to mention the additional latency it causes
> with all those context switches.
>
> I was hoping we could get some more of the Xen experts to the next
> Stratos sync (17th Feb) to go over approaches for a properly hosted on
> Xen approach. From my recollection (Vincent please correct me if I'm
> wrong) of last week the issues that need solving are:
>
>  * How to handle configuration steps as FE guests come up
>
> The SCMI server will be a long running persistent backend because it is
> managing real HW resources. However the guests may be ephemeral (or just
> restarted) so we can't just hard-code everything in a DTB. While the
> virtio-negotiation in the config space covers most things we still need
> information like where in the guests address space the shared memory
> lives and at what offset into that the queues are created. As far as I'm
> aware the canonical source of domain information is XenStore
> (https://wiki.xenproject.org/wiki/XenStore) but this relies on a Dom0
> type approach. Is there an alternative for dom0less systems or do we
> need a dom0-light approach, for example using STR-21 (Ensure Zephyr can
> run cleanly as a Dom0 guest) providing just enough services for FE's to
> register metadata and BE's to read it?
>
>  * How to handle mapping of memory
>
> AIUI the Xen model is the FE guest explicitly makes grant table requests
> to expose portions of it's memory to other domains. Can the BE query the
> hypervisor itself to discover the available grants or does it require
> coordination with Dom0/XenStore for that information to be available to
> the BE domain?

I have noticed that it was possible to share memory between VMs in the
VM config file which seem to be quite similar to what is done with
qemu to share memory object between VMs
>
>  * How to handle signalling
>
> I guess this requires a minimal implementation of the IOREQ calls for
> Zephyr so we can register the handler in the backend? Does the IOREQ API
> allow for a IPI style notifications using the global GIC IRQs?
>
> Forgive the incomplete notes from the Stratos sync, I was trying to type
> while participating in the discussion so hopefully this email captures
> what was missed:
>
>   
> https://linaro.atlassian.net/wiki/spaces/STR/pages/28682518685/2022-02-03+Project+Stratos+Sync+Meeting+Notes
>
> Vincent, anything to add?

I want to use an interface that is not tied to an hypervisor that's
why i have reused the virtio_mmio to emulate the device side where the
backend can get virtqueue description

>
> --
> Alex Bennée