xen: add Intel IGD passthrough support

From: "Michael S. Tsirkin" <[email protected]>

Xen wants to supply a different pci and host devices, inheriting i440fx devices. Make types configurable.

Quoted 4 lines · Tiejun Chen

From: "Michael S. Tsirkin" <[email protected]>

Xen wants to supply a different pci and host devices, inheriting i440fx devices. Make types configurable.

Description is misleading, this isn't about xen but about IGD

passthrough. Guess kvm needs this too once kvmgt lands upstream.

Otherwise looks sane to me.

cheers,
Gerd

Quoted 7 lines · Gerd Hoffmann

Quoted 4 lines · Tiejun Chen

From: "Michael S. Tsirkin" <[email protected]>

Xen wants to supply a different pci and host devices, inheriting i440fx devices. Make types configurable.

Description is misleading, this isn't about xen but about IGD

Its about IGD passthrough in Xen side.

Quoted 9 lines · Tiejun

Quoted 7 lines · Gerd Hoffmann

Quoted 4 lines · Tiejun Chen

From: "Michael S. Tsirkin" <[email protected]>

Xen wants to supply a different pci and host devices, inheriting i440fx devices. Make types configurable.

Description is misleading, this isn't about xen but about IGD

Quoted 1 line

Its about IGD passthrough in Xen side.

As far I can see the only really xen specific stuff here is the pci pass-through bits, i.e. how we handle the IGD device itself.

The northbridge & isa-bridge emulation extensions needed for IGD should be pretty much common for IGD passthough on xen, IGD passthrough on kvm (vfio) and IGD virtualization (xengt+kvmgt).

cheers,
Gerd

Quoted 4 lines · Tiejun Chen

From: "Michael S. Tsirkin" <[email protected]>

Xen wants to supply a different pci and host devices, inheriting i440fx devices. Make types configurable.

Description is misleading, this isn't about xen but about IGD passthrough. Guess kvm needs this too once kvmgt lands upstream.

hw/pci-host/piix.c static const TypeInfo i440fx_info = { · line 738

Quoted 7 lines · Tiejun Chen

hw/pci-host/piix.c +7 -0

+static void xen_igd_passthrough_i440fx_class_init(ObjectClass *klass,
+                                                  void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+
+    dc->desc = "IGD PT XEN Host bridge";
+}

IMO "xen" naming should go away here too.

Quoted 11 lines · Gerd Hoffmann

hw/pci-host/piix.c static const TypeInfo i440fx_info = { · line 738

Quoted 7 lines · Tiejun Chen

hw/pci-host/piix.c +7 -0

+static void xen_igd_passthrough_i440fx_class_init(ObjectClass *klass,
+                                                  void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+
+    dc->desc = "IGD PT XEN Host bridge";
+}

IMO "xen" naming should go away here too.

Its easy to do but we need to wait KvmGT guys' response, so now it makes sense to leave "xen" as a prefix since this just work in xen side.

Thanks
Tiejun

Quoted 12 lines · Tiejun

Quoted 11 lines · Gerd Hoffmann

hw/pci-host/piix.c static const TypeInfo i440fx_info = { · line 738

Quoted 7 lines · Tiejun Chen

hw/pci-host/piix.c +7 -0

+static void xen_igd_passthrough_i440fx_class_init(ObjectClass *klass,
+                                                  void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+
+    dc->desc = "IGD PT XEN Host bridge";
+}

IMO "xen" naming should go away here too.

I would agree with this.

In fact, this piece of code could possibly be used by:

a) IGD passthru for Xen and KVM, and/or:
b) IGD Mediated passthru for Xen and KVM, i.e. XenGT/KVMGT

So it looks better if have "xen" naming purged :)

Quoted 8 lines

Its easy to do but we need to wait KvmGT guys' response, so now it makes sense to leave "xen" as a prefix since this just work in xen side.

Thanks
Tiejun

--
Thanks,
Jike

qemu-options.hx STEXI · line 1085

