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

Re: [PATCH v7 10/10] x86/vm_event: Carry Processor Trace buffer offset in vm_event


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 1 Feb 2021 09:06:27 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sGjRN6tz/BfhPmsSH+7Nomnz4zgbH460+p/U5a3VJfI=; b=jOTki7pAZSX5ygC2u9r2lRuJaAMei47ysH25VgAP4W2r7diGGhAs64ouUB9nYipJcrcl3/rC9SMOp6MJOl/ne0gqrLVJlRXtk3y2RweKaVyDkm4LgeU0Z/OB6TdHub8pJN5DcJQUY6YYaVsnBa0kW9W2nBlB+rSDi2t9WGWhyRbX5ogaz5KrAD/jHC9Iu9yk8AyTa/cHMQ+QytbUJtgOLun0PeOM4LyCIKiex36mUEx9LgjauC7lLeCuhm8rtVYkZC9TfGuEhlKk9TIJrg1jvT7YonP4l5XDhlZfg6gz5gqtb4TqCGVJNYTY6sIQrKiqMJuXa+v5Pe/vmUOXWUAyIA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dmzl8EpwcX3pejtzrAT37HnC+Nf4gCblUATKhO1k/nwmYfKhFeoimjQeGqPOEMY9gt+NLcBLmBqSTU2PUCqXuWU06Pqr7vBip5T9yVIa0jgYYBATkXUlc5g8gdSb3ayyKHbdteGhMD95hDwVKbNnZtCeGmhWSQGm04zLKKvAa2Ltlu3whg6Y1fZS3sM2GVKQDDxXZ/WnGDdgPWmP904E9gBeVvOD3xrhBid/be+qWc8hViQbrHfueCRVrw639fpASSUJYO5x1rpSrHTkFWe/S7SlO9bPScaSUWmFUd4BQt8jVcxUQDp+TkdGJ+D307pIqn4y8lOm1pwNDid+GaSLtA==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Michał Leszczyński <michal.leszczynski@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 01 Feb 2021 09:06:58 +0000
  • Ironport-sdr: JjPmpUc7y4gJ0wMtEgJPJ0GIFydIeGEz0FCYCLC6dC+AU3tVXUpT5vytp9AtktnrwOOBcjdqXc tzf/d4AQIgDT94+IN1dgzYM66yC6BE5l2iXYlLawhi7Fb74uyKe9r3f9w4Tt4KD3oOrKjqcvGY E5hXB7oa2G0nVDaSE5My5h/eDDXDFZFNY4uRIv4nM9a0SdJQ3PqKuAnu/HNOjUWtSnE3dTsuJ5 xqVP2X6g05zLcHf7v8oEzufNF3TV6IGdLtj7A8JKC+KMGNsGlh+fyNsqhwt1T9nr7FFw1KIrwC X7c=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 01/02/2021 08:55, Jan Beulich wrote:
> On 30.01.2021 00:40, Tamas K Lengyel wrote:
>> On Fri, Jan 29, 2021 at 6:22 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
>> wrote:
>>> 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.
>> From the vm_event ABI perspective it's simpler to have a 64-bit value
>> here even if the max value it may possibly carry is never going to use
>> the whole 64-bit width. I rather not play with shortening it just to
>> add padding somewhere else.
>>
>> As for what it's called is not that important from my perspective,
>> vmtrace_pos or something like that for example is fine by me.
> The important thing to me is that the comment not be misleading.
> Whether that's arranged for by adjusting the comment of the
> commented declaration is up to what you deem better, i.e. I
> understand the comment it is.

Please see v8.  I rewrote the comment.

~Andrew



 


Rackspace

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