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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.01.2023 22:05, Andrew Cooper wrote:
> On 13/12/2022 4:31 pm, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1428,10 +1428,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 )
>> +        /*
>> +         * 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);
>> @@ -4180,6 +4189,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 breaks GDBSX and introspection.
> 
> For XSA-156, we were forced to intercept #DB unilaterally for safety,
> but both GDBSX and Introspection can optionally intercepting #DB for
> logical reasons too.
> 
> i.e. we can legitimately end up here even on an system with VM Notify.
> 
> 
> What I can't figure out is why made any reference to MTF.  MTF has
> absolutely nothing to do with TRAP_debug.

Looking back I see that the two seemingly asymmetric conditions puzzled
me during review, but for some reason I didn't question the MTF part
as a whole; I think I simply wasn't sure and hence left it to the
VMX maintainers. I think you're right and that part of the condition
wants deleting from vmx_update_debug_state() (on top of deleting the
entire if() above).

> Furthermore, there's no CPU in practice that has VM Notify but lacks
> MTF, so the head of vmx_update_debug_state() looks like dead code...

"No CPU in practice" is not an applicable argument as long as the spec
doesn't spell out a connection. When running virtualized ourselves, any
valid feature combination may be found (seeing that we similarly
may ourselves surface feature combinations to guests which no real
hardware equivalent exists for).

Jan