Re: [PATCH V6 1/2] libxl: Add support for Virtio disk configuration

From: Juergen Gross <jgross@suse.com>
To: Oleksandr <olekstysh@gmail.com>,
	Anthony PERARD <anthony.perard@citrix.com>
Cc: xen-devel@lists.xenproject.org,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Wei Liu <wl@xen.org>, George Dunlap <george.dunlap@citrix.com>,
	Nick Rosbrook <rosbrookn@ainfosec.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Bertrand Marquis <bertrand.marquis@arm.com>
Subject: Re: [PATCH V6 1/2] libxl: Add support for Virtio disk configuration
Date: Wed, 15 Dec 2021 07:08:13 +0100	[thread overview]
Message-ID: <4c89e55d-4bf1-506e-d620-4a0ff18ef308@suse.com> (raw)
In-Reply-To: <bce10079-abd6-c033-6273-ac0ea9f51668@gmail.com>

[-- Attachment #1.1.1: Type: text/plain, Size: 2158 bytes --]

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 <oleksandr_tyshchenko@epam.com>
>>>
>>> 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=<script-path>".

Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]