[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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

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

Thanks for your response.

Luwei Kang

> 
> Therefore, as far as I can see, allowing a guest to use PT via EPT now 
> prohibits Xen also using PT for its own purposes outside of non-
> root mode.
> 
> Is this intentional and/or expected, or have I misunderstood something in the 
> manuals?
> 
> Thanks,
> 
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.