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. > the support/information it needs and xenstore is not welcome then I would be > absolutely ok to consider using other solution. > > I propose to get back to that discussion after I prepare and send out the > proper IOREQ series. Sure, that's fine. Roger.