Quoted 8 lines · Tiejun Chen

qemu-options.hx +8 -0

+DEF("gfx_passthru", 0, QEMU_OPTION_gfx_passthru,
+    "-gfx_passthru   enable Intel IGD passthrough by XEN\n",
+    QEMU_ARCH_ALL)
+STEXI
+@item -gfx_passthru
+@findex -gfx_passthru
+Enable Intel IGD passthrough by XEN
+ETEXI

Make that a machine option, i.e. "-machine pc,igd-passthru=on"?

Quoted 11 lines · Gerd Hoffmann

qemu-options.hx STEXI · line 1085

Quoted 8 lines · Tiejun Chen

qemu-options.hx +8 -0

+DEF("gfx_passthru", 0, QEMU_OPTION_gfx_passthru,
+    "-gfx_passthru   enable Intel IGD passthrough by XEN\n",
+    QEMU_ARCH_ALL)
+STEXI
+@item -gfx_passthru
+@findex -gfx_passthru
+Enable Intel IGD passthrough by XEN
+ETEXI

Make that a machine option, i.e. "-machine pc,igd-passthru=on"?

Yeah but I think we need "-machine xenfv,igd-passthru=on" here.

Quoted 13 lines · Tiejun

Quoted 11 lines · Gerd Hoffmann

qemu-options.hx STEXI · line 1085

Quoted 8 lines · Tiejun Chen

qemu-options.hx +8 -0

+DEF("gfx_passthru", 0, QEMU_OPTION_gfx_passthru,
+    "-gfx_passthru   enable Intel IGD passthrough by XEN\n",
+    QEMU_ARCH_ALL)
+STEXI
+@item -gfx_passthru
+@findex -gfx_passthru
+Enable Intel IGD passthrough by XEN
+ETEXI

Make that a machine option, i.e. "-machine pc,igd-passthru=on"?

Quoted 1 line

Yeah but I think we need "-machine xenfv,igd-passthru=on" here.

IIRC xen decided to stop using xenfv and use pc-$version instead (with $version being what was current at release time, 1.6 for xen 4.4 I think, to avoid surprises like the address space layout changes in more recent machine types).

Currently IGD drivers always need to access PCH by 1f.0. But we

Quoted 1 line · Tiejun Chen

Currently IGD drivers always need to access PCH by 1f.0. But we

Obvious question: q35?

q35 already has a isa bridge @ 0x1f.0. Guess that needs to be extended for the pass-through then (simliar to the host bridge) instead of adding a dummy bridge.

Also: again xen naming here.

cheers,
Gerd

Quoted 9 lines · Gerd Hoffmann

Quoted 1 line · Tiejun Chen

Currently IGD drivers always need to access PCH by 1f.0. But we

Obvious question: q35?

q35 already has a isa bridge @ 0x1f.0. Guess that needs to be extended for the pass-through then (simliar to the host bridge) instead of adding a dummy bridge.

Quoted 4 lines

Also: again xen naming here.

cheers,
Gerd

This hack probably doesn't have a chance to work well for q35 due to the above conflict.

Happily future cards won't need it.

Currently IGD drivers always need to access PCH by 1f.0. But we don't want to poke that directly to get ID, and although in real world different GPU should have different PCH. But actually the different PCH DIDs likely map to different PCH SKUs. We do the same thing for the GPU. For PCH, the different SKUs are going to be all the same silicon design and implementation, just different features turn on and off with fuses. The SW interfaces should be consistent across all SKUs in a given family (eg LPT). But just same features may not be supported.

Most of these different PCH features probably don't matter to the Gfx driver, but obviously any difference in display port connections will so it should be fine with any PCH in case of passthrough.

So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell) scenarios, 0x9cc3 for BDW(Broadwell).

Signed-off-by Tiejun Chen <[email protected]>

---
 hw/xen/xen_pt.c | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 126 insertions(+)

hw/xen/xen_pt.c +94 -0

