RE: [Xen-devel] Domain controller guidelines

["Aggarwal, Vikas \(OFT\)" <Vikas.Aggarwal@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxx]
Sent: Tue 5/3/2005 3:36 PM
To: Aggarwal, Vikas (OFT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxx [mailto:maw48@xxxxxxxxxxxxxxxx] On Behalf Of
> Mark Williamson Sent: Tuesday, May 03, 2005 11:13 AM
> To: Aggarwal, Vikas (OFT)
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxx [mailto:maw48@xxxxxxxxxxxxxxxx] On Behalf
> > Of Mark Williamson
> > Sent: Sunday, May 01, 2005 8:16 PM
> > To: xen-devel@xxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel