[Xen-changelog] [qemu-xen-unstable] passthrough: move pci_read_intx() and pci_intx()

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

commit f058b3c3548336677f58ec694c1a5e5cc7b5d845
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Mon Jan 4 17:47:03 2010 +0000

    passthrough: move pci_read_intx() and pci_intx()
    
    Move pci_read_intx() and pci_intx() to above pt_irqpin_reg_init().
    This is requred for a subsequent patch where pt_irqpin_reg_init()
    calls pci_read_intx().
    
    Cc: Tom Rotenberg <tom.rotenberg@xxxxxxxxx>
    Cc: Edwin Zhai <edwin.zhai@xxxxxxxxx>
    Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
    
    [patch 1/2] qemu-xen: pass-through: move pci_read_intx() and pci_intx()
    
    From:
    
    [patch 0/2] qemu-xen: pass-through: always use hw intx
    pass-through: always use hw intx and always get it from the same place
    
    The assumption that function zero always uses INTA tuns out not
    to be true in the wild. This leaves us with three options.
    
    1) Always use INTA
    
       This was the case before multi-function pass-through was possible.
       But with the advent of multi-function pass-through this may lead
       to excessive virtual GSI sharing.
    
    2) Fix emulation to use INTA for function zero
    
    3) Always use the hardware value for INTx
    
    There doesn't seem to be much between 2) and 3) but the latter seems
    slightly cleaner so I advocate that approach.
---
 hw/pass-through.c |  116 ++++++++++++++++++++++++++--------------------------
 1 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/hw/pass-through.c b/hw/pass-through.c
index e7bd386..bda908a 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -1021,6 +1021,64 @@ int bdf_to_devfn(char *bdf_str)
     return -1;
 }
 
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the intertupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+static uint8_t pci_read_intx(struct pt_dev *ptdev)
+{
+    uint8_t r_val = pci_read_byte(ptdev->pci_dev, PCI_INTERRUPT_PIN);
+
+    PT_LOG("intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4)
+    {
+        PT_LOG("Interrupt pin read from hardware is out of range: "
+               "value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    }
+    else
+    {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+/*
+ * For virtual function 0, always use INTA#,
+ * otherwise use the hardware value
+ */
+uint8_t pci_intx(struct pt_dev *ptdev)
+{
+    if (!PCI_FUNC(ptdev->dev.devfn))
+        return 0;
+    return pci_read_intx(ptdev);
+}
+
 /* Being called each time a mmio region has been updated */
 static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size,
                          int type)
@@ -4470,61 +4528,3 @@ int pt_init(PCIBus *e_bus)
 
     return 0;
 }
-
-/* The PCI Local Bus Specification, Rev. 3.0,
- * Section 6.2.4 Miscellaneous Registers, pp 223
- * outlines 5 valid values for the intertupt pin (intx).
- *  0: For devices (or device functions) that don't use an interrupt in
- *  1: INTA#
- *  2: INTB#
- *  3: INTC#
- *  4: INTD#
- *
- * Xen uses the following 4 values for intx
- *  0: INTA#
- *  1: INTB#
- *  2: INTC#
- *  3: INTD#
- *
- * Observing that these list of values are not the same, pci_read_intx()
- * uses the following mapping from hw to xen values.
- * This seems to reflect the current usage within Xen.
- *
- * PCI hardware    | Xen | Notes
- * ----------------+-----+----------------------------------------------------
- * 0               | 0   | No interrupt
- * 1               | 0   | INTA#
- * 2               | 1   | INTB#
- * 3               | 2   | INTC#
- * 4               | 3   | INTD#
- * any other value | 0   | This should never happen, log error message
- */
-static uint8_t pci_read_intx(struct pt_dev *ptdev)
-{
-    uint8_t r_val = pci_read_byte(ptdev->pci_dev, PCI_INTERRUPT_PIN);
-
-    PT_LOG("intx=%i\n", r_val);
-    if (r_val < 1 || r_val > 4)
-    {
-        PT_LOG("Interrupt pin read from hardware is out of range: "
-               "value=%i, acceptable range is 1 - 4\n", r_val);
-        r_val = 0;
-    }
-    else
-    {
-        r_val -= 1;
-    }
-
-    return r_val;
-}
-
-/*
- * For virtual function 0, always use INTA#,
- * otherwise use the hardware value
- */
-uint8_t pci_intx(struct pt_dev *ptdev)
-{
-    if (!PCI_FUNC(ptdev->dev.devfn))
-        return 0;
-    return pci_read_intx(ptdev);
-}
--
generated by git-patchbot for /home/xen/git/qemu-xen-unstable.git

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog