Mailing List Archive

[PATCH] enhance HVM xentrace
enhance HVM xentrace:
1) VMX xentrace data are store in current vcpu instead physical CPU.
2) Log PIO data in xentrace.

Signed-off-by: Xin Li <xin.b.li@intel.com>
Re: [PATCH] enhance HVM xentrace [ In reply to ]
On 3/11/06 04:10, "Li, Xin B" <xin.b.li@intel.com> wrote:

> enhance HVM xentrace:
> 1) VMX xentrace data are store in current vcpu instead physical CPU.
> 2) Log PIO data in xentrace.
>
> Signed-off-by: Xin Li <xin.b.li@intel.com>

I was wondering how useful these are at all. It's a bit random and
undocumented. If it's useful perhaps it should be extended into a generic
HVM mechanism and define some processor-agnostic enumerations for exit-code
reasons and so on.

-- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
RE: [PATCH] enhance HVM xentrace [ In reply to ]
>> enhance HVM xentrace:
>> 1) VMX xentrace data are store in current vcpu instead physical CPU.
>> 2) Log PIO data in xentrace.
>>
>> Signed-off-by: Xin Li <xin.b.li@intel.com>
>
>I was wondering how useful these are at all. It's a bit random and
>undocumented.

Two usages for us currently:
1) debug, for some specific bugs it's very useful, for example, the
issue that win2k can't boot are identified by using xentrace.
2) outline some specific guest behavior, for example, how HVM guest are
using it's PIC/LAPIC, so that we may find some optimization
possibilites.

> If it's useful perhaps it should be extended into a generic
>HVM mechanism and define some processor-agnostic enumerations
>for exit-code reasons and so on.

If we could have it, it's really good.
But for now, I think it's hard and we still need more experiences.
-Xin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
RE: [PATCH] enhance HVM xentrace [ In reply to ]
>>I was wondering how useful these are at all. It's a bit random and
>>undocumented.
>
>Two usages for us currently:
>1) debug, for some specific bugs it's very useful, for example, the
>issue that win2k can't boot are identified by using xentrace.
>2) outline some specific guest behavior, for example, how HVM guest are
>using it's PIC/LAPIC, so that we may find some optimization
>possibilites.
>
>> If it's useful perhaps it should be extended into a generic
>>HVM mechanism and define some processor-agnostic enumerations
>>for exit-code reasons and so on.
>
>If we could have it, it's really good.
>But for now, I think it's hard and we still need more experiences.
>-Xin
>


The perl script to parse VMX xentrace data is attached, it helps to
shape VMX VMExit, I think maybe we can put it into tools/xentrace/
But 2 obviously issues:
1) it's specific to VMX currently, and the patch to encode shadow
information into XenTrace data is still in our hand since it's ugly :-(.
2) schdule data are not well parsed yet :-(

-Xin
RE: [PATCH] enhance HVM xentrace [ In reply to ]
>>I was wondering how useful these are at all. It's a bit random and
>>undocumented.
>
>Two usages for us currently:
>1) debug, for some specific bugs it's very useful, for example, the
>issue that win2k can't boot are identified by using xentrace.
>2) outline some specific guest behavior, for example, how HVM guest are
>using it's PIC/LAPIC, so that we may find some optimization
>possibilites.
>
>> If it's useful perhaps it should be extended into a generic
>>HVM mechanism and define some processor-agnostic enumerations
>>for exit-code reasons and so on.
>
>If we could have it, it's really good.
>But for now, I think it's hard and we still need more experiences.

The perl script in the attached patch is to parse VMX xentrace data, and
it helps to shape VMX VMExits with 2 obvious issues:
1) it's specific to VMX currently, and the patch to encode shadow
information into XenTrace data is still in our hand since it's ugly :-(
2) schdule data are not well parsed yet
-Xin
Re: [PATCH] enhance HVM xentrace [ In reply to ]
I've been using the VMX tracing (also modified, and with some
additional ugly shadow tracing) to analyze overhead of different
operations, as well as to look for patterns. There's some pretty
powerful analysis you can do with the right information in the trace
buffer.

I think it might be a good idea at some point for those of us using
the VMX tracing (along with those wanting to do SVM tracing) to get
together and define a useful interface.

-George

On 11/3/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
> On 3/11/06 04:10, "Li, Xin B" <xin.b.li@intel.com> wrote:
>
> > enhance HVM xentrace:
> > 1) VMX xentrace data are store in current vcpu instead physical CPU.
> > 2) Log PIO data in xentrace.
> >
> > Signed-off-by: Xin Li <xin.b.li@intel.com>
>
> I was wondering how useful these are at all. It's a bit random and
> undocumented. If it's useful perhaps it should be extended into a generic
> HVM mechanism and define some processor-agnostic enumerations for exit-code
> reasons and so on.
>
> -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

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