All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 06/11] x86/hvm: allowing registering EOI callbacks for GSIs
Date: Wed, 7 Apr 2021 17:51:14 +0200	[thread overview]
Message-ID: <a57f0f75-341d-e6e1-823c-2083184a8f08@suse.com> (raw)
In-Reply-To: <20210331103303.79705-7-roger.pau@citrix.com>

On 31.03.2021 12:32, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -595,6 +595,69 @@ int hvm_local_events_need_delivery(struct vcpu *v)
>      return !hvm_interrupt_blocked(v, intack);
>  }
>  
> +int hvm_gsi_register_callback(struct domain *d, unsigned int gsi,
> +                              struct hvm_gsi_eoi_callback *cb)
> +{
> +    struct hvm_irq *hvm_irq = hvm_domain_irq(d);
> +
> +    if ( gsi >= hvm_irq->nr_gsis )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return -EINVAL;
> +    }
> +
> +    write_lock(&hvm_irq->gsi_callbacks_lock);
> +    list_add(&cb->list, &hvm_irq->gsi_callbacks[gsi]);
> +    write_unlock(&hvm_irq->gsi_callbacks_lock);
> +
> +    return 0;
> +}
> +
> +void hvm_gsi_unregister_callback(struct domain *d, unsigned int gsi,
> +                                 struct hvm_gsi_eoi_callback *cb)
> +{
> +    struct hvm_irq *hvm_irq = hvm_domain_irq(d);
> +    const struct list_head *tmp;
> +
> +    if ( gsi >= hvm_irq->nr_gsis )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return;
> +    }
> +
> +    write_lock(&hvm_irq->gsi_callbacks_lock);
> +    list_for_each ( tmp, &hvm_irq->gsi_callbacks[gsi] )
> +        if ( tmp == &cb->list )
> +        {
> +            list_del(&cb->list);
> +            break;
> +        }
> +    write_unlock(&hvm_irq->gsi_callbacks_lock);
> +}

Perhaps somehow flag, at least in debug builds, if the callback
wasn#t found?

> +void hvm_gsi_execute_callbacks(unsigned int gsi)
> +{
> +    struct hvm_irq *hvm_irq = hvm_domain_irq(current->domain);
> +    struct hvm_gsi_eoi_callback *cb;
> +
> +    read_lock(&hvm_irq->gsi_callbacks_lock);
> +    list_for_each_entry ( cb, &hvm_irq->gsi_callbacks[gsi], list )
> +        cb->callback(gsi, cb->data);
> +    read_unlock(&hvm_irq->gsi_callbacks_lock);
> +}

Just as an observation (for now at least) - holding the lock here
means the callbacks cannot re-register themselves.

> +bool hvm_gsi_has_callbacks(const struct domain *d, unsigned int gsi)
> +{
> +    struct hvm_irq *hvm_irq = hvm_domain_irq(d);
> +    bool has_callbacks;
> +
> +    read_lock(&hvm_irq->gsi_callbacks_lock);
> +    has_callbacks = !list_empty(&hvm_irq->gsi_callbacks[gsi]);
> +    read_unlock(&hvm_irq->gsi_callbacks_lock);
> +
> +    return has_callbacks;
> +}

What use is this function? Its result is stale by the time the
caller can look at it, as you've dropped the lock.

> @@ -421,13 +423,25 @@ static void eoi_callback(unsigned int vector, void *data)
>              if ( is_iommu_enabled(d) )
>              {
>                  spin_unlock(&d->arch.hvm.irq_lock);
> -                hvm_dpci_eoi(vioapic->base_gsi + pin);
> +                hvm_dpci_eoi(gsi);
>                  spin_lock(&d->arch.hvm.irq_lock);
>              }
>  
> +            /*
> +             * Callbacks don't expect to be executed with any lock held, so
> +             * drop the lock that protects the vIO-APIC fields from changing.
> +             *
> +             * Note that the redirection entry itself cannot go away, so upon
> +             * retaking the lock we only need to avoid making assumptions on
> +             * redirection entry field values (ie: recheck the IRR field).
> +             */
> +            spin_unlock(&d->arch.hvm.irq_lock);
> +            hvm_gsi_execute_callbacks(gsi);
> +            spin_lock(&d->arch.hvm.irq_lock);

The two pairs of unlock / re-lock want folding, I think - there's
no point causing extra contention on the lock here.

> @@ -443,7 +457,8 @@ static void ioapic_inj_irq(
>      struct vlapic *target,
>      uint8_t vector,
>      uint8_t trig_mode,
> -    uint8_t delivery_mode)
> +    uint8_t delivery_mode,
> +    bool callback)
>  {
>      HVM_DBG_LOG(DBG_LEVEL_IOAPIC, "irq %d trig %d deliv %d",
>                  vector, trig_mode, delivery_mode);
> @@ -452,7 +467,7 @@ static void ioapic_inj_irq(
>             (delivery_mode == dest_LowestPrio));
>  
>      vlapic_set_irq_callback(target, vector, trig_mode,
> -                            trig_mode ? eoi_callback : NULL, NULL);
> +                            callback ? eoi_callback : NULL, NULL);

I think you'd better use trig_mode || callback here and ...