index fcc9f1c..5532d6f 100644
@@ -632,6 +632,129 @@ static const MemoryListener xen_pt_io_listener = {
     .priority = 10,
 };
 
+typedef struct {
+    uint16_t gpu_device_id;
+    uint16_t pch_device_id;
+    uint8_t pch_revision_id;
+} XenIGDDeviceIDInfo;
+
+/* In real world different GPU should have different PCH. But actually
+ * the different PCH DIDs likely map to different PCH SKUs. We do the
+ * same thing for the GPU. For PCH, the different SKUs are going to be
+ * all the same silicon design and implementation, just different
+ * features turn on and off with fuses. The SW interfaces should be
+ * consistent across all SKUs in a given family (eg LPT). But just same
+ * features may not be supported.
+ *
+ * Most of these different PCH features probably don't matter to the
+ * Gfx driver, but obviously any difference in display port connections
+ * will so it should be fine with any PCH in case of passthrough.
+ *
+ * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
+ * scenarios, 0x9cc3 for BDW(Broadwell).
+ */
+static const XenIGDDeviceIDInfo xen_igd_combo_id_infos[] = {
+    /* HSW Classic */
+    {0x0402, 0x8c4e, 0x04}, /* HSWGT1D, HSWD_w7 */
+    {0x0406, 0x8c4e, 0x04}, /* HSWGT1M, HSWM_w7 */
+    {0x0412, 0x8c4e, 0x04}, /* HSWGT2D, HSWD_w7 */
+    {0x0416, 0x8c4e, 0x04}, /* HSWGT2M, HSWM_w7 */
+    {0x041E, 0x8c4e, 0x04}, /* HSWGT15D, HSWD_w7 */
+    /* HSW ULT */
+    {0x0A06, 0x8c4e, 0x04}, /* HSWGT1UT, HSWM_w7 */
+    {0x0A16, 0x8c4e, 0x04}, /* HSWGT2UT, HSWM_w7 */
+    {0x0A26, 0x8c4e, 0x06}, /* HSWGT3UT, HSWM_w7 */
+    {0x0A2E, 0x8c4e, 0x04}, /* HSWGT3UT28W, HSWM_w7 */
+    {0x0A1E, 0x8c4e, 0x04}, /* HSWGT2UX, HSWM_w7 */
+    {0x0A0E, 0x8c4e, 0x04}, /* HSWGT1ULX, HSWM_w7 */
+    /* HSW CRW */
+    {0x0D26, 0x8c4e, 0x04}, /* HSWGT3CW, HSWM_w7 */
+    {0x0D22, 0x8c4e, 0x04}, /* HSWGT3CWDT, HSWD_w7 */
+    /* HSW Server */
+    {0x041A, 0x8c4e, 0x04}, /* HSWSVGT2, HSWD_w7 */
+    /* HSW SRVR */
+    {0x040A, 0x8c4e, 0x04}, /* HSWSVGT1, HSWD_w7 */
+    /* BSW */
+    {0x1606, 0x9cc3, 0x03}, /* BDWULTGT1, BDWM_w7 */
+    {0x1616, 0x9cc3, 0x03}, /* BDWULTGT2, BDWM_w7 */
+    {0x1626, 0x9cc3, 0x03}, /* BDWULTGT3, BDWM_w7 */
+    {0x160E, 0x9cc3, 0x03}, /* BDWULXGT1, BDWM_w7 */
+    {0x161E, 0x9cc3, 0x03}, /* BDWULXGT2, BDWM_w7 */
+    {0x1602, 0x9cc3, 0x03}, /* BDWHALOGT1, BDWM_w7 */
+    {0x1612, 0x9cc3, 0x03}, /* BDWHALOGT2, BDWM_w7 */
+    {0x1622, 0x9cc3, 0x03}, /* BDWHALOGT3, BDWM_w7 */
+    {0x162B, 0x9cc3, 0x03}, /* BDWHALO28W, BDWM_w7 */
+    {0x162A, 0x9cc3, 0x03}, /* BDWGT3WRKS, BDWM_w7 */
+    {0x162D, 0x9cc3, 0x03}, /* BDWGT3SRVR, BDWM_w7 */
+};
+
+static void isa_bridge_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    dc->desc        = "ISA bridge faked to support IGD PT";
+    k->vendor_id    = PCI_VENDOR_ID_INTEL;
+    k->class_id     = PCI_CLASS_BRIDGE_ISA;
+};
+
+static TypeInfo isa_bridge_info = {
+    .name          = "xen-igd-passthrough-isa-bridge",
+    .parent        = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(PCIDevice),
+    .class_init = isa_bridge_class_init,
+};
+
+static void xen_pt_graphics_register_types(void)
+{
+    type_register_static(&isa_bridge_info);
+}
+type_init(xen_pt_graphics_register_types)
+
+static void
+xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
+                                      XenHostPCIDevice *dev)
+{
+    struct PCIDevice *pci_dev;
+    int i, num;
+    uint16_t gpu_dev_id, pch_dev_id = 0xffff;
+    uint8_t pch_rev_id;
+    PCIDevice *d = &s->dev;
+
+    if (!is_igd_vga_passthrough(dev)) {
+        return;
+    }
+
+    gpu_dev_id = dev->device_id;

hw/xen/xen_pt.c +13 -0

+     * Note that vendor id is always PCI_VENDOR_ID_INTEL.
+     */
+    if (!pci_dev) {
+        fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed!\n");
+        return;
+    }
+    pci_config_set_device_id(pci_dev->config, pch_dev_id);
+    pci_config_set_revision(pci_dev->config, pch_rev_id);
+}
+
 /* init */
 
 static int xen_pt_initfn(PCIDevice *d)

