[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Oleksandr <olekstysh@xxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 20 Jul 2020 13:09:50 +0200
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Oleksandr Andrushchenko <andr2000@xxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Artem Mygaiev <joculator@xxxxxxxxx>
  • Delivery-date: Mon, 20 Jul 2020 11:10:26 +0000
  • Ironport-sdr: d/9RX8s/l3kWpPI01lNkPjuqD1aCI7h9a+pqnZQ6piT5cn3wv5f75X4vtxfd2b9ILqf4TEcWTA GR4Cs59sV7u/5O64zLToBz8IjvueaLL7j8JL5Nvsk/lqmdnDAbhDh/uVrxZz4ZvcNjqBNvKBCX NkjyUruM3YGVy1QzqcxvNBk6ggOTWWRtFMGr1xJtOe3S1y0OnYif5sv9GRdpRqBAAXJQ2xZCNY NhyIRm1BLWJOpxioMDUn/5Gj9rhtP5KiQAdOcCpAlW07CpV5aPOXgfxbA+3t6CWzgyUWu6zkjf Z3c=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.