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

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?

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


 


Rackspace

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