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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Jan 16, 2018 at 02:12:26AM +0800, Luwei Kang wrote:
> Hi All,
> 
> 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/architecture-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.

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?

Wei.

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