@@ -680,6 +803,9 @@ static int xen_pt_initfn(PCIDevice *d)
             xen_host_pci_device_put(&s->real_device);
             return -1;
         }
+
+        /* Register ISA bridge for passthrough GFX. */
+        xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
     }
 
     /* Handle real device's MMIO/PIO BARs */

Signature · 1 line

1.9.1

hw/xen/xen_pt.c static const MemoryListener xen_pt_io_listener = { · line 738

Quoted 3 lines

hw/xen/xen_pt.c +3 -0

+
+    if (pch_dev_id == 0xffff) {
+        fprintf(stderr, "unsupported PCH!\n");

I would drop this fprintf: this likely means a newer card, so the bridge is not necessary.

hw/xen/xen_pt.c static const MemoryListener xen_pt_io_listener = { · line 747

Quoted 10 lines

hw/xen/xen_pt.c +9 -0

+        return;
+    }
+
+    /* Currently IGD drivers always need to access PCH by 1f.0. */
+    pci_dev = pci_create_simple(d->bus, PCI_DEVFN(0x1f, 0),
+                                "xen-igd-passthrough-isa-bridge");
+
+    /*
+     * Identify PCH card with its own real vendor/device ids.

This no longer holds I think.

Currently IGD drivers always need to access PCH by 1f.0. But we don't want to poke that directly to get ID, and although in real world different GPU should have different PCH. But actually the different PCH DIDs likely map to different PCH SKUs. We do the same thing for the GPU. For PCH, the different SKUs are going to be all the same silicon design and implementation, just different features turn on and off with fuses. The SW interfaces should be consistent across all SKUs in a given family (eg LPT). But just same features may not be supported.

Most of these different PCH features probably don't matter to the Gfx driver, but obviously any difference in display port connections will so it should be fine with any PCH in case of passthrough.

So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell) scenarios, 0x9cc3 for BDW(Broadwell).

Signed-off-by Tiejun Chen <[email protected]>

---
 hw/xen/xen_pt.c | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 126 insertions(+)

hw/xen/xen_pt.c +73 -0

index fcc9f1c..5532d6f 100644
@@ -632,6 +632,129 @@ static const MemoryListener xen_pt_io_listener = {
     .priority = 10,
 };
 
+typedef struct {
+    uint16_t gpu_device_id;
+    uint16_t pch_device_id;
+    uint8_t pch_revision_id;
+} XenIGDDeviceIDInfo;
+
+/* In real world different GPU should have different PCH. But actually
+ * the different PCH DIDs likely map to different PCH SKUs. We do the
+ * same thing for the GPU. For PCH, the different SKUs are going to be
+ * all the same silicon design and implementation, just different
+ * features turn on and off with fuses. The SW interfaces should be
+ * consistent across all SKUs in a given family (eg LPT). But just same
+ * features may not be supported.
+ *
+ * Most of these different PCH features probably don't matter to the
+ * Gfx driver, but obviously any difference in display port connections
+ * will so it should be fine with any PCH in case of passthrough.
+ *
+ * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
+ * scenarios, 0x9cc3 for BDW(Broadwell).
+ */
+static const XenIGDDeviceIDInfo xen_igd_combo_id_infos[] = {
+    /* HSW Classic */
+    {0x0402, 0x8c4e, 0x04}, /* HSWGT1D, HSWD_w7 */
+    {0x0406, 0x8c4e, 0x04}, /* HSWGT1M, HSWM_w7 */
+    {0x0412, 0x8c4e, 0x04}, /* HSWGT2D, HSWD_w7 */
+    {0x0416, 0x8c4e, 0x04}, /* HSWGT2M, HSWM_w7 */
+    {0x041E, 0x8c4e, 0x04}, /* HSWGT15D, HSWD_w7 */
+    /* HSW ULT */
+    {0x0A06, 0x8c4e, 0x04}, /* HSWGT1UT, HSWM_w7 */
+    {0x0A16, 0x8c4e, 0x04}, /* HSWGT2UT, HSWM_w7 */
+    {0x0A26, 0x8c4e, 0x06}, /* HSWGT3UT, HSWM_w7 */
+    {0x0A2E, 0x8c4e, 0x04}, /* HSWGT3UT28W, HSWM_w7 */
+    {0x0A1E, 0x8c4e, 0x04}, /* HSWGT2UX, HSWM_w7 */
+    {0x0A0E, 0x8c4e, 0x04}, /* HSWGT1ULX, HSWM_w7 */
+    /* HSW CRW */
+    {0x0D26, 0x8c4e, 0x04}, /* HSWGT3CW, HSWM_w7 */
+    {0x0D22, 0x8c4e, 0x04}, /* HSWGT3CWDT, HSWD_w7 */
+    /* HSW Server */
+    {0x041A, 0x8c4e, 0x04}, /* HSWSVGT2, HSWD_w7 */
+    /* HSW SRVR */
+    {0x040A, 0x8c4e, 0x04}, /* HSWSVGT1, HSWD_w7 */
+    /* BSW */
+    {0x1606, 0x9cc3, 0x03}, /* BDWULTGT1, BDWM_w7 */
+    {0x1616, 0x9cc3, 0x03}, /* BDWULTGT2, BDWM_w7 */
+    {0x1626, 0x9cc3, 0x03}, /* BDWULTGT3, BDWM_w7 */
+    {0x160E, 0x9cc3, 0x03}, /* BDWULXGT1, BDWM_w7 */
+    {0x161E, 0x9cc3, 0x03}, /* BDWULXGT2, BDWM_w7 */
+    {0x1602, 0x9cc3, 0x03}, /* BDWHALOGT1, BDWM_w7 */
+    {0x1612, 0x9cc3, 0x03}, /* BDWHALOGT2, BDWM_w7 */
+    {0x1622, 0x9cc3, 0x03}, /* BDWHALOGT3, BDWM_w7 */
+    {0x162B, 0x9cc3, 0x03}, /* BDWHALO28W, BDWM_w7 */
+    {0x162A, 0x9cc3, 0x03}, /* BDWGT3WRKS, BDWM_w7 */
+    {0x162D, 0x9cc3, 0x03}, /* BDWGT3SRVR, BDWM_w7 */
+};
+
+static void isa_bridge_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    dc->desc        = "ISA bridge faked to support IGD PT";
+    k->vendor_id    = PCI_VENDOR_ID_INTEL;
+    k->class_id     = PCI_CLASS_BRIDGE_ISA;
+};
+
+static TypeInfo isa_bridge_info = {
+    .name          = "xen-igd-passthrough-isa-bridge",
+    .parent        = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(PCIDevice),
+    .class_init = isa_bridge_class_init,
+};
+

hw/xen/xen_pt.c +42 -0

+    int i, num;
+    uint16_t gpu_dev_id, pch_dev_id = 0xffff;
+    uint8_t pch_rev_id;
+    PCIDevice *d = &s->dev;
+
+    if (!is_igd_vga_passthrough(dev)) {
+        return;
+    }
+
+    gpu_dev_id = dev->device_id;
+    num = ARRAY_SIZE(xen_igd_combo_id_infos);
+    for (i = 0; i < num; i++) {
+        if (gpu_dev_id == xen_igd_combo_id_infos[i].gpu_device_id) {
+            pch_dev_id = xen_igd_combo_id_infos[i].pch_device_id;
+            pch_rev_id = xen_igd_combo_id_infos[i].pch_revision_id;
+        }
+    }
+
+    if (pch_dev_id == 0xffff) {
+        fprintf(stderr, "unsupported PCH!\n");
+        return;
+    }
+
+    /* Currently IGD drivers always need to access PCH by 1f.0. */
+    pci_dev = pci_create_simple(d->bus, PCI_DEVFN(0x1f, 0),
+                                "xen-igd-passthrough-isa-bridge");
+
+    /*
+     * Identify PCH card with its own real vendor/device ids.
+     * Note that vendor id is always PCI_VENDOR_ID_INTEL.
+     */
+    if (!pci_dev) {
+        fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed!\n");
+        return;
+    }
+    pci_config_set_device_id(pci_dev->config, pch_dev_id);
+    pci_config_set_revision(pci_dev->config, pch_rev_id);
+}
+
 /* init */
 
 static int xen_pt_initfn(PCIDevice *d)

