Xen devel - May 2005 - RE: Domain controller guidelines

Sir

Then i have question ::
In what situation one should use FE/BE+XEND  interface
and  when should i consider using xentrace.c/trace.c  like  mechanism.

Will new XEND  work with existing 2.0.5 and 2.6.10 kernel?


thanks for all your answers.
-vikas


-----Original Message-----
From: Mark Williamson [mailto:mark.williamson@cl.cam.ac.uk]
Sent: Tue 5/3/2005 3:36 PM
To: Aggarwal, Vikas (OFT)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Doamin controller guidelines
 
> Can we bypass XEND  domain controller. ------------
> Am I wrong in understanding xentrace.c &  common/trace.c  while I think
> dom0 is tracing dom1 and control/data flows without going through XEND, it
> is just using SHARE_PFN_WITH_DOMAIN?
xentrace doesn''t go through Xend.  However, Xentrace uses a ring buffer
that
is shared between dom0 and Xen - it does not communicate with other domains.

If you really want to bypass Xend, you''ll need a different interdomain 
transport for sending commands, shared memory addresses, etc. - you could use 
the virtual ethernet for this.

When the updated Xend is checked in, you may find it gets easier to hack on.

Cheers,
Mark
> The mechanism used in xentrace is different from blkif/netif as it appears
> by looking at the code. Why xentrace not required to use shared ring
> mechanism?
>
> I am asking these questions as xentrace seems to make my task easier if it
> can bypass XEND.
>
> These are naïve questions but I am very much unfamiliar with underlying
> code.
>
> -vikas
>
> -----Original Message-----
> From: maw48@hermes.cam.ac.uk [mailto:maw48@hermes.cam.ac.uk] On Behalf Of
> Mark Williamson Sent: Tuesday, May 03, 2005 11:13 AM
> To: Aggarwal, Vikas (OFT)
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Doamin controller guidelines
>
> > We have a kernel debugging driver, controlled via IOCTL. We need to
port
> > our tool to Xen so that we can trace the guest kernels, control our
> > tracer and collect trace data from the host kernel in domain 0.
>
> Cool!
>
> > 1- Send control command to our tracer : control data from domain0 to
the
> > kernel of domain1 for example start/stop tracing.
>
> Sounds like it could come as a control message from Xend, after a request
> from the xm tool?  Alternatively, you could have the backend prod the
> frontend for start / stop events.
>
> > 2 Send the trace data generated by the guest kernel to the host
> > kernel.(shared ring ? , I am using 2.0.5)
>
> Sounds like good use for a shared ring, possibly with the backend directly
> mapping memory buffers in the guest to copy data out.
>
> > Right  now I am adding support into python XEND, I already have some
> > basic frame work in place for my FE/BE.
> > I am unfamiliar with python but more than that the logic in XEND. I
> > created my own trace_debug.py  based on blkif.py.
>
> Sounds good.
>
> > But I don''t understand what to do corresponding to Blkctl.py.
I am
> > really not sure what to put into my trace_debug_ctl.py corresponding
to
> > Blkctl.py. I believe its because I don''t understand what is
expected
> > inside XEND.  Please pour some light on this area.
>
> You won''t need one: Netctl and Blkctl are only needed because they
call
> shell scripts that do some outside configuration of the network / block
> devices (adding network devices to bridges, running losetup for block
> device files). Since your "device" is entirely virtual, you
probably don''t
> need a trace_debug_ctl.py at all.
>
> HTH,
> Mark
>
> > Thanks
> > -vikas
> >
> > -----Original Message-----
> > From: maw48@hermes.cam.ac.uk [mailto:maw48@hermes.cam.ac.uk] On Behalf
> > Of Mark Williamson
> > Sent: Sunday, May 01, 2005 8:16 PM
> > To: xen-devel@lists.xensource.com
> > Cc: Aggarwal, Vikas (OFT)
> > Subject: Re: [Xen-devel] Doamin controller guidelines
> >
> > >   Kindly provide me some basic informnation on how to enahnce
> > >   the XEN domain controller code for my newly ported
> >
> > front-end/back-end
> >
> > > driver. I trying to dig into mailing lists but could not find
> >
> > something for
> >
> > > domain controller enhancement (2.0.5 XEN) .  Though i found
doc/misc/
> >
> > very
> >
> > > helpful for FE/BE  but nothing there to help in domain
controller.
> >
> > Look in: tools/python/xen/xend/server/{blk,net}if.py
> >
> > These implement the domain-controller end of the protocol.  Other
> > relevant
> > code is in controller.py and channel.py (also in that directory).
> > Currently
> > this code uses the Deferred objects in the Twisted Matrix framework to
> > implement this in a non-blocking way.  If you ever look at supporting
> > unstable / 3.0, you should be aware a Xend rewrite is in progress for
> > the
> > unstable tree that will eliminate use of Twisted and use language
level
> > threads - allowing you to block instead of using Deferreds.
> >
> > If you need configuration details in the domain config file,
you''ll also
> > need
> > to modify the xm tool and various other parts of Xend.  You might find
> > tracing through how block or net configuration works a helpful
exercise
> > is
> > this case.
> >
> > I''m personally curious what your front / back end is ;-) 
Will we get to
> > see
> > it some time?
> >
> > HTH,
> > Mark

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> In what situation one should use FE/BE+XEND  interface
> and  when should i consider using xentrace.c/trace.c  like  mechanism.
FE / BE interfaces are used for interdomain communication - these use a shared 
memory page to pass descriptors from the FE to the BE, describing the machine 
address where data is located.  The BE then maps these machine addresses and 
grabs the data out of them.

