| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home