@@ -680,6 +803,9 @@ static int xen_pt_initfn(PCIDevice *d)
             xen_host_pci_device_put(&s->real_device);
             return -1;
         }
+
+        /* Register ISA bridge for passthrough GFX. */
+        xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
     }
 
     /* Handle real device's MMIO/PIO BARs */

Signature · 1 line

1.9.1

hw/xen/xen_pt.c static const MemoryListener xen_pt_io_listener = { · line 717

Quoted 4 lines

hw/xen/xen_pt.c +4 -0

+static void
+xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
+                                      XenHostPCIDevice *dev)
+{

I suggest this implementation, and the table, are moved to the same file where igd-passthrough-isa-bridge is implemented. The function can get PCIDevice *d, this way it's not xen specific.

Quoted 4 lines

+ struct PCIDevice *pci_dev;

pls rename bridge_dev;

Some registers of Intel IGD are mapped in host bridge, so it needs to passthrough these registers of physical host bridge to guest because emulated host bridge in guest doesn't have these mappings.

Signed-off-by Tiejun Chen <[email protected]>

Signed-off-by Yang Zhang <[email protected]>

---
 hw/pci-host/piix.c       |  3 ++
 hw/xen/xen_pt.h          |  1 +
 hw/xen/xen_pt_graphics.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 76 insertions(+)

hw/pci-host/piix.c +3 -0

index 1468961..0a5a4c7 100644
@@ -34,6 +34,7 @@
 #include "sysemu/sysemu.h"
 #include "hw/i386/ioapic.h"
 #include "qapi/visitor.h"
+#include "hw/xen/xen_pt.h"
 
 /*
  * I440FX chipset data sheet.

@@ -733,8 +734,10 @@ static void xen_igd_passthrough_i440fx_class_init(ObjectClass *klass,
                                                   void *data)
 {
     DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
 
     dc->desc = "IGD PT XEN Host bridge";
+    k->config_read = xen_igd_pci_read;
 }
 
 static const TypeInfo xen_igd_passthrough_i440fx_info = {

hw/xen/xen_pt.h +1 -0

index 0aa5a93..94cde4a 100644
@@ -5,6 +5,7 @@
 #include "hw/xen/xen_common.h"
 #include "hw/pci/pci.h"
 #include "xen-host-pci-device.h"
+uint32_t xen_igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
 
 void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
 

hw/xen/xen_pt_graphics.c +32 -0

index 3232296..227089b 100644
@@ -4,6 +4,7 @@
 #include "xen_pt.h"
 #include "xen-host-pci-device.h"
 #include "hw/xen/xen_backend.h"
+#include "hw/pci/pci_bus.h"
 
 typedef struct VGARegion {
     int type;           /* Memory or port I/O */

@@ -188,3 +189,74 @@ int xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev)
     cpu_physical_memory_rw(0xc0000, bios, bios_size, 1);
     return 0;
 }
