Re: [Xen-devel] xm dmesg and performance on serial port

[Mark A. W. <mar...@cl...>]

> It is not circular or the circular mechanism might have been broken. The

No, it's not circular by design.

> buffer just stopped after a certain limit. The code in "console.c" does
> not seems to be circular either. And the command with "xm dmesg -c"
> doesn't seem to exist either.

xm dmesg [-c|--clear] should now work if you pull the unstable repo (or wait a 
little for it to arrive in the stable repo).

> xentrace seems to be used for debugging purpose. I am actually doing a
> security project using Xen. On a particular event that happens in the
> one of the domain, detected by a module in XEN. I'd like to report it or
> log it. I am trying to find the best way to do this.

Yes, the trace buffer is aimed at debugging timing-sensitive problems but it 
may still suit your needs, or at least provide a starting point.

> Let me know if I'm
> wrong. Isn't the "event_channel" is the communication channel from XEN
> to a domain.

Event channels are Xen's equivalent to interrupts in normal hardware.  Event 
channels may be between Xen and a domain or between a pair of domains.  
Events send on these are basically like interrupts, i.e. they just mean "look 
at this!", signalling that some event has just occurred.  They don't actually 
transfer data associated with an event.

> If I want to get XEN buffer messages (I guess it has to be
> in shared pages with the domain) to privilege domain 0, and flag the
> domain to check if there's something in the buffer. And get a handler in
> domain 0 to consume the buffer. I think this would have much less
> performance effect. Is there any interface existed that I can use for
> this? Or I'll just have to built it on top of event_channel.

You've got the right idea.  This is basically what the xentrace / trace buffer 
stuff does, so you might want to look at xen/common/trace.c and 
tools/xentrace/xentrace.c for the details of how this stuff is done.  The 
trace buffer doesn't actually use an event channel, it just polls 
periodically but this seems to work OK for our applications.

It would be possible to add a pseudo-device in dom0, which you could just read 
the trace data out of, with the reading process woken up when new data 
arrives (as signalled to dom0 by a suitable event channel).

HTH,
Mark