Re: Design session "virtio"

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.09.2022 16:03, Marek Marczykowski-Górecki wrote:
> Some sparse notes from the design session:
> 
> Passing backend domid ideas:
>  - via xenstore: good - can be done now; bad - requires xenstore even if
>    only virtio devices are used
>  - extend generic part of virtio spec: takes time, but otherwise
>    preferred
> 
> New "config" virtio device - for configuring backends
> 
> Hotplug:
>  - ACPI (for HVM at least)
>  - xenstore
> 
> 
> ACTION: Start the virtio spec change.
> 
> In the meantime, use xenstore(?)
> 
> qemu parameters are device-specific - adding backend id needs to be done for 
> every device type - both at qemu side, and libxl side
> 
> Device endpoint ID are currently allocated by qemu - for driver domains that 
> needs to be moved to the toolstack, to reserve space for devices running in 
> other backends.

Thanks for the separate notes, which are certainly helpful on top of
the ones I took. Plus I'll admit I was struggling some with typing and
listening at the same time, so I surely missed pieces (besides
likely also having screwed up here and there). Corrections and alike
appreciated ...

Jürgen  - working: frontend/backend but no connecting
        - prototype using device tree
        - generic solution needed
        - ACPI (on x86 at least)? DT (dynamic)? Xenstore?
        - for frontends: limited but generic xs entries (central driver)
Marek   - Isn't there a virtio mechansim for figuring domid?
Jürgen  - would need extending virtio, also for hotplug
        - ACPI (for hotplug) not an option for PV guests
George  - concerns regarding the use of Xenstore
        - at least for static configs it would be nice to do without
Jürgen  - option: new virtio device type for passing config information
Marek   - Use PCI IDs or alike?
Jürgen  - potentially risky going forward (compatibility-wise)
        - (excurse to some KVM side aspects, which might also need e.g. such
          a config device for certain purposes)
George  - Is there a config device already which we could extend?
Jürgen  - No, new type needed.
Roger   - vPCI usable (for its config space)?
Jürgen  - needs extending the virtio spec, preferably for all devices to
          represent data consistently (which may take long)
Roger   - Use VPD?
Jürgen  - still in (global) config space, hence needs specifying
George  - Transitory alternative until virtio spec was updated?
Jürgen  - backend (ad ioreq server) params perhaps best over Xenstore
        - if PV, ioreq server would need hooking up (if to be used)
George  - PV requiring Xenstore?
Jürgen  - alternatives are (in theory) possible
        - Result: Aim at virtio spec change plus introduce config device
        - Intermediate: Xenstore?
Anthony - Prototype?
Jürgen  - xl/libxl changes needed in addition
George  - 1) dom0-only + all grants (global), 2) xenstore (which would
          want to continue to work, once 3) config device is there)
Anthony - allocation of PCI IDs currently in qemu, want to move to tools
Marek   - How to launch backend in drvdom?
Jürgen  - one config device per backend domain

Jan