+
+/*
+ * Currently we just pass this physical host bridge for IGD, 00:02.0.
+ *
+ * Here pci_dev is just that host bridge, so we have to get that real
+ * passthrough device by that given devfn to avoid other devices access.
+ */
+static int is_igd_passthrough(PCIDevice *pci_dev)
+{
+    PCIDevice *f = pci_dev->bus->devices[PCI_DEVFN(2, 0)];
+    if (pci_dev->bus->devices[PCI_DEVFN(2, 0)]) {
+        XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, f);
+        return (is_igd_vga_passthrough(&s->real_device)
+                    && (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL));
+    } else {
+        return 0;
+    }
+}
+
+uint32_t xen_igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
+{
+    XenHostPCIDevice dev;
+    uint32_t val;
+    int r;
+
+    /* IGD read/write is through the host bridge.
+     */
+    assert(pci_dev->devfn == 0x00);
+
+    if (!is_igd_passthrough(pci_dev)) {
+        goto read_default;

hw/xen/xen_pt_graphics.c +18 -0

+        break;
+    default:
+        /* Just gets the emulated values. */
+        goto read_default;
+    }
+
+    /* Host read */
+    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
+    if (r) {
+        goto err_out;
+    }
+
+    r = xen_host_pci_get_block(&dev, config_addr, (uint8_t *)&val, len);
+    if (r) {
+        goto err_out;
+    }
+
+    xen_host_pci_device_put(&dev);

Signature · 1 line

1.9.1

Quoted 16 lines

hw/xen/xen_pt_graphics.c +16 -0

+uint32_t xen_igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
+{
+    XenHostPCIDevice dev;
+    uint32_t val;
+    int r;
+
+    /* IGD read/write is through the host bridge.
+     */
+    assert(pci_dev->devfn == 0x00);
+
+    if (!is_igd_passthrough(pci_dev)) {
+        goto read_default;
+    }
+
+    /* Just work for the i915 driver. */
+    switch (config_addr) {

hw/xen/xen_pt_graphics.c int xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev) · line 232

Quoted 6 lines

hw/xen/xen_pt_graphics.c +6 -0

+    case 0x08:        /* revision id */
+    case 0x2c:        /* sybsystem vendor id */
+    case 0x2e:        /* sybsystem id */
+    case 0x50:        /* SNB: processor graphics control register */
+    case 0x52:        /* processor graphics control register */
+    case 0xa0:        /* top of memory */

Is this host physical memory? If yes how can using it in guest work?

hw/xen/xen_pt_graphics.c int xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev) · line 234

Quoted 3 lines

hw/xen/xen_pt_graphics.c +2 -0

+    case 0xa4:        /* SNB: graphics base of stolen memory */
+    case 0xa8:        /* SNB: base of GTT stolen memory */

Same question for above two.

Quoted 23 lines

hw/xen/xen_pt_graphics.c +22 -0

+        break;
+    default:
+        /* Just gets the emulated values. */
+        goto read_default;
+    }
+
+    /* Host read */
+    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
+    if (r) {
+        goto err_out;
+    }
+
+    r = xen_host_pci_get_block(&dev, config_addr, (uint8_t *)&val, len);
+    if (r) {
+        goto err_out;
+    }
+
+    xen_host_pci_device_put(&dev);
+
+    return val;
+
+read_default:

