On 14.12.21 18:44, Oleksandr wrote: > > On 14.12.21 18:03, Anthony PERARD wrote: > > Hi Anthony > > >> On Wed, Dec 08, 2021 at 06:59:43PM +0200, Oleksandr Tyshchenko wrote: >>> From: Oleksandr Tyshchenko >>> >>> This patch adds basic support for configuring and assisting virtio-disk >>> backend (emualator) which is intended to run out of Qemu and could be >>> run in any domain. >>> Although the Virtio block device is quite different from traditional >>> Xen PV block device (vbd) from the toolstack point of view: >>>   - as the frontend is virtio-blk which is not a Xenbus driver, nothing >>>     written to Xenstore are fetched by the frontend (the vdev is not >>>     passed to the frontend) >>>   - the ring-ref/event-channel are not used for the backend<->frontend >>>     communication, the proposed IPC for Virtio is IOREQ/DM >>> it is still a "block device" and ought to be integrated in existing >>> "disk" handling. So, re-use (and adapt) "disk" parsing/configuration >>> logic to deal with Virtio devices as well. >> How backend are intended to be created? Is there something listening on >> xenstore? >> >> You mention QEMU as been the backend, do you intend to have QEMU >> listening on xenstore to create a virtio backend? Or maybe it is on the >> command line? There is QMP as well, but it's probably a lot more >> complicated as I think libxl needs refactoring for that. > > > No, QEMU is not involved there. The backend is a standalone application, > it is launched from the command line. The backend reads the Xenstore to get > the configuration and to detect when guest with the frontend is > created/destroyed. I think this should be reflected somehow in the configuration, as I expect qemu might gain this functionality in the future. I'm wondering whether we shouldn't split the backend from the protocol (or specification?). Something like "protocol=virtio" (default would be e.g. "xen") and then you could add "backend=external" for your use case? We could later expand that to "backend=qemu" or "backend=". Juergen