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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/05/18 10:26, Kang, Luwei wrote:
>>>>> 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?

Yes.  Then again, this information is readily available from the
emulator.  What we probably need (although I've not put much thought
into this) is to accumulate a list of trace events during emulation,
then insert them into the trace log only when we retire the instruction.

~Andrew

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