Design session "virtio"

Design session "virtio"

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

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.


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Design session "virtio"

[Jan Beulich]

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