From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Feng Wu <feng.wu@intel.com>
Cc: Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [PATCH v5 12/17] Update IRTE according to guest interrupt config changes
Date: Wed, 12 Aug 2015 12:43:21 -0400 [thread overview]
Message-ID: <20150812164320.GH17650@l.oracle.com> (raw)
In-Reply-To: <1439346938-31824-13-git-send-email-feng.wu@intel.com>
On Wed, Aug 12, 2015 at 10:35:33AM +0800, Feng Wu wrote:
> When guest changes its interrupt configuration (such as, vector, etc.)
> for direct-assigned devices, we need to update the associated IRTE
> with the new guest vector, so external interrupts from the assigned
> devices can be injected to guests without VM-Exit.
>
> For lowest-priority interrupts, we use vector-hashing mechamisn to find
> the destination vCPU. This follows the hardware behavior, since modern
> Intel CPUs use vector hashing to handle the lowest-priority interrupt.
>
> For multicast/broadcast vCPU, we cannot handle it via interrupt posting,
> still use interrupt remapping.
>
> CC: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Feng Wu <feng.wu@intel.com>
> ---
> v5:
> - Make 'struct vcpu *vcpu' const
>
> v4:
> - Make some 'int' variables 'unsigned int' in pi_find_dest_vcpu()
> - Make 'dest_id' uint32_t
> - Rename 'size' to 'bitmap_array_size'
> - find_next_bit() and find_first_bit() always return unsigned int,
> so no need to check whether the return value is less than 0.
> - Message error level XENLOG_G_WARNING -> XENLOG_G_INFO
> - Remove useless warning message
> - Create a seperate function vector_hashing_dest() to find the
> - destination of lowest-priority interrupts.
> - Change some comments
>
> v3:
> - Use bitmap to store the all the possible destination vCPUs of an
> interrupt, then trying to find the right destination from the bitmap
> - Typo and some small changes
>
> xen/drivers/passthrough/io.c | 124 ++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 123 insertions(+), 1 deletion(-)
>
> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index bda9374..f62f86c 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -25,6 +25,7 @@
> #include <asm/hvm/iommu.h>
> #include <asm/hvm/support.h>
> #include <xen/hvm/irq.h>
> +#include <asm/io_apic.h>
>
> static DEFINE_PER_CPU(struct list_head, dpci_list);
>
> @@ -198,6 +199,108 @@ void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci)
> xfree(dpci);
> }
>
> +/*
> + * This routine handles lowest-priority interrupts using vector-hashing
> + * mechanism. As an example, modern Intel CPUs use this method to handle
> + * lowest-priority interrupts.
> + *
> + * Here is the details about the vector-hashing mechanism:
> + * 1. For lowest-priority interrupts, store all the possible destination
> + * vCPUs in an array.
> + * 2. Use "gvec % max number of destination vCPUs" to find the right
> + * destination vCPU in the array for the lowest-priority interrupt.
> + */
> +static struct vcpu *vector_hashing_dest(const struct domain *d,
> + uint32_t dest_id,
> + bool_t dest_mode,
> + uint8_t gvec)
> +
> +{
> + unsigned long *dest_vcpu_bitmap;
> + unsigned int dest_vcpu_num = 0, idx;
> + unsigned int bitmap_array_size = BITS_TO_LONGS(d->max_vcpus);
> + struct vcpu *v, *dest = NULL;
> + unsigned int i;
> +
> + dest_vcpu_bitmap = xzalloc_array(unsigned long, bitmap_array_size);
> + if ( !dest_vcpu_bitmap )
> + {
> + dprintk(XENLOG_G_INFO,
> + "dom%d: failed to allocate memory\n", d->domain_id);
> + return NULL;
> + }
> +
> + for_each_vcpu ( d, v )
> + {
> + if ( !vlapic_match_dest(vcpu_vlapic(v), NULL, 0,
s/0/APIC_DEST_NOSHORT/
> + dest_id, dest_mode) )
> + continue;
> +
> + __set_bit(v->vcpu_id, dest_vcpu_bitmap);
> + dest_vcpu_num++;
Perhaps change the variable to:
dest_vcpus
?
> + }
> +
> + if ( dest_vcpu_num != 0 )
> + {
> + idx = 0;
> +
> + for ( i = gvec % dest_vcpu_num; i >= 0; i--)
That loop is not good as it will overflow.
Imagine gvec = 40, dest_vcpu_num = 2
On first iteration i = 0, on the next i = -1 (aka 0xfffffff), and so on.
> + {
> + idx = find_next_bit(dest_vcpu_bitmap, d->max_vcpus, idx) + 1;
> + BUG_ON(idx >= d->max_vcpus);
> + }
> + idx--;
> +
> + dest = d->vcpu[idx];
> + }
> +
> + xfree(dest_vcpu_bitmap);
> +
> + return dest;
> +}
> +
> +/*
> + * The purpose of this routine is to find the right destination vCPU for
> + * an interrupt which will be delivered by VT-d posted-interrupt. There
> + * are several cases as below:
> + *
> + * - For lowest-priority interrupts, use vector-hashing mechanism to find
> + * the destination.
> + * - Otherwise, for single destination interrupt, it is straightforward to
> + * find the destination vCPU and return true.
> + * - For multicast/broadcast vCPU, we cannot handle it via interrupt posting,
> + * so return NULL.
> + */
> +static struct vcpu *pi_find_dest_vcpu(const struct domain *d, uint32_t dest_id,
> + bool_t dest_mode, uint8_t delivery_mode,
> + uint8_t gvec)
> +{
> + unsigned int dest_vcpu_num = 0;
> + struct vcpu *v, *dest = NULL;
> +
> + if ( delivery_mode == dest_LowestPrio )
> + return vector_hashing_dest(d, dest_id, dest_mode, gvec);
> +
> + for_each_vcpu ( d, v )
> + {
> + if ( !vlapic_match_dest(vcpu_vlapic(v), NULL, 0,
s/0/APIC_DEST_NOSHORT/
> + dest_id, dest_mode) )
> + continue;
> +
> + dest_vcpu_num++;
> + dest = v;
> + }
> +
> + /*
> + * For fixed destination, we only handle single-destination
> + * interrupts.
> + */
> + if ( dest_vcpu_num == 1 )
> + return dest;
Something is off with the tabs here.
> +
> + return NULL;
> +}
> +
> int pt_irq_create_bind(
> struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)
> {
> @@ -256,7 +359,7 @@ int pt_irq_create_bind(
> {
> case PT_IRQ_TYPE_MSI:
> {
> - uint8_t dest, dest_mode;
> + uint8_t dest, dest_mode, delivery_mode;
> int dest_vcpu_id;
>
> if ( !(pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
> @@ -329,11 +432,30 @@ int pt_irq_create_bind(
> /* Calculate dest_vcpu_id for MSI-type pirq migration. */
> dest = pirq_dpci->gmsi.gflags & VMSI_DEST_ID_MASK;
> dest_mode = !!(pirq_dpci->gmsi.gflags & VMSI_DM_MASK);
> + delivery_mode = (pirq_dpci->gmsi.gflags >> GFLAGS_SHIFT_DELIV_MODE) &
> + VMSI_DELIV_MASK;
> dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode);
> pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id;
> spin_unlock(&d->event_lock);
> if ( dest_vcpu_id >= 0 )
> hvm_migrate_pirqs(d->vcpu[dest_vcpu_id]);
> +
> + /* Use interrupt posting if it is supported */
Missing full stop.
> + if ( iommu_intpost )
> + {
> + const struct vcpu *vcpu = pi_find_dest_vcpu(d, dest, dest_mode,
> + delivery_mode, pirq_dpci->gmsi.gvec);
> +
> + if ( vcpu )
> + {
> + rc = pi_update_irte( vcpu, info, pirq_dpci->gmsi.gvec );
> + if ( unlikely(rc) )
> + dprintk(XENLOG_G_INFO,
> + "%pv: failed to update PI IRTE, gvec:%02x\n",
> + vcpu, pirq_dpci->gmsi.gvec);
> + }
> + }
> +
> break;
> }
>
> --
> 2.1.0
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-08-12 16:43 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 2:35 [PATCH v5 00/17] Add VT-d Posted-Interrupts support Feng Wu
2015-08-12 2:35 ` [PATCH v5 01/17] VT-d Posted-intterrupt (PI) design Feng Wu
2015-08-12 15:35 ` Konrad Rzeszutek Wilk
2015-08-12 17:27 ` Andrew Cooper
2015-08-12 17:46 ` Konrad Rzeszutek Wilk
2015-08-13 1:37 ` Wu, Feng
2015-08-13 8:29 ` Jan Beulich
2015-08-12 2:35 ` [PATCH v5 02/17] Add cmpxchg16b support for x86-64 Feng Wu
2015-08-12 15:38 ` Konrad Rzeszutek Wilk
2015-08-12 2:35 ` [PATCH v5 03/17] iommu: Add iommu_intpost to control VT-d Posted-Interrupts feature Feng Wu
2015-08-12 15:39 ` Konrad Rzeszutek Wilk
2015-08-12 2:35 ` [PATCH v5 04/17] vt-d: VT-d Posted-Interrupts feature detection Feng Wu
2015-08-12 15:40 ` Konrad Rzeszutek Wilk
2015-08-12 2:35 ` [PATCH v5 05/17] vmx: Extend struct pi_desc to support VT-d Posted-Interrupts Feng Wu
2015-08-12 15:45 ` Konrad Rzeszutek Wilk
2015-08-12 2:35 ` [PATCH v5 06/17] vmx: Add some helper functions for Posted-Interrupts Feng Wu
2015-08-12 15:46 ` Konrad Rzeszutek Wilk
2015-08-12 2:35 ` [PATCH v5 07/17] vmx: Initialize VT-d Posted-Interrupts Descriptor Feng Wu
2015-08-12 17:03 ` Konrad Rzeszutek Wilk
2015-08-12 2:35 ` [PATCH v5 08/17] vmx: Suppress posting interrupts when 'SN' is set Feng Wu
2015-08-12 17:03 ` Konrad Rzeszutek Wilk
2015-08-12 2:35 ` [PATCH v5 09/17] VT-d: Remove pointless casts Feng Wu
2015-08-12 17:03 ` Konrad Rzeszutek Wilk
2015-08-12 2:35 ` [PATCH v5 10/17] vt-d: Extend struct iremap_entry to support VT-d Posted-Interrupts Feng Wu
2015-08-12 2:35 ` [PATCH v5 11/17] vt-d: Add API to update IRTE when VT-d PI is used Feng Wu
2015-08-12 16:23 ` Konrad Rzeszutek Wilk
2015-08-13 8:33 ` Jan Beulich
2015-08-13 18:27 ` Konrad Rzeszutek Wilk
2015-08-12 17:41 ` Andrew Cooper
2015-08-13 1:41 ` Wu, Feng
2015-08-12 2:35 ` [PATCH v5 12/17] Update IRTE according to guest interrupt config changes Feng Wu
2015-08-12 16:43 ` Konrad Rzeszutek Wilk [this message]
2015-08-13 1:37 ` Wu, Feng
2015-08-13 8:36 ` Jan Beulich
2015-08-12 2:35 ` [PATCH v5 13/17] vmx: posted-interrupt handling when vCPU is blocked Feng Wu
2015-08-12 16:59 ` Konrad Rzeszutek Wilk
2015-08-12 2:35 ` [PATCH v5 14/17] vmx: Properly handle notification event when vCPU is running Feng Wu
2015-08-12 17:02 ` Konrad Rzeszutek Wilk
2015-08-13 1:37 ` Wu, Feng
2015-08-12 2:35 ` [PATCH v5 15/17] vmx: Add some scheduler hooks for VT-d posted interrupts Feng Wu
2015-08-12 17:13 ` Konrad Rzeszutek Wilk
2015-08-13 9:06 ` Dario Faggioli
2015-08-13 9:15 ` Wu, Feng
2015-08-12 2:35 ` [PATCH v5 16/17] VT-d: Dump the posted format IRTE Feng Wu
2015-08-12 17:14 ` Konrad Rzeszutek Wilk
2015-08-12 2:35 ` [PATCH v5 17/17] Add a command line parameter for VT-d posted-interrupts Feng Wu
2015-08-12 17:16 ` Konrad Rzeszutek Wilk
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=20150812164320.GH17650@l.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=feng.wu@intel.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xen.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.