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

Re: [Xen-devel] [PATCH] x86/HVM: adjust hvm_interrupt_blocked()


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 31 Aug 2023 12:42:58 +0200
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=l1cqeqijpgvhxLv1B7jYvYIpq/meCgyTj84p4u89SKc=; b=VTeO5LKNWx9tGUP6+32fSETj0ivbhhBpkJ1Z+4izNwT7DTBz7RpxGVul9f1eXFEzTOA2hwn3NW0uuLr7fiIroN/KKJ+EQpqrkfEXGGZzPcFiHyvbmco3GQi+lrW02pR7mk34ItYOYW+DYMesnowFptepLOchFHUwoxxxkSJYzoImFyRaE2W7Vgt5QteIFR4OEY63em4vXVY+XGglNRWLvAihfe7qWz1pl8pEOdZJ7DuYgnfMqS4TZ0RLE2Z5Ub2RQ5kX9CbOxTBqcfwd1Gb1VXz0ll5haSo6rEzjqh00wJ75MXOq7vQN7dhmTMfggFR/9z4ZDKIGiBm77TyJ/rSbaQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bocrYVJ6MaRoOhRPZHwJHnHMM0hDvwhaYa+PUg/o+8hXxDJwTGRGSz613VgYrOm/PDMzNiCY9VPfZu61tKMGKyj4A9kE2Tn0kRPYIUpKWZKcAQUbaPNGGyefUbhE6rPGAQ3RdtLxZLWnZcrRGF4zetSjMG5a9Y1H8AhQkuvKpRMBRTBKfEVCg57956h0noBnebfBAWrkOvAMTiSu0y7GNlUkB1chuOQtfoe00mUXg0LLruw9DLNH8s2VKR50EX5vJ6R21aUoE/jU4u3BpsoxE80HmvYtMtjo5IIokVxP7n724S/1TPHx0hFiIIo/tsPcT69JCJW82JPGrWQAcNr7jg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>
  • Delivery-date: Thu, 31 Aug 2023 10:43:23 +0000
  • Ironport-data: A9a23:foee1aKwUZ9t6dRAFE+Rw5QlxSXFcZb7ZxGr2PjKsXjdYENS1zxTn DQXDD+POvnbZzGgc4skPI2w8hsBu5GDx9FjSlBlqX01Q3x08seUXt7xwmUcnc+xBpaaEB84t ZV2hv3odp1coqr0/0/1WlTZhSAgk/rOHvykU7Ss1hlZHWdMUD0mhQ9oh9k3i4tphcnRKw6Ws Jb5rta31GWNglaYCUpKrfrZwP9TlK6q4mhA7gdnPakjUGL2zBH5MrpOfcldEFOgKmVkNrbSb /rOyri/4lTY838FYj9yuu+mGqGiaue60Tmm0hK6aYD76vRxjnVaPpIAHOgdcS9qZwChxLid/ jnvWauYEm/FNoWU8AgUvoIx/ytWZcWq85efSZSzXFD6I+QrvBIAzt03ZHzaM7H09c5eOjtvq 84XFgsQRR27t9PuwYnrdc9z05FLwMnDZOvzu1lG5BSAVLMMZ8CGRK/Ho9hFwD03m8ZCW+7EY NYUYiZuaxKGZABTPlAQC9Q1m+LAanvXKmUE7g7K4/dnpTGNnWSd05C0WDbRUsaNSshP2F6Ru 0rN/njjAwFcP9uaodaA2iv23b6Sx3+mCer+EpWxq6dosHK1x1ZNCSEfZVvrhP2W0k2hDoc3x 0s8v3BGQbIJ3G6BQ8T5Xha4iGWZpRNaUN1Ve8Uq5QfIxqfK7gKxAmkfUiUHeNEgrNUxRzEhy hmOhdyBONB0mLicSHbY/LHEqzq3YHERNTVbO35CShYZ6d7+po11lgjIUttoDK+yiJvyBC30x DeJ6iM5gt3/kPI26klyxnif6xrEm3QDZlddCtn/No590j5EWQ==
  • Ironport-hdrordr: A9a23:26HfsaDqGsTX6AblHemT55DYdb4zR+YMi2TDGXoBMCC9E/bo7/ xG+c5w6faaskd1ZJhNo6HjBEDEewK+yXcX2+gs1NWZLW3bUQKTRekI0WKh+V3d8kbFh4lgPM lbAs5D4R7LYWSST/yW3OB1KbkdKRC8npyVuQ==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Oct 12, 2018 at 09:58:46AM -0600, Jan Beulich wrote:
> First of all, hvm_intsrc_mce was not considered here at all, yet nothing
> blocks #MC (other than an already in-progress #MC, but dealing with this
> is not the purpose of this patch).
> 
> Additionally STI-shadow only blocks maskable interrupts, but not NMI.

I've found the Table 25-3 on Intel SDM vol3 quite helpful:

"Execution of STI with RFLAGS.IF = 0 blocks maskable interrupts on the
instruction boundary following its execution.1 Setting this bit
indicates that this blocking is in effect."

And:

"Execution of a MOV to SS or a POP to SS blocks or suppresses certain
debug exceptions as well as interrupts (maskable and nonmaskable) on
the instruction boundary following its execution."

Might be worth adding to the commit message IMO.

> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3771,19 +3771,24 @@ enum hvm_intblk hvm_interrupt_blocked(st
>              return intr;
>      }
>  
> -    if ( (intack.source != hvm_intsrc_nmi) &&
> -         !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) )
> -        return hvm_intblk_rflags_ie;
> +    if ( intack.source == hvm_intsrc_mce )
> +        return hvm_intblk_none;

I've been wondering, why do we handle #MC here, instead of doing the
same as for other Traps/Exceptions and use hvm_inject_hw_exception()
directly?

>  
>      intr_shadow = hvm_funcs.get_interrupt_shadow(v);
>  
> -    if ( intr_shadow & (HVM_INTR_SHADOW_STI|HVM_INTR_SHADOW_MOV_SS) )
> +    if ( intr_shadow & HVM_INTR_SHADOW_MOV_SS )
>          return hvm_intblk_shadow;
>  
>      if ( intack.source == hvm_intsrc_nmi )
>          return ((intr_shadow & HVM_INTR_SHADOW_NMI) ?
>                  hvm_intblk_nmi_iret : hvm_intblk_none);
>  
> +    if ( intr_shadow & HVM_INTR_SHADOW_STI )
> +        return hvm_intblk_shadow;
> +
> +    if ( !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) )
> +        return hvm_intblk_rflags_ie;

I do wonder whether this code would be clearer using a `switch (
intack.source )` construct, but that's out of the scope.

Thanks, Roger.



 


Rackspace

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