hw/xen/xen_pt_graphics.c int xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev) · line 262

Quoted 6 lines

hw/xen/xen_pt_graphics.c +6 -0

+    return pci_default_read_config(pci_dev, config_addr, len);
+
+err_out:
+    XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
+    return -1;
+}

Do any of the above registers change with time?

Does it work if we just read them when device is created and put in dev->config?

-----Original Message-----
From: Chen, Tiejun
Sent: Tuesday, January 20, 2015 7:17 PM
To: Michael S. Tsirkin; Kay, Allen M
Cc: [email protected]; [email protected]; [email protected]; Zhang, Yang Z; [email protected]
Subject: Re: [v6][PATCH 08/10] xen, gfx passthrough: support Intel IGD passthrough with VT-D

Quoted 16 lines

Quoted 16 lines

hw/xen/xen_pt_graphics.c +16 -0

+uint32_t xen_igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr,
+int len) {
+    XenHostPCIDevice dev;
+    uint32_t val;
+    int r;
+
+    /* IGD read/write is through the host bridge.
+     */
+    assert(pci_dev->devfn == 0x00);
+
+    if (!is_igd_passthrough(pci_dev)) {
+        goto read_default;
+    }
+
+    /* Just work for the i915 driver. */
+    switch (config_addr) {

Quoted 8 lines

hw/xen/xen_pt_graphics.c int xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev) · line 232

Quoted 6 lines

hw/xen/xen_pt_graphics.c +6 -0

+    case 0x08:        /* revision id */
+    case 0x2c:        /* sybsystem vendor id */
+    case 0x2e:        /* sybsystem id */
+    case 0x50:        /* SNB: processor graphics control register */
+    case 0x52:        /* processor graphics control register */
+    case 0xa0:        /* top of memory */

Is this host physical memory? If yes how can using it in guest work?

This is just a threshold value, not a start or end address :)

