Re: [Xen-devel] wrong vmexit size in xenalyze

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

A lot of times not only the size of the record changes across
releases, but the ordering of the content.  Checking the sizes (and
also things like checking for impossible values; e.g., RIP values that
can't actually be generated on real hardware) is meant so that a file
change will probably cause a meaningful warning immediately, rather
than just having strange results and me spending half a day trying to
figure out what's causing unexpected behavior, only to find that it
was a change in the trace file layout I didn't catch.

We can easily set it up so that these kinds of sanity checks don't
stop xenalyze from processing -- in fact, the basic infrastructure is
already there for classifying errors.  I'll post something next week
that classifies unexpected sizes differently and allows Xen to keep
processing the records.

Olaf: BTW, the off-by-one count won't result in short records; the
trace code will copy as many bytes as it's told into the trace buffer;
so the integrity of the record metadata is maintained. (Technically, I
suppose some information from the stack could leak; probably not a big
issue, given that only root in dom0 can take traces.)

 -George


On Fri, Nov 19, 2010 at 10:07 AM, Olaf Hering <olaf@xxxxxxxxx> wrote:
> On Fri, Nov 19, George Dunlap wrote:
>
>> If you have a better idea, I'm open to it.  A bit more discipline --
>> doing an audit of the tracing after the feature freeze before each
>> release -- would be helpful; some automated testing would be even
>> more helpful.
>
> I think the extra u32 is just padding and can be ignored.
> Whats the purpose of the ->extra_bytes checks? If its just a data
> integrity check, it can be removed because reading past the end of the
> record data should not harm. Maybe limit the loops which iterate
> ->extra_bytes to 7 because more doesnt fit in a trace record.
>
>
> Olaf
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel