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

Re: [PATCH] x86 / viridian: remove the viridian_vcpu msg_pending bit mask


  • To: Paul Durrant <paul@xxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 13 Aug 2020 12:15:49 +0200
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Paul Durrant <pdurrant@xxxxxxxxxx>, "Wei Liu" <wl@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Thu, 13 Aug 2020 10:16:22 +0000
  • Ironport-sdr: WP4kH+OdkP0qw0RmUj9Oh7b3TYkHjG8h724gHTWT/jPkKOPFtYKiiyIOUQlHYW+KOzKszIVDaQ 7VDvBN/GYLYtCVGVkujlaaqJH2D3mMWnySgnexy6S9KOfF7J6mhIZewyL8rEpRkbwM4RxXk9yf l2djRadaQn4p25nAJuvKBwXGNbNDojtrxVbhNJRWQ32SnKuSX4fhfk8cKFCt52qPlr4ipE+5dN DMqyKoSB55qQAMUdwtL8wMBvwMGpnaR4m3I7v8bI0ryz3SSM8hVMaiePjTo6nyMexdGxCbp+X8 CcQ=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Aug 13, 2020 at 10:57:23AM +0100, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@xxxxxxxxxx>
> 
> The mask does not actually serve a useful purpose as we only use the SynIC
> for timer messages.

Oh, I see. I assume it doesn't make sense because there can only be a
single message pending (a timer one), and hence there isn't much value
in doing this SynIC pending tracking? 

> Dropping the mask means that the EOM MSR handler
> essentially becomes a no-op. This means we can avoid setting 'message_pending'
> for timer messages and hence avoid a VMEXIT for the EOM.
> 
> Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx>

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

I've got some question below and one nit.

> ---
> Cc: Wei Liu <wl@xxxxxxx>
> Cc: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Cc: "Roger Pau Monné" <roger.pau@xxxxxxxxxx>
> 
> This should hopefully simplify Roger's "x86/vlapic: implement EOI callbacks"
> series a little.
> ---
>  xen/arch/x86/hvm/viridian/synic.c  | 24 +-----------------------
>  xen/arch/x86/hvm/vlapic.c          |  2 --
>  xen/include/asm-x86/hvm/viridian.h |  2 --
>  3 files changed, 1 insertion(+), 27 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/viridian/synic.c 
> b/xen/arch/x86/hvm/viridian/synic.c
> index 94a2b88733..22e2df27e5 100644
> --- a/xen/arch/x86/hvm/viridian/synic.c
> +++ b/xen/arch/x86/hvm/viridian/synic.c
> @@ -137,7 +137,6 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, 
> uint64_t val)
>          if ( !(viridian_feature_mask(d) & HVMPV_synic) )
>              return X86EMUL_EXCEPTION;
>  
> -        vv->msg_pending = 0;
>          break;
>  
>      case HV_X64_MSR_SINT0 ... HV_X64_MSR_SINT15:
> @@ -168,9 +167,6 @@ int viridian_synic_wrmsr(struct vcpu *v, uint32_t idx, 
> uint64_t val)
>          printk(XENLOG_G_INFO "%pv: VIRIDIAN SINT%u: vector: %x\n", v, sintx,
>                 vector);
>  
> -        if ( new.polling )
> -            __clear_bit(sintx, &vv->msg_pending);
> -
>          *vs = new;
>          break;
>      }
> @@ -334,9 +330,6 @@ bool viridian_synic_deliver_timer_msg(struct vcpu *v, 
> unsigned int sintx,
>          .DeliveryTime = delivery,
>      };
>  
> -    if ( test_bit(sintx, &vv->msg_pending) )
> -        return false;
> -
>      /*
>       * To avoid using an atomic test-and-set, and barrier before calling
>       * vlapic_set_irq(), this function must be called in context of the
> @@ -346,12 +339,9 @@ bool viridian_synic_deliver_timer_msg(struct vcpu *v, 
> unsigned int sintx,
>  
>      msg += sintx;
>  
> +    /* There is no need to set message_pending as we do not require an EOM */
>      if ( msg->header.message_type != HVMSG_NONE )

I think it's fine to use HVMSG_NONE ATM because Xen only knows about
timer messages, but long term wouldn't it be better to use
HVMSG_TIMER_EXPIRED?

> -    {
> -        msg->header.message_flags.msg_pending = 1;
> -        __set_bit(sintx, &vv->msg_pending);
>          return false;
> -    }
>  
>      msg->header.message_type = HVMSG_TIMER_EXPIRED;
>      msg->header.message_flags.msg_pending = 0;
> @@ -380,18 +370,6 @@ bool viridian_synic_is_auto_eoi_sint(const struct vcpu 
> *v,
>      return vs->auto_eoi;
>  }
>  
> -void viridian_synic_ack_sint(const struct vcpu *v, unsigned int vector)
> -{
> -    struct viridian_vcpu *vv = v->arch.hvm.viridian;
> -    unsigned int sintx = vv->vector_to_sintx[vector];
> -
> -    ASSERT(v == current);
> -
> -    if ( sintx < ARRAY_SIZE(vv->sint) )
> -        __clear_bit(array_index_nospec(sintx, ARRAY_SIZE(vv->sint)),
> -                    &vv->msg_pending);
> -}
> -
>  void viridian_synic_save_vcpu_ctxt(const struct vcpu *v,
>                                     struct hvm_viridian_vcpu_context *ctxt)
>  {
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 7b5c633033..1aff4cf989 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -466,8 +466,6 @@ void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
>  
>      if ( vlapic_test_vector(vector, &vlapic->regs->data[APIC_TMR]) )
>          vioapic_update_EOI(d, vector);
> -    else if ( has_viridian_synic(d) )
> -        viridian_synic_ack_sint(v, vector);

Please also clean the comment above about SynIC SINTx being edge
triggered.

Thanks, Roger.



 


Rackspace

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