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

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

> >>> 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/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.
> >>
> >> 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.

System-Wide: trace Xen hypervisor and guest and output to host buffer; 
VMM-only: trace Xen hypervisor only and output to host buffer.;
VM-only: trace guest only and output to guest buffer;

> 
> >
> >> 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.

Yes, correct.

> 
> 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.

Yes, as description in "Intel® architecture instruction set extensions 
programming reference" 5.2.3. 
If the “Load IA32_RTIT_CTL on entry” is 1, IA32_RTIT_CTL.TraceEn must be zero. 
Otherwise will VM entry fails by loading processor state from the guest-state 
area of the VMCS.

> 
> 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.

Yes. If implement host-guest mode we should clear RTIT_CTL first and restore 
the guest state before VM-entry .
1. Clear RTIT_CTL before configuration MSRs. A WRMSR to any of these 
configuration MSRs that begins and ends with IA32_RTIT_CTL.TraceEn set will #GP 
fault. Packet generation must be disabled before the configuration MSRs can be 
changed. (SDM 36.2.7.1)
2. Restore other Intel PT MSRs.
3. Restore guest RTIT_CTL state to VMCS guest IA32_RTIT_CTL.

Thanks,
Luwei Kang
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel