[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling



> > > > Here is a patch-series which adding Processor Trace enabling in XEN 
> > > > guest. You can get It's software developer manuals from:
> > > > https://software.intel.com/sites/default/files/managed/c5/15/archi
> > > > tect ure-instruction-set-extensions-programming-reference.pdf
> > > > In Chapter 5 INTEL PROCESSOR TRACE: VMX IMPROVEMENTS.
> > > >
> > > > Introduction:
> > > > Intel Processor Trace (Intel PT) is an extension of Intel
> > > > Architecture that captures information about software execution
> > > > using
> > > dedicated hardware facilities that cause only minimal performance
> > > perturbation to the software being traced. Details on the Intel PT 
> > > infrastructure and trace capabilities can be found in the Intel
> 64 and IA-32 Architectures Software Developer’s Manual, Volume 3C.
> > > >
> > > > The suite of architecture changes serve to simplify the process of
> > > > virtualizing Intel PT for use by a guest software. There are two
> > > primary elements to this new architecture support for VMX support 
> > > improvements made for Intel PT.
> > > > 1. Addition of a new guest IA32_RTIT_CTL value field to the VMCS.
> > > >   — This serves to speed and simplify the process of disabling trace on 
> > > > VM exit, and restoring it on VM entry.
> > > > 2. Enabling use of EPT to redirect PT output.
> > > >   — This enables the VMM to elect to virtualize the PT output
> > > > buffer using EPT. In this mode, the CPU will treat PT output
> > > addresses as Guest Physical Addresses (GPAs) and translate them
> > > using EPT. This means that Intel PT output reads (of the ToPA
> > > table) and writes (of trace output) can cause EPT violations, and other 
> > > output events.
> > > >
> > >
> > > A high level question, SDM vol 3 "Emulation of Intel PT Traced State"
> > > says:
> > >
> > > "If a VMM emulates an element of processor state by taking a VM exit
> > > on reads and/or writes to that piece of state, and the state element
> > > impacts Intel PT packet generation or values, it may be incumbent upon 
> > > the VMM to insert or modify the output trace data."
> > >
> > > The immediately follows that paragraph is an example of CR3 causing
> > > vmexit which leads to missing packet. IIRC Xen does that, however the 
> > > code as is doesn't seem to handle that at all.
> >
> > Yes, I need add some code on this. I propose if this can be handled by 
> > hardware but...
> >
> > >
> > > Another thing is Xen's vmevent allows intercepting several other
> > > traced states. It seems that a more generic framework is needed to make 
> > > PT work with vmevent subsystem? What is your
> thought on that?
> >
> > Hi Wei,
> >     I am not fully clear what is the "vmevent subsystem" and what is your 
> > mean of " several other traced states ".
> >     I guess vmevent is use VPMU collect performance counter? and save/load 
> > vpmu MSRs when it's scheduled?
> 
> See Razvan's reply.
> 
> I suppose your first step would be to make Xen able to insert new records to 
> guest's trace buffer. The end result would be a set of
> functions to do that. We would need that even without consideration of 
> vmevent because Xen can choose to intercept any of the
> traced state as it evolves.
> 
> Then we can see about how to hook that up to vmevent subsystem -- at this 
> point I think it will become a specialised case of what
> Xen already does.
> 

I briefly go through the source code of vm_event and find some function like 
hvm_monitor_msr(), hvm_monitor_cpuid(), hvm_monitor_cr(). I guess cpuid and msr 
event can work with current source code and don't need do anything.
The only things I can think of is as your mentioned " insert new records to 
guest's trace buffer ". But vmm may can't catch this event because it write by 
hardware. Or we trap the buffer write operation by making the trace buffer 
write protect or misconfiguration? 

Thanks,
Luwei Kang

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.