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

Re: [PATCH v2 3/3] x86/vmx: implement Notify VM Exit


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 7 Jun 2022 09:43:25 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EmJNePRXgjIKvdu5abJi5FPixN7IoQ968WzPPUigfiI=; b=L5AHJBu3cP02z9Y+BXIliAtww2yDAvxRhEQVSRmeICXUCTjOqoMYmCZvQFl5AUVLDlxzUhgwcyhQ7hU967eTGj1lxg7b8q3nTxAx+wXZa00U56gBdsHUrkOkyJO1Ww1PurA+yqh1vwoz8uSv+FdjARhd2HRDKH3hSjt8/EHMwAUPvWvD28NlEMLb/Jt62LtjsRcNj7FqypdonJboIDNvaykncGICSFTUyYP2fg3s2P8ZnUoyhdwODSTjHa5wzTsYzXbJ1YXhGnwGER5688XmivRG+cL4uSR2n3I0NVXOm0Dd0UcAjGXY7sADxlrEZlqCpVoodlkEaR26bb2vgfalkw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y+3mZgcvmyrVA3yzNmb+qdgWy8oB3t/1a7mAvbuD9/Quc+vG5rjzSsdXuGd5Uf8ciUGPlCKVaBR3zbS0nMik0lvodoIhJqajh2PvNgIKdHxgMFhWpsu/RKAXpytgbGN3lv/AXVig1gslxXjm8Yb/STPz7Od03LB4dEUmm4vm2n6agLMz/IkSdfHuTETf66xGpsxSJfTf22zM/AwyJq09eWba+XyKA2s7jh0QCWCALTvclKIdmhsw9YFtpVOuOVAc2QimtBKOoyyYNuJvjE3y1O9wBaTPVzS8hZPKalHraC7iSV0zVL+kPQ1FFrQOYszP0RpA/ERwSK9+Gq8fVAWXBg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 07 Jun 2022 07:43:37 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.06.2022 16:46, Roger Pau Monné wrote:
> On Fri, Jun 03, 2022 at 02:49:54PM +0200, Jan Beulich wrote:
>> On 26.05.2022 13:11, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -1419,10 +1419,19 @@ static void cf_check vmx_update_host_cr3(struct 
>>> vcpu *v)
>>>  
>>>  void vmx_update_debug_state(struct vcpu *v)
>>>  {
>>> +    unsigned int mask = 1u << TRAP_int3;
>>> +
>>> +    if ( !cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting )
>>
>> I'm puzzled by the lack of symmetry between this and ...
>>
>>> +        /*
>>> +         * Only allow toggling TRAP_debug if notify VM exit is enabled, as
>>> +         * unconditionally setting TRAP_debug is part of the XSA-156 fix.
>>> +         */
>>> +        mask |= 1u << TRAP_debug;
>>> +
>>>      if ( v->arch.hvm.debug_state_latch )
>>> -        v->arch.hvm.vmx.exception_bitmap |= 1U << TRAP_int3;
>>> +        v->arch.hvm.vmx.exception_bitmap |= mask;
>>>      else
>>> -        v->arch.hvm.vmx.exception_bitmap &= ~(1U << TRAP_int3);
>>> +        v->arch.hvm.vmx.exception_bitmap &= ~mask;
>>>  
>>>      vmx_vmcs_enter(v);
>>>      vmx_update_exception_bitmap(v);
>>> @@ -4155,6 +4164,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>>          switch ( vector )
>>>          {
>>>          case TRAP_debug:
>>> +            if ( cpu_has_monitor_trap_flag && 
>>> cpu_has_vmx_notify_vm_exiting )
>>> +                goto exit_and_crash;
>>
>> ... this condition. Shouldn't one be the inverse of the other (and
>> then it's the one down here which wants adjusting)?
> 
> The condition in vmx_update_debug_state() sets the mask so that
> TRAP_debug will only be added or removed from the bitmap if
> !cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting (note that
> otherwise TRAP_debug is unconditionally set if
> !cpu_has_vmx_notify_vm_exiting).
> 
> Hence it's impossible to get a VMExit TRAP_debug with
> cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting because
> TRAP_debug will never be set by vmx_update_debug_state() in that
> case.

Hmm, yes, I've been misguided by you not altering the existing setting
of v->arch.hvm.vmx.exception_bitmap in construct_vmcs(). Instead you
add an entirely new block of code near the bottom of the function. Is
there any chance you could move up that adjustment, perhaps along the
lines of

    v->arch.hvm.vmx.exception_bitmap = HVM_TRAP_MASK
              | (paging_mode_hap(d) ? 0 : (1U << TRAP_page_fault))
              | (v->arch.fully_eager_fpu ? 0 : (1U << TRAP_no_device));
    if ( cpu_has_vmx_notify_vm_exiting )
    {
        __vmwrite(NOTIFY_WINDOW, vm_notify_window);
        /*
         * Disable #AC and #DB interception: by using VM Notify Xen is
         * guaranteed to get a VM exit even if the guest manages to lock the
         * CPU.
         */
        v->arch.hvm.vmx.exception_bitmap &= ~((1U << TRAP_debug) |
                                              (1U << TRAP_alignment_check));
    }
    vmx_update_exception_bitmap(v);

Jan




 


Rackspace

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