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

["Kang, Luwei" <luwei.kang@xxxxxxxxx>]

> >>> 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/archite
> >>> ct 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.
> > Hi Wei,
> >     Intel PT can be exposed to guest only when EPT is enabled. In that 
> > case, CPU_BASED_CR3_LOAD_EXITING and
> CPU_BASED_CR3_STORE_EXITING would be clear, so "MOV CR3 " will not cause a 
> vm-exit. It looks like don't need emulate the
> missing PIP by writing it into the guest output buffer.
> 
> With introspection, the guest mov to cr3 instruction might be on a page 
> protected with NX at the EPT level, at which point it traps
> for inspection and will be completed with emulation, to avoid the overhead of 
> changing EPT permissions, singlestepping the guest,
> then reinstating the NX protection.
> 
> Basically, any and all actions could end up requiring emulation, based on the 
> safety decisions of the introspection logic.

Hi Andrew, 
     As you mentioned in previous mail and emphasized in community call. Any 
instruction might be on a page protected with NX at the EPT level. So it looks 
like that almost all the Trace packet need to be emulated. For example, 
TNT(taken/not-taken) might be emulate for branch instruction, TIP(target IP) 
might be emulate for branch, interrupt, exception and so on. Is that right?

Thanks,
Luwei Kang

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