> @@ -466,6 +481,7 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin)
>      struct vlapic *target;
>      struct vcpu *v;
>      unsigned int irq = vioapic->base_gsi + pin;
> +    bool callback = trig_mode || hvm_gsi_has_callbacks(d, irq);
>  
>      ASSERT(spin_is_locked(&d->arch.hvm.irq_lock));
>  
> @@ -492,7 +508,8 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin)
>              target = vlapic_lowest_prio(d, NULL, 0, dest, dest_mode);
>          if ( target != NULL )
>          {
> -            ioapic_inj_irq(vioapic, target, vector, trig_mode, delivery_mode);
> +            ioapic_inj_irq(vioapic, target, vector, trig_mode, delivery_mode,
> +                           callback);

... invoke hvm_gsi_has_callbacks() right here and ...

> @@ -507,7 +524,7 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin)
>          for_each_vcpu ( d, v )
>              if ( vlapic_match_dest(vcpu_vlapic(v), NULL, 0, dest, dest_mode) )
>                  ioapic_inj_irq(vioapic, vcpu_vlapic(v), vector, trig_mode,
> -                               delivery_mode);
> +                               delivery_mode, callback);

... here, avoiding to call the function when you don't need the
result.

Jan


  reply	other threads:[~2021-04-07 15:51 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-31 10:32 [PATCH v3 00/11] x86/intr: introduce EOI callbacks and fix vPT Roger Pau Monne
2021-03-31 10:32 ` [PATCH v3 01/11] x86/hvm: drop vcpu parameter from vlapic EOI callbacks Roger Pau Monne
2021-03-31 16:02   ` Jan Beulich
2021-03-31 16:24     ` Andrew Cooper
2021-04-01  9:12       ` Roger Pau Monné
2021-04-01 11:06   ` Jan Beulich
2021-04-07  7:41     ` Roger Pau Monné
2021-04-07  8:19       ` Jan Beulich
2021-03-31 10:32 ` [PATCH v3 02/11] x86/hvm: drop domain parameter from vioapic/vpic " Roger Pau Monne
2021-03-31 16:04   ` Jan Beulich
2021-04-01  9:15     ` Roger Pau Monné
2021-04-01  9:28       ` Jan Beulich
2021-03-31 10:32 ` [PATCH v3 03/11] x86/vlapic: introduce an EOI callback mechanism Roger Pau Monne
2021-03-31 11:47   ` Andrew Cooper
2021-03-31 12:50     ` Roger Pau Monné
2021-04-07 14:55   ` Jan Beulich
2021-04-07 16:27     ` Roger Pau Monné
2021-04-08  6:20       ` Jan Beulich
2021-04-08  9:12         ` Roger Pau Monné
2021-04-08 10:49           ` Jan Beulich
2021-04-08 10:56             ` Roger Pau Monné
2021-03-31 10:32 ` [PATCH v3 04/11] x86/vmsi: use the newly introduced EOI callbacks Roger Pau Monne
2021-04-07 14:59   ` Jan Beulich
2021-03-31 10:32 ` [PATCH v3 05/11] x86/vioapic: switch to use the EOI callback mechanism Roger Pau Monne
2021-04-07 15:19   ` Jan Beulich
2021-04-07 16:46     ` Roger Pau Monné
2021-04-08  6:27       ` Jan Beulich
2021-04-08  8:59         ` Roger Pau Monné
2021-04-08 10:52           ` Jan Beulich
2021-03-31 10:32 ` [PATCH v3 06/11] x86/hvm: allowing registering EOI callbacks for GSIs Roger Pau Monne
2021-04-07 15:51   ` Jan Beulich [this message]
2021-04-07 17:08     ` Roger Pau Monné
2021-04-08  6:34       ` Jan Beulich
2021-04-15 16:04       ` Roger Pau Monné
2021-04-16  7:29         ` Jan Beulich
2021-04-19  8:31           ` Roger Pau Monné
2021-04-08 12:52     ` Roger Pau Monné
2021-04-08 14:31       ` Jan Beulich
2021-04-08 15:06         ` Roger Pau Monné
2021-03-31 10:32 ` [PATCH v3 07/11] x86/dpci: move code Roger Pau Monne
2021-03-31 10:33 ` [PATCH v3 08/11] x86/dpci: switch to use a GSI EOI callback Roger Pau Monne
2021-04-08 14:49   ` Jan Beulich
2021-04-08 15:23     ` Roger Pau Monné
2021-03-31 10:33 ` [PATCH v3 09/11] x86/vpt: switch interrupt injection model Roger Pau Monne
2021-04-14 10:28   ` Jan Beulich
2021-04-14 13:37     ` Roger Pau Monné
2021-04-14 14:05       ` Jan Beulich
2021-04-14 14:20         ` Roger Pau Monné
2021-03-31 10:33 ` [PATCH v3 10/11] x86/vpt: remove vPT timers per-vCPU lists Roger Pau Monne
2021-04-14 10:38   ` Jan Beulich
2021-03-31 10:33 ` [PATCH v3 11/11] x86/vpt: introduce a per-vPT lock Roger Pau Monne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a57f0f75-341d-e6e1-823c-2083184a8f08@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.