> 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@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
|
Home