On 26/01/2021 14:27, Jan Beulich wrote:
> On 21.01.2021 22:27, Andrew Cooper wrote:
>> --- a/xen/arch/x86/vm_event.c
>> +++ b/xen/arch/x86/vm_event.c
>> @@ -251,6 +251,9 @@ void vm_event_fill_regs(vm_event_request_t *req)
>>  
>>      req->data.regs.x86.shadow_gs = ctxt.shadow_gs;
>>      req->data.regs.x86.dr6 = ctxt.dr6;
>> +
>> +    if ( hvm_vmtrace_output_position(curr, &req->data.regs.x86.pt_offset) 
>> != 1 )
>> +        req->data.regs.x86.pt_offset = ~0;
> Ah. (Regarding my earlier question about this returning -errno or
> boolean).
>
>> --- a/xen/include/public/vm_event.h
>> +++ b/xen/include/public/vm_event.h
>> @@ -223,6 +223,12 @@ struct vm_event_regs_x86 {
>>       */
>>      uint64_t npt_base;
>>  
>> +    /*
>> +     * Current offset in the Processor Trace buffer. For Intel Processor 
>> Trace
>> +     * this is MSR_RTIT_OUTPUT_MASK. Set to ~0 if no Processor Trace is 
>> active.
>> +     */
>> +    uint64_t pt_offset;
> According to vmtrace_output_position() the value is only one half
> of what the named MSR contains. Perhaps "... this is from MSR_..."?
> Not sure whether, despite this, there still is a reason to have
> this 64-bit wide.

This is a vestigial remnant which escaped the "use vmtrace uniformly" work.

It should match the domctl_vmtrace_output_position() format, so each
interface gives the same content for the attempted-platform-neutral version.

~Andrew

Reply via email to