Re: [PATCH 0/6] Intel Processor Trace virtulization enabling

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 26/10/17 05:13, Kang, Luwei 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/architect
>>> 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.
>>
>> Hello,
>>
>> Having read the new proposed extensions, I've got some architecture questions before diving into the patches themselves.
>>
>> First of all, is this technology expected to end up in Icelake, or something later?
> Yes, this would be enabled on Icelake.

Thanks.

>
>> In Vol 3, the existing VMX support describes a number of scenarios (system wide, VMM-only, VM-only, guest aware), which require
>> the use of MSR load lists to atomically alter the IA32_RTIT_* msrs.
> Currently, I just enabling the guest only mode(VM-only) in my patches.

That is fine.  I'm not asking you to implement these modes; I am just
trying to work out how they would interact.

>
>> Obviously, system wide mode is incompatible with also allowing the guest to use PT itself, 
> Yes, system mode(collect trace packets of the entire system) can't work with guest only mode at the same time.
>
>> but what about Xen wanting to use PT for itself, and for the guest to use PT as well?
> I think this can be named by host-guest mode. This may need add new command or interface to enable PT in Xen hypervisor. Trace vmm-only and guest simultaneous and output to their respective buffer.
>
>> Previously, this appears to be possible using the MSR load lists (albeit with Xen needing to shadow the ToPA records to cause the
>> packet stream to end up in the right place).
> Yes.
>
>> However, the new VM consistency checks require that using EPT redirection requires clear/load CTL on exit/entry be set, and having
>> load on entry set requires the host TraceEn to be clear.
> Yes. New bits added in VMCS can make sure PT be disabled before VM exit and IA32_RTIT_CTL MSR will be written with the value of the associated Guest State field of the VMCS on VM entry.

I am not sure I explained myself clearly.

It appears that it is possible to implement host-guest mode using MSR
load lists, because all the host configuration gets replaced by guest
configuration on vmentry, and host configuration gets restored at vmexit.

However with these PT extension, a new restriction is that a vmentry
failure will occur if we try to load the guest RTIT_CTL value while the
current RTIT_CTL.TraceEn is set.

As far as I can tell, this prohibits host-guest mode from working,
unless we tolerate having Xen clear RTIT_CTL before restoring guest GPR
state.

Is this correct, or have I missed something?

Thanks,

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel