All of lore.kernel.org
 help / color / mirror / Atom feed
From: Feng Wu <feng.wu@intel.com>
To: xen-devel@lists.xen.org
Cc: kevin.tian@intel.com, keir@xen.org, george.dunlap@eu.citrix.com,
	andrew.cooper3@citrix.com, jbeulich@suse.com,
	yang.z.zhang@intel.com, Feng Wu <feng.wu@intel.com>
Subject: [RFC v2 08/15] Update IRTE according to guest interrupt config changes
Date: Fri,  8 May 2015 17:07:11 +0800	[thread overview]
Message-ID: <1431076038-7497-9-git-send-email-feng.wu@intel.com> (raw)
In-Reply-To: <1431076038-7497-1-git-send-email-feng.wu@intel.com>

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.

Signed-off-by: Feng Wu <feng.wu@intel.com>
---
 xen/drivers/passthrough/io.c | 99 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 98 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 9b77334..7b1c094 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -26,6 +26,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);
 
@@ -199,6 +200,73 @@ void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci)
     xfree(dpci);
 }
 
+/*
+ * 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, we find the destination vCPU from the
+ *   guest vector using vector-hashing mechanism and return true. This follows
+ *   the hardware behavior, since modern Intel CPUs use vector hashing to
+ *   handle the lowest-priority interrupt.
+ * - 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 false.
+ *
+ *   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 bool_t pi_find_dest_vcpu(struct domain *d, uint8_t dest_id,
+                                uint8_t dest_mode, uint8_t delivery_mode,
+                                uint8_t gvec, struct vcpu **dest_vcpu)
+{
+    struct vcpu *v, **dest_vcpu_array;
+    unsigned int dest_vcpu_num = 0;
+    int ret;
+
+    dest_vcpu_array = xzalloc_array(struct vcpu *, d->max_vcpus);
+    if ( !dest_vcpu_array )
+    {
+        dprintk(XENLOG_G_INFO,
+                "dom%d: failed to allocate memeory.\n", d->domain_id);
+        return 0;
+    }
+
+    for_each_vcpu ( d, v )
+    {
+        if ( !vlapic_match_dest(vcpu_vlapic(v), NULL, 0,
+                                dest_id, dest_mode) )
+            continue;
+
+        dest_vcpu_array[dest_vcpu_num++] = v;
+    }
+
+    if ( delivery_mode == dest_LowestPrio )
+    {
+        if (  dest_vcpu_num != 0 )
+        {
+            *dest_vcpu = dest_vcpu_array[gvec % dest_vcpu_num];
+            ret = 1;
+        }
+        else
+            ret = 0;
+    }
+    else if (  dest_vcpu_num == 1 )
+    {
+        *dest_vcpu = dest_vcpu_array[0];
+        ret = 1;
+    }
+    else
+        ret = 0;
+
+    xfree(dest_vcpu_array);
+    return ret;
+}
+
 int pt_irq_create_bind(
     struct domain *d, xen_domctl_bind_pt_irq_t *pt_irq_bind)
 {
@@ -257,7 +325,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) )
@@ -330,11 +398,40 @@ 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 */
+        if ( iommu_intpost )
+        {
+            struct vcpu *vcpu = NULL;
+
+            if ( !pi_find_dest_vcpu(d, dest, dest_mode, delivery_mode,
+                                    pirq_dpci->gmsi.gvec, &vcpu) )
+            {
+                dprintk(XENLOG_G_WARNING,
+                        "%pv: failed to find the dest vCPU for PI, guest "
+                        "vector:%u use software way to deliver the "
+                        " interrupts.\n", vcpu, pirq_dpci->gmsi.gvec);
+                break;
+            }
+
+            if ( pi_update_irte( vcpu, info, pirq_dpci->gmsi.gvec ) != 0 )
+            {
+                dprintk(XENLOG_G_WARNING,
+                        "%pv: failed to update PI IRTE, guest vector:%u "
+                        "use software way to deliver the interrupts.\n",
+                        vcpu, pirq_dpci->gmsi.gvec);
+
+                break;
+            }
+        }
+
         break;
     }
 
-- 
2.1.0

  parent reply	other threads:[~2015-05-08  9:07 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-08  9:07 [RFC v2 00/15] Add VT-d Posted-Interrupts support Feng Wu
2015-05-08  9:07 ` [RFC v2 01/15] Vt-d Posted-intterrupt (PI) design Feng Wu
2015-05-08  9:07 ` [RFC v2 02/15] iommu: Add iommu_intpost to control VT-d Posted-Interrupts feature Feng Wu
2015-06-09 14:10   ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 03/15] vt-d: VT-d Posted-Interrupts feature detection Feng Wu
2015-06-09 14:15   ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 04/15] vmx: Extend struct pi_desc to support VT-d Posted-Interrupts Feng Wu
2015-06-09 14:17   ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 05/15] vmx: Initialize VT-d Posted-Interrupts Descriptor Feng Wu
2015-06-09 14:20   ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 06/15] vt-d: Extend struct iremap_entry to support VT-d Posted-Interrupts Feng Wu
2015-06-09 14:25   ` Jan Beulich
2015-06-16  6:18     ` Wu, Feng
2015-06-16  7:48       ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 07/15] vt-d: Add API to update IRTE when VT-d PI is used Feng Wu
2015-06-09 14:32   ` Jan Beulich
2015-06-12  9:40     ` Wu, Feng
2015-06-12 10:33       ` Jan Beulich
2015-06-10  6:17   ` Jan Beulich
2015-06-12  9:40     ` Wu, Feng
2015-06-12 10:34       ` Jan Beulich
2015-05-08  9:07 ` Feng Wu [this message]
2015-06-09 15:06   ` [RFC v2 08/15] Update IRTE according to guest interrupt config changes Jan Beulich
2015-06-16  8:08     ` Wu, Feng
2015-06-16  8:17       ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 09/15] Add a new per-vCPU tasklet to wakeup the blocked vCPU Feng Wu
2015-06-09 15:08   ` Jan Beulich
2015-06-12  9:40     ` Wu, Feng
2015-06-12 10:41       ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 10/15] vmx: Define two per-cpu variables Feng Wu
2015-06-09 15:12   ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 11/15] vmx: Add a global wake-up vector for VT-d Posted-Interrupts Feng Wu
2015-06-09 15:20   ` Jan Beulich
2015-06-12  9:40     ` Wu, Feng
2015-06-12 10:44       ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 12/15] vmx: Properly handle notification event when vCPU is running Feng Wu
2015-06-09 16:12   ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 13/15] Update Posted-Interrupts Descriptor during vCPU scheduling Feng Wu
2015-06-10  6:43   ` Jan Beulich
2015-06-16  0:17     ` Wu, Feng
2015-06-16  7:53       ` Jan Beulich
2015-06-16  8:13         ` Wu, Feng
2015-06-16  8:29           ` Jan Beulich
2015-06-16  8:56             ` Wu, Feng
2015-06-16  9:24               ` Jan Beulich
2015-06-17  6:52                 ` Wu, Feng
2015-06-17  6:54     ` Wu, Feng
2015-06-17  7:56       ` Jan Beulich
2015-06-17  8:46         ` Wu, Feng
2015-06-17  8:59           ` Jan Beulich
2015-06-17  9:14             ` Wu, Feng
2015-06-17  7:00     ` Wu, Feng
2015-06-17  7:59       ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 14/15] Suppress posting interrupts when 'SN' is set Feng Wu
2015-06-10  6:48   ` Jan Beulich
2015-05-08  9:07 ` [RFC v2 15/15] Add a command line parameter for VT-d posted-interrupts Feng Wu
2015-06-10  6:52   ` Jan Beulich
2015-05-13  5:11 ` [RFC v2 00/15] Add VT-d Posted-Interrupts support Wu, Feng
2015-05-13  6:50   ` Jan Beulich
2015-05-13  7:04     ` Wu, Feng
2015-05-18  5:33 ` Tian, Kevin
2015-06-12  9:40 [RFC v2 08/15] Update IRTE according to guest interrupt config changes Wu, Feng
2015-06-12 10:40 ` Jan Beulich
2015-06-15  9:18   ` Wu, Feng

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=1431076038-7497-9-git-send-email-feng.wu@intel.com \
    --to=feng.wu@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yang.z.zhang@intel.com \
    /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.