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

[Oleksandr <olekstysh@xxxxxxxxx>]

On 15.12.21 08:08, Juergen Gross wrote:

Hi Juergen

> 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@xxxxxxxx>
> > > >
> > > > 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 understand this and agree in general (however I am wondering whether 
this can be postponed until it is actually needed), but ...

> 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?
... I am afraid, I didn't get the idea. Are we speaking about the (new?) 
disk configuration options
here or these are not disk specific things at all and to be applicable 
for all possible backends?
If the former, then could the new backendtype simply do the job? For 
example, "backendtype=virtio_external" for our current use-case and 
"backendtype=virtio_qemu"
for the possible future use-cases? Could you please clarify the idea.


Thank you.



> We could later expand that to "backend=qemu" or "backend=<script-path>".
>
>
> Juergen
--
Regards,

Oleksandr Tyshchenko