Quoted 4 lines

Quoted 3 lines

hw/xen/xen_pt_graphics.c +2 -0

+    case 0xa4:        /* SNB: graphics base of stolen memory */
+    case 0xa8:        /* SNB: base of GTT stolen memory */

Quoted 1 line

Same question for above two.

I shouldn't matter since I remember we already discussed this previously but I can't sort out this from those emails now.

Allen,

Could you reexplain this?

Quoted 23 lines

Quoted 23 lines

hw/xen/xen_pt_graphics.c +22 -0

+        break;
+    default:
+        /* Just gets the emulated values. */
+        goto read_default;
+    }
+
+    /* Host read */
+    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
+    if (r) {
+        goto err_out;
+    }
+
+    r = xen_host_pci_get_block(&dev, config_addr, (uint8_t *)&val, len);
+    if (r) {
+        goto err_out;
+    }
+
+    xen_host_pci_device_put(&dev);
+
+    return val;
+
+read_default:

Quoted 8 lines

hw/xen/xen_pt_graphics.c int xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev) · line 262

Quoted 6 lines

hw/xen/xen_pt_graphics.c +6 -0

+    return pci_default_read_config(pci_dev, config_addr, len);
+
+err_out:
+    XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
+    return -1;
+}

Do any of the above registers change with time?

Think about we just provide read ops, so they're not changed based on my experiential.

Quoted 2 lines

Does it work if we just read them when device is created and put in dev->config?

I think this is a good idea so I will go there and thank you.

Tiejun