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

Re: [Xen-devel] [PATCH v3 02/17] Document ioemu Linux stubdomain protocol



On Thu, Feb 21, 2019 at 05:31:54PM +0000, Wei Liu wrote:
> On Thu, Feb 21, 2019 at 06:08:22PM +0100, Marek Marczykowski-Górecki wrote:
> > On Thu, Feb 21, 2019 at 03:39:25PM +0000, Wei Liu wrote:
> > > On Mon, Jan 28, 2019 at 10:30:19PM +0100, Marek Marczykowski-Górecki 
> > > wrote:
> > > > Add documentation for upcoming Linux stubdomain for qemu-upstream.
> > > > 
> > > > Signed-off-by: Marek Marczykowski-Górecki 
> > > > <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> > > > ---
> > > >  docs/misc/stubdom.txt | 50 
> > > > ++++++++++++++++++++++++++++++++++++++++++++-
> > > >  1 file changed, 50 insertions(+)
> > > > 
> > > > diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
> > > > index 4c524f2..9c94c6b 100644
> > > > --- a/docs/misc/stubdom.txt
> > > > +++ b/docs/misc/stubdom.txt
> > > > @@ -75,6 +75,56 @@ Defined commands:
> > > >     - "running" - success
> > > >  
> > > >  
> > > > +Toolstack to Linux ioemu stubdomain protocol
> > > > +--------------------------------------------
> > > > +
> > > > +This section describe communication protocol between toolstack and
> > > > +qemu-upstream running in Linux stubdomain. The protocol include
> > > > +expectations of both stubdomain, and qemu.
> > > > +
> > > > +Setup (done by toolstack, expected by stubdomain):
> > > > + - Block devices for target domain are connected as PV disks to 
> > > > stubdomain,
> > > > +   according to configuration order, starting with xvda
> > > > + - Network devices for target domain are connected as PV nics to 
> > > > stubdomain,
> > > > +   according to configuration order, starting with 0
> > > > + - [not implemented] if graphics output is expected, VFB and VKB 
> > > > devices are set for stubdomain
> > > > +   (its backend is responsible for exposing them using appropriate 
> > > > protocol
> > > > +   like VNC or Spice)
> > > > + - other target domain's devices are not connected at this point to 
> > > > stubdomain
> > > > +   (may be hot-plugged later)
> > > > + - QEMU command line is stored in
> > > > +   /vm/<target-uuid>/image/dmargs xenstore dir, each argument as 
> > > > separate key
> > > > +   in form /vm/<target-uuid>/image/dmargs/NNN, where NNN is 0-padded 
> > > > argument
> > > > +   number
> > > > + - target domain id is stored in /local/domain/<stubdom-id>/target 
> > > > xenstore path
> > > > +?? - bios type is stored in /local/domain/<target-id>/hvmloader/bios
> > > 
> > > Since you're defining a new protocol here, you have the liberty to
> > > eliminate this uncertainty, unless for some reason you want it to be
> > > compatible with the old stubdom?
> > 
> > I'm not sure who access this xenstore key, since I haven't found how is
> > it used in minios based stubdomain. Is it used by qemu?
> 
> It is read by hvmloader afaict.

Ah, in that case I think it should be removed from this (and minios)
spec, because it is irrelevant to stubdomain.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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