WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Doamin controller guidelines

To: "Aggarwal, Vikas \(OFT\)" <Vikas.Aggarwal@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Doamin controller guidelines
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 3 May 2005 20:36:04 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 03 May 2005 20:13:26 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0BAE938A1E68534E928747B9B46A759A6CF13D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <0BAE938A1E68534E928747B9B46A759A6CF13D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8
> 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

<Prev in Thread] Current Thread [Next in Thread>