Re: Virtio in Xen on Arm (based on IOREQ concept)

[Oleksandr <olekstysh@xxxxxxxxx>]

On 20.07.20 23:40, Stefano Stabellini wrote:

Hello Stefano

> On Mon, 20 Jul 2020, Roger Pau Monné wrote:
> > On Mon, Jul 20, 2020 at 01:56:51PM +0300, Oleksandr wrote:
> > > On 20.07.20 12:17, Roger Pau Monné wrote:
> > > > On Fri, Jul 17, 2020 at 09:34:14PM +0300, Oleksandr wrote:
> > > > > On 17.07.20 18:00, Roger Pau Monné wrote:
> > > > > > On Fri, Jul 17, 2020 at 05:11:02PM +0300, Oleksandr Tyshchenko wrote:
> > > > > The other reasons are:
> > > > >
> > > > > 1. Automation. With current backend implementation we don't need to pause
> > > > > guest right after creating it, then go to the driver domain and spawn
> > > > > backend and
> > > > >
> > > > > after that go back to the dom0 and unpause the guest.
> > > > xl devd should be capable of handling this for you on the driver
> > > > domain.
> > > >
> > > > > 2. Ability to detect when guest with involved frontend has gone away and
> > > > > properly release resource (guest destroy/reboot).
> > > > >
> > > > > 3. Ability to (re)connect to the newly created guest with involved frontend
> > > > > (guest create/reboot).
> > > > >
> > > > > 4. What is more that having Xenstore support the backend is able to detect
> > > > > the dom_id it runs into and the guest dom_id, there is no need pass them via
> > > > > command line.
> > > > >
> > > > >
> > > > > I will be happy to explain in details after publishing backend code).
> > > > As I'm not the one doing the work I certainly won't stop you from
> > > > using xenstore on the backend. I would certainly prefer if the backend
> > > > gets all the information it needs from the command line so that the
> > > > configuration data is completely agnostic to the transport layer used
> > > > to convey it.
> > > >
> > > > Thanks, Roger.
> > > Thank you for pointing another possible way. I feel I need to investigate
> > > what is the "xl devd" (+ Argo?) and how it works. If it is able to provide
> > > backend with
> > That's what x86 at least uses to manage backends on driver domains: xl
> > devd will for example launch the QEMU instance required to handle a
> > Xen PV disk backend in user-space.
> >
> > Note that there's currently no support for Argo or any communication
> > channel different than xenstore, but I think it would be cleaner to
> > place the fetching of data from xenstore in xl devd and just pass
> > those as command line arguments to the VirtIO backend if possible. I
> > would prefer the VirtIO backend to be fully decoupled from xenstore.
> >
> > Note that for a backend running on dom0 there would be no need to
> > pass any data on xenstore, as the backend would be launched directly
> > from xl with the appropriate command line arguments.
> If I can paraphrase Roger's point, I think we all agree that xenstore is
> very convenient to use and great to get something up and running
> quickly. But it has several limitations, so it would be fantastic if we
> could kill two birds with one stone and find a way to deploy the system
> without xenstore, given that with virtio it is not actually needed if not
> for very limited initial configurations. It would certainly be a big
> win. However, it is fair to say that the xenstore alternative, whatever
> that might be, needs work.
Well, why actually not?

For example, the idea "to place the fetching of data from xenstore in xl 
devd and just pass
those as command line arguments to the VirtIO backend if possible" 
sounds fine to me. But this needs an additional investigation.
--
Regards,

Oleksandr Tyshchenko