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

Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op


  • To: Michał Leszczyński <michal.leszczynski@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 22 Jun 2020 10:39:17 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=AzLQgpaLcUta3sDI7R2cn8rDxD/Tgo+eeo3raKNb6gA=; b=bgBdYawOjgbyzQ5NiYi+e62Fcmf+VB+O6ZwXYUd0xmTfiQhnS/JAmNHSnQIxIB0izVORS7HTgqC/bdNGvwX0G4Yt2EynmBYMPanFcclnxlEerLXyEN4vOLPcrx2aVKw0ROn0m7BqqB0WRl/q8EfWwrlEHe6iCLpzZcxIEo22E5NNOyrwZuZI3DHmhw5ldY4qpWB9H6Jv+a1QOWPy9LCGhzIXDwXhuBZaVI7GF0SIwnlLbDALyD0UQdru/X4K6RGYvgIKjNT5oNaT6IQEylBreqCzui4pEi6Mf/tGJhQPI9ztxvg9IKMkFYiWmz+RxLoUWrSybln/BzGiLmY7+ipZsw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IrJ9lFXKEGkDVfO/DlY7YW78zPyuf7fQBIlfWRmkpW/WUuz0Pa198M2ndi7xbiIAhmr0EXyN2szlTl+GKzodteinCSqeweVU5ZTF/LromOy3K3NQKUzoiF2quM3G50pmTd7ghnN4kc5Tjeu8vMSv/KYHHSKNdvUvB9mnoSjXPb6eJXTqt/qth++UUKnQ0Cah3WyuZ5wytRAWQapFEOu1AHd2/M1SQjLI8hDwUQXBrsUaklONNA9XEsqYyZRdGIBAJfwvEbwv0Gt4B0+hGH1M8tbQA1umnNF70o+LX++EUN/cWk6DrLJgiof0bkqkyy+hv+C++dKM1xfiTIDsDBxR1Q==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: Kevin Tian <kevin.tian@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, "Kang, Luwei" <luwei.kang@xxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Mon, 22 Jun 2020 08:39:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22.06.2020 04:56, Michał Leszczyński wrote:
> ----- 19 cze 2020 o 1:41, Michał Leszczyński michal.leszczynski@xxxxxxx 
> napisał(a):
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -508,11 +508,25 @@ static void vmx_restore_host_msrs(void)
>>
>> static void vmx_save_guest_msrs(struct vcpu *v)
>> {
>> +    uint64_t rtit_ctl;
>> +
>>     /*
>>      * We cannot cache SHADOW_GS_BASE while the VCPU runs, as it can
>>      * be updated at any time via SWAPGS, which we cannot trap.
>>      */
>>     v->arch.hvm.vmx.shadow_gs = rdgsshadow();
>> +
>> +    if ( unlikely(v->arch.hvm.vmx.ipt_state &&
>> v->arch.hvm.vmx.ipt_state->active) )
>> +    {
>> +        smp_rmb();
>> +        rdmsrl(MSR_RTIT_CTL, rtit_ctl);
>> +
>> +        if ( rtit_ctl & RTIT_CTL_TRACEEN )
>> +            BUG();
>> +
>> +        rdmsrl(MSR_RTIT_STATUS, v->arch.hvm.vmx.ipt_state->status);
>> +        rdmsrl(MSR_RTIT_OUTPUT_MASK,
>> v->arch.hvm.vmx.ipt_state->output_mask.raw);
>> +    }
>> }
> 
> 
> It was suggested to move this piece of code from vm-entry/vm-exit handling to
> vmx_save_guest_msrs/vmx_restore_guest_msrs functions.
> 
> Please note that we do need to periodically read MSR_RTIT_OUTPUT_MASK in order
> to know how much data was written into the buffer by the processor. During 
> tests,
> I've spotted that in some cases vCPUs get out of scope very rarely.
> 
> For instance: when IPT gets enabled, xc_vmtrace_ipt_get_offset() is returning 
> zero
> value for the first few seconds, because it's relying on the value of
> v->arch.hvm.vmx.ipt_state->output_mask which we only read in 
> vmx_save_guest_msrs()
> and in some cases this occurs very rarely.
> 
> Could you guys suggest some solution to the problem? If we would leave this 
> value
> dirty in hardware, AFAIK we have no possibility to directly access it,
> but observing this particular value is very important in the runtime.

Much depends on what state the vCPU in question is in when you need
to "periodically read" the value. If it's paused, you may need to
invoke sync_vcpu_execstate(). If it's actively running you can't
get at the value anyway except when you're on the CPU that this vCPU
is running on (and then you can RDMSR it quite easily). Any
intermediate state between paused and running is prone to change
immediately after you've established it anyway, so you need to get
the vCPU into one of the two "stable" states in order to get at
the register.

Also (and I think I said so before) - please trim your replies.

Jan



 


Rackspace

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