Xend is only there as a means to set up the initial shared memory page. 
It''s
entirely possible to pass this address in a different fashion - for instance, 
over the network (slightly clunky) or as a module parameter (very clunky).

The Xentrace-style mechanism is really suitable only for Xen <-> domain 
communication.  I believe the Xenoprof code uses a conceptually similar 
mechanism, although I haven''t look at that code yet.
> Will new XEND  work with existing 2.0.5 and 2.6.10 kernel?
Probably not.  A rewrite of Xend is a major change and as such will probably 
go into the unstable tree (just in case :-)).
> thanks for all your answers.
No problem!

You''re probably on the right track by basing your control code on the
blkif
code.  It can take a while to get your head around and debug but it''s
not too
bad once you get the hang of it.

Cheers,
Mark
> -vikas
>
>
> -----Original Message-----
> From: Mark Williamson [mailto:mark.williamson@cl.cam.ac.uk]
> Sent: Tue 5/3/2005 3:36 PM
> To: Aggarwal, Vikas (OFT)
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Doamin controller guidelines
>
> > Can we bypass XEND  domain controller. ------------
> > Am I wrong in understanding xentrace.c &  common/trace.c  while I
think
> > dom0 is tracing dom1 and control/data flows without going through
XEND,
> > it is just using SHARE_PFN_WITH_DOMAIN?
>
> xentrace doesn''t go through Xend.  However, Xentrace uses a ring
buffer
> that is shared between dom0 and Xen - it does not communicate with other
> domains.
>
> If you really want to bypass Xend, you''ll need a different
interdomain
> transport for sending commands, shared memory addresses, etc. - you could
> use the virtual ethernet for this.
>
> When the updated Xend is checked in, you may find it gets easier to hack
> on.
>
> Cheers,
> Mark
>
> > The mechanism used in xentrace is different from blkif/netif as it
> > appears by looking at the code. Why xentrace not required to use
shared
> > ring mechanism?
> >
> > I am asking these questions as xentrace seems to make my task easier
if
> > it can bypass XEND.
> >
> > These are naïve questions but I am very much unfamiliar with
underlying
> > code.
> >
> > -vikas
> >
> > -----Original Message-----
> > From: maw48@hermes.cam.ac.uk [mailto:maw48@hermes.cam.ac.uk] On Behalf
Of
> > Mark Williamson Sent: Tuesday, May 03, 2005 11:13 AM
> > To: Aggarwal, Vikas (OFT)
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] Doamin controller guidelines
> >
> > > We have a kernel debugging driver, controlled via IOCTL. We need
to
> > > port our tool to Xen so that we can trace the guest kernels,
control
> > > our tracer and collect trace data from the host kernel in domain
0.
> >
> > Cool!
> >
> > > 1- Send control command to our tracer : control data from domain0
to
> > > the kernel of domain1 for example start/stop tracing.
> >
> > Sounds like it could come as a control message from Xend, after a
request
> > from the xm tool?  Alternatively, you could have the backend prod the
> > frontend for start / stop events.
> >
> > > 2 Send the trace data generated by the guest kernel to the host
> > > kernel.(shared ring ? , I am using 2.0.5)
> >
> > Sounds like good use for a shared ring, possibly with the backend
> > directly mapping memory buffers in the guest to copy data out.
> >
> > > Right  now I am adding support into python XEND, I already have
some
> > > basic frame work in place for my FE/BE.
> > > I am unfamiliar with python but more than that the logic in XEND.
I
> > > created my own trace_debug.py  based on blkif.py.
> >
> > Sounds good.
> >
> > > But I don''t understand what to do corresponding to
Blkctl.py.  I am
> > > really not sure what to put into my trace_debug_ctl.py
corresponding to
> > > Blkctl.py. I believe its because I don''t understand what
is expected
> > > inside XEND.  Please pour some light on this area.
> >
> > You won''t need one: Netctl and Blkctl are only needed because
they call
> > shell scripts that do some outside configuration of the network /
block
> > devices (adding network devices to bridges, running losetup for block
> > device files). Since your "device" is entirely virtual, you
probably
> > don''t need a trace_debug_ctl.py at all.
> >
> > HTH,
> > Mark
> >
> > > Thanks
> > > -vikas
> > >
> > > -----Original Message-----
> > > From: maw48@hermes.cam.ac.uk [mailto:maw48@hermes.cam.ac.uk] On
Behalf
> > > Of Mark Williamson
> > > Sent: Sunday, May 01, 2005 8:16 PM
> > > To: xen-devel@lists.xensource.com
> > > Cc: Aggarwal, Vikas (OFT)
> > > Subject: Re: [Xen-devel] Doamin controller guidelines
> > >
> > > >   Kindly provide me some basic informnation on how to
enahnce
> > > >   the XEN domain controller code for my newly ported
> > >
> > > front-end/back-end
> > >
> > > > driver. I trying to dig into mailing lists but could not
find
> > >
> > > something for
> > >
> > > > domain controller enhancement (2.0.5 XEN) .  Though i found
doc/misc/
> > >
> > > very
> > >
> > > > helpful for FE/BE  but nothing there to help in domain
controller.
> > >
> > > Look in: tools/python/xen/xend/server/{blk,net}if.py
> > >
> > > These implement the domain-controller end of the protocol.  Other
> > > relevant
> > > code is in controller.py and channel.py (also in that directory).
> > > Currently
> > > this code uses the Deferred objects in the Twisted Matrix
framework to
> > > implement this in a non-blocking way.  If you ever look at
supporting
> > > unstable / 3.0, you should be aware a Xend rewrite is in progress
for
> > > the
> > > unstable tree that will eliminate use of Twisted and use language
level
> > > threads - allowing you to block instead of using Deferreds.
> > >
> > > If you need configuration details in the domain config file,
you''ll
> > > also need
> > > to modify the xm tool and various other parts of Xend.  You might
find
> > > tracing through how block or net configuration works a helpful
exercise
> > > is
> > > this case.
> > >
> > > I''m personally curious what your front / back end is ;-)
Will we get
> > > to see
> > > it some time?
> > >
> > > HTH,
> > > Mark
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel