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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
>> 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
>>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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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