[Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Tiejun Chen]

V5 is generated just based on Paolo's some comments.

v5:

* Don't set that ISA class property, instead, just fake this ISA bridge
  with 00:1f.0.
* Don't pass vendor/device ids in igd_pci_read().
* Add to support offset 0x44/0x48.
* Just rebase.

v4:

* Fix some typos in the patch head description.
* Improve some comments.
* Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
  are called unconditionally, so we just return 0 there.
* Remove one spurious change.
* Remove some unnecessary "return" in void foo().
* Given that pci_create_pch() is called unconditionally, so we just return 0
  even if its failed to check xen_has_gfx_passthru.
* Use (xen_enabled() && xen_has_gfx_passthru) to make sure we only work
  in this scenario.

v3:

* In this case, as we discussed we will give priority to devices to
  reserve a specific devfn by passing
  "device_model_args_hvm = ['-device', 'xen-platform,addr=0x3']" and
  "vga=none", so withdraw patch #1, #2 and #4.
* Fix some typos.
* Add more comments to make that readable.
* To unmap igd_opregion when call xen_pt_unregister_vga_regions().
* Improve some return paths.
* Force to convert igd_guest/host_opoegion as an unsigned long type
  while calling xc_domain_memory_mapping().
* We need to map 3 pages for opregion as hvmloader set.

v2:

* rebase on current qemu tree.
* retrieve VGA bios from sysfs properly.
* redefine some function name.
* introduce bitmap to manage registe/runregister pci dev, and provide
  a common way to reserve some specific devfn.
* introduce is_igd_passthrough() to make sure we touch physical host
  bridge only in IGD case.
* We should return zero as an invalid address value while calling
  igd_read_opregion().

Additionally, now its also not necessary to recompile seabios with some
extra steps like v1.
 

The following patches are ported partially from Xen Qemu-traditional
branch which are adding Intel IGD passthrough supporting to Qemu upstream.

To pass through IGD to guest, user need to add following lines in Xen
config file:
gfx_passthru=1
pci=['00:02.0@2']

Now successfully boot Ubuntu 14.04/Windows 7 guests with IGD assigned in
Haswell desktop with Latest Xen + Qemu upstream.

----------------------------------------------------------------
Tiejun Chen (5):
      xen, gfx passthrough: basic graphics passthrough support
      xen, gfx passthrough: create pseudo intel isa bridge
      xen, gfx passthrough: support Intel IGD passthrough with VT-D
      xen, gfx passthrough: create host bridge to passthrough
      xen, gfx passthrough: add opregion mapping

 hw/pci-host/piix.c           |  56 +++++++++++++++-
 hw/xen/Makefile.objs         |   2 +-
 hw/xen/xen-host-pci-device.c |   5 ++
 hw/xen/xen-host-pci-device.h |   1 +
 hw/xen/xen_pt.c              |  10 +++
 hw/xen/xen_pt.h              |  12 +++-
 hw/xen/xen_pt_config_init.c  |  50 +++++++++++++-
 hw/xen/xen_pt_graphics.c     | 513 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 qemu-options.hx              |   9 +++
 vl.c                         |  10 +++
 10 files changed, 663 insertions(+), 5 deletion

Thanks
Tiejun

[v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Tiejun Chen]

V5 is generated just based on Paolo's some comments.

v5:

* Don't set that ISA class property, instead, just fake this ISA bridge
  with 00:1f.0.
* Don't pass vendor/device ids in igd_pci_read().
* Add to support offset 0x44/0x48.
* Just rebase.

v4:

* Fix some typos in the patch head description.
* Improve some comments.
* Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
  are called unconditionally, so we just return 0 there.
* Remove one spurious change.
* Remove some unnecessary "return" in void foo().
* Given that pci_create_pch() is called unconditionally, so we just return 0
  even if its failed to check xen_has_gfx_passthru.
* Use (xen_enabled() && xen_has_gfx_passthru) to make sure we only work
  in this scenario.

v3:

* In this case, as we discussed we will give priority to devices to
  reserve a specific devfn by passing
  "device_model_args_hvm = ['-device', 'xen-platform,addr=0x3']" and
  "vga=none", so withdraw patch #1, #2 and #4.
* Fix some typos.
* Add more comments to make that readable.
* To unmap igd_opregion when call xen_pt_unregister_vga_regions().
* Improve some return paths.
* Force to convert igd_guest/host_opoegion as an unsigned long type
  while calling xc_domain_memory_mapping().
* We need to map 3 pages for opregion as hvmloader set.

v2:

* rebase on current qemu tree.
* retrieve VGA bios from sysfs properly.
* redefine some function name.
* introduce bitmap to manage registe/runregister pci dev, and provide
  a common way to reserve some specific devfn.
* introduce is_igd_passthrough() to make sure we touch physical host
  bridge only in IGD case.
* We should return zero as an invalid address value while calling
  igd_read_opregion().

Additionally, now its also not necessary to recompile seabios with some
extra steps like v1.
 

The following patches are ported partially from Xen Qemu-traditional
branch which are adding Intel IGD passthrough supporting to Qemu upstream.

To pass through IGD to guest, user need to add following lines in Xen
config file:
gfx_passthru=1
pci=['00:02.0@2']

Now successfully boot Ubuntu 14.04/Windows 7 guests with IGD assigned in
Haswell desktop with Latest Xen + Qemu upstream.

----------------------------------------------------------------
Tiejun Chen (5):
      xen, gfx passthrough: basic graphics passthrough support
      xen, gfx passthrough: create pseudo intel isa bridge
      xen, gfx passthrough: support Intel IGD passthrough with VT-D
      xen, gfx passthrough: create host bridge to passthrough
      xen, gfx passthrough: add opregion mapping

 hw/pci-host/piix.c           |  56 +++++++++++++++-
 hw/xen/Makefile.objs         |   2 +-
 hw/xen/xen-host-pci-device.c |   5 ++
 hw/xen/xen-host-pci-device.h |   1 +
 hw/xen/xen_pt.c              |  10 +++
 hw/xen/xen_pt.h              |  12 +++-
 hw/xen/xen_pt_config_init.c  |  50 +++++++++++++-
 hw/xen/xen_pt_graphics.c     | 513 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 qemu-options.hx              |   9 +++
 vl.c                         |  10 +++
 10 files changed, 663 insertions(+), 5 deletion

Thanks
Tiejun

[Qemu-devel] [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Tiejun Chen]

basic gfx passthrough support:
- add a vga type for gfx passthrough
- retrieve VGA bios from sysfs, then load it to guest at 0xC0000
- register/unregister legacy VGA I/O ports and MMIOs for passthrough GFX

The original patch is from Weidong Han <weidong.han@intel.com>

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Cc: Weidong Han <weidong.han@intel.com>
---
v5:

* Just rebase.

v4:

* Fix some typos in the patch head description.
* Improve some comments.
* Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
  are called unconditionally, so we just return 0 there.
* Remove one spurious change.

v3:

* Fix some typos.
* Add more comments to make that readable.
* Improve some return paths.

v2:

* retrieve VGA bios from sysfs properly.
* redefine some function name.

 hw/xen/Makefile.objs         |   2 +-
 hw/xen/xen-host-pci-device.c |   5 +
 hw/xen/xen-host-pci-device.h |   1 +
 hw/xen/xen_pt.c              |  10 ++
 hw/xen/xen_pt.h              |   4 +
 hw/xen/xen_pt_graphics.c     | 232 +++++++++++++++++++++++++++++++++++++++++++
 qemu-options.hx              |   9 ++
 vl.c                         |  10 ++
 8 files changed, 272 insertions(+), 1 deletion(-)
 create mode 100644 hw/xen/xen_pt_graphics.c

diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index a0ca0aa..77b7dae 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -2,4 +2,4 @@
 common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
 
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
-obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o xen_pt_graphics.o
diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index 743b37b..a54b7de 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -376,6 +376,11 @@ int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
         goto error;
     }
     d->irq = v;
+    rc = xen_host_pci_get_hex_value(d, "class", &v);
+    if (rc) {
+        goto error;
+    }
+    d->class_code = v;
     d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
 
     return 0;
diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
index c2486f0..f1e1c30 100644
--- a/hw/xen/xen-host-pci-device.h
+++ b/hw/xen/xen-host-pci-device.h
@@ -25,6 +25,7 @@ typedef struct XenHostPCIDevice {
 
     uint16_t vendor_id;
     uint16_t device_id;
+    uint32_t class_code;
     int irq;
 
     XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index be4220b..dac4238 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -450,6 +450,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
                    d->rom.size, d->rom.base_addr);
     }
 
+    xen_pt_register_vga_regions(d);
     return 0;
 }
 
@@ -470,6 +471,8 @@ static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
     if (d->rom.base_addr && d->rom.size) {
         memory_region_destroy(&s->rom);
     }
+
+    xen_pt_unregister_vga_regions(d);
 }
 
 /* region mapping */
@@ -693,6 +696,13 @@ static int xen_pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     xen_pt_register_regions(s);
 
+    /* Setup VGA bios for passthrough GFX */
+    if (xen_pt_setup_vga(&s->real_device) < 0) {
+        XEN_PT_ERR(d, "Setup VGA BIOS of passthrough GFX failed!\n");
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
     /* reinitialize each config register to be emulated */
     if (xen_pt_config_init(s)) {
         XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 942dc60..4d3a18d 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -298,5 +298,9 @@ static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
     return s->msix && s->msix->bar_index == bar;
 }
 
+extern int xen_has_gfx_passthru;
+int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
+int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
+int xen_pt_setup_vga(XenHostPCIDevice *dev);
 
 #endif /* !XEN_PT_H */
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
new file mode 100644
index 0000000..461e526
--- /dev/null
+++ b/hw/xen/xen_pt_graphics.c
@@ -0,0 +1,232 @@
+/*
+ * graphics passthrough
+ */
+#include "xen_pt.h"
+#include "xen-host-pci-device.h"
+#include "hw/xen/xen_backend.h"
+
+static int is_vga_passthrough(XenHostPCIDevice *dev)
+{
+    return (xen_has_gfx_passthru
+            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
+}
+
+typedef struct VGARegion {
+    int type;           /* Memory or port I/O */
+    uint64_t guest_base_addr;
+    uint64_t machine_base_addr;
+    uint64_t size;    /* size of the region */
+    int rc;
+} VGARegion;
+
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+
+static struct VGARegion vga_args[] = {
+    {
+        .type = IORESOURCE_IO,
+        .guest_base_addr = 0x3B0,
+        .machine_base_addr = 0x3B0,
+        .size = 0xC,
+        .rc = -1,
+    },
+    {
+        .type = IORESOURCE_IO,
+        .guest_base_addr = 0x3C0,
+        .machine_base_addr = 0x3C0,
+        .size = 0x20,
+        .rc = -1,
+    },
+    {
+        .type = IORESOURCE_MEM,
+        .guest_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
+        .machine_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
+        .size = 0x20,
+        .rc = -1,
+    },
+};
+
+/*
+ * register VGA resources for the domain with assigned gfx
+ */
+int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
+{
+    int i = 0;
+
+    if (!is_vga_passthrough(dev)) {
+        return 0;
+    }
+
+    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
+        if (vga_args[i].type == IORESOURCE_IO) {
+            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                            vga_args[i].guest_base_addr,
+                            vga_args[i].machine_base_addr,
+                            vga_args[i].size, DPCI_ADD_MAPPING);
+        } else {
+            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                            vga_args[i].guest_base_addr,
+                            vga_args[i].machine_base_addr,
+                            vga_args[i].size, DPCI_ADD_MAPPING);
+        }
+
+        if (vga_args[i].rc) {
+            XEN_PT_ERR(NULL, "VGA %s mapping failed! (rc: %i)\n",
+                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
+                    vga_args[i].rc);
+            return vga_args[i].rc;
+        }
+    }
+
+    return 0;
+}
+
+/*
+ * unregister VGA resources for the domain with assigned gfx
+ */
+int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
+{
+    int i = 0;
+
+    if (!is_vga_passthrough(dev)) {
+        return 0;
+    }
+
+    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
+        if (vga_args[i].type == IORESOURCE_IO) {
+            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                            vga_args[i].guest_base_addr,
+                            vga_args[i].machine_base_addr,
+                            vga_args[i].size, DPCI_REMOVE_MAPPING);
+        } else {
+            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                            vga_args[i].guest_base_addr,
+                            vga_args[i].machine_base_addr,
+                            vga_args[i].size, DPCI_REMOVE_MAPPING);
+        }
+
+        if (vga_args[i].rc) {
+            XEN_PT_ERR(NULL, "VGA %s unmapping failed! (rc: %i)\n",
+                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
+                    vga_args[i].rc);
+            return vga_args[i].rc;
+        }
+    }
+
+    return 0;
+}
+
+static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
+{
+    char rom_file[64];
+    FILE *fp;
+    uint8_t val;
+    struct stat st;
+    uint16_t magic = 0;
+    int ret = 0;
+
+    snprintf(rom_file, sizeof(rom_file),
+             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
+             dev->domain, dev->bus, dev->dev,
+             dev->func);
+
+    if (stat(rom_file, &st)) {
+        return -ENODEV;
+    }
+
+    if (access(rom_file, F_OK)) {
+        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
+                    rom_file);
+        return -ENODEV;
+    }
+
+    /* Write "1" to the ROM file to enable it */
+    fp = fopen(rom_file, "r+");
+    if (fp == NULL) {
+        return -EACCES;
+    }
+    val = 1;
+    if (fwrite(&val, 1, 1, fp) != 1) {
+        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
+        ret = -EIO;
+        goto close_rom;
+    }
+    fseek(fp, 0, SEEK_SET);
+
+    /*
+     * Check if it a real bios extension.
+     * The magic number is 0xAA55.
+     */
+    if (!fread(&magic, sizeof(magic), 1, fp)) {
+        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
+        ret = -ENODEV;
+        goto close_rom;
+    }
+    if (magic != 0xAA55) {
+        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
+        ret = -ENODEV;
+        goto close_rom;
+    }
+    fseek(fp, 0, SEEK_SET);
+
+    if (!fread(buf, 1, st.st_size, fp)) {
+        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s", rom_file);
+        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are probably invalid "
+                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
+                     "or load from file with romfile=\n");
+    }
+
+close_rom:
+    /* Write "0" to disable ROM */
+    fseek(fp, 0, SEEK_SET);
+    val = 0;
+    if (!fwrite(&val, 1, 1, fp)) {
+        ret = -EIO;
+        XEN_PT_LOG("%s\n", "Failed to disable pci-sysfs rom file");
+    }
+    fclose(fp);
+    return ret;
+}
+
+/* Allocated 128K for the vga bios */
+#define VGA_BIOS_DEFAULT_SIZE (0x20000)
+
+int xen_pt_setup_vga(XenHostPCIDevice *dev)
+{
+    unsigned char *bios = NULL;
+    int bios_size = 0;
+    char *c = NULL;
+    char checksum = 0;
+    int rc = 0;
+
+    if (!is_vga_passthrough(dev)) {
+        return rc;
+    }
+
+    bios = g_malloc0(VGA_BIOS_DEFAULT_SIZE);
+
+    bios_size = get_vgabios(bios, dev);
+    if (bios_size) {
+        XEN_PT_ERR(NULL, "VGA: Error %d getting VBIOS!\n", bios_size);
+        if (bios_size < 0) {
+            XEN_PT_ERR(NULL, "VGA: Error (%s).\n", strerror(bios_size));
+        }
+        rc = -1;
+        goto out;
+    }
+
+    /* Adjust the bios checksum */
+    for (c = (char *)bios; c < ((char *)bios + bios_size); c++) {
+        checksum += *c;
+    }
+    if (checksum) {
+        bios[bios_size - 1] -= checksum;
+        XEN_PT_LOG(NULL, "vga bios checksum is adjusted!\n");
+    }
+
+    /* Currently we fixed this address as a primary. */
+    cpu_physical_memory_rw(0xc0000, bios, bios_size, 1);
+out:
+    g_free(bios);
+    return rc;
+}
diff --git a/qemu-options.hx b/qemu-options.hx
index ff76ad4..1c77baa 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1066,6 +1066,15 @@ STEXI
 Rotate graphical output some deg left (only PXA LCD).
 ETEXI
 
+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
+
 DEF("vga", HAS_ARG, QEMU_OPTION_vga,
     "-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|none]\n"
     "                select video card type\n", QEMU_ARCH_ALL)
diff --git a/vl.c b/vl.c
index a1686ef..c5b572d 100644
--- a/vl.c
+++ b/vl.c
@@ -1418,6 +1418,13 @@ static void configure_msg(QemuOpts *opts)
     enable_timestamp_msg = qemu_opt_get_bool(opts, "timestamp", true);
 }
 
+/* We still need this for compatibility with XEN. */
+int xen_has_gfx_passthru;
+static void xen_gfx_passthru(const char *optarg)
+{
+    xen_has_gfx_passthru = 1;
+}
+
 /***********************************************************/
 /* USB devices */
 
@@ -3945,6 +3952,9 @@ int main(int argc, char **argv, char **envp)
                     exit(1);
                 }
                 break;
+            case QEMU_OPTION_gfx_passthru:
+                xen_gfx_passthru(optarg);
+                break;
             default:
                 os_parse_cmd_args(popt->index, optarg);
             }
-- 
1.9.1

[v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Tiejun Chen]

basic gfx passthrough support:
- add a vga type for gfx passthrough
- retrieve VGA bios from sysfs, then load it to guest at 0xC0000
- register/unregister legacy VGA I/O ports and MMIOs for passthrough GFX

The original patch is from Weidong Han <weidong.han@intel.com>

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Cc: Weidong Han <weidong.han@intel.com>
---
v5:

* Just rebase.

v4:

* Fix some typos in the patch head description.
* Improve some comments.
* Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
  are called unconditionally, so we just return 0 there.
* Remove one spurious change.

v3:

* Fix some typos.
* Add more comments to make that readable.
* Improve some return paths.

v2:

* retrieve VGA bios from sysfs properly.
* redefine some function name.

 hw/xen/Makefile.objs         |   2 +-
 hw/xen/xen-host-pci-device.c |   5 +
 hw/xen/xen-host-pci-device.h |   1 +
 hw/xen/xen_pt.c              |  10 ++
 hw/xen/xen_pt.h              |   4 +
 hw/xen/xen_pt_graphics.c     | 232 +++++++++++++++++++++++++++++++++++++++++++
 qemu-options.hx              |   9 ++
 vl.c                         |  10 ++
 8 files changed, 272 insertions(+), 1 deletion(-)
 create mode 100644 hw/xen/xen_pt_graphics.c

diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index a0ca0aa..77b7dae 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -2,4 +2,4 @@
 common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
 
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
-obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o xen_pt_graphics.o
diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index 743b37b..a54b7de 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -376,6 +376,11 @@ int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
         goto error;
     }
     d->irq = v;
+    rc = xen_host_pci_get_hex_value(d, "class", &v);
+    if (rc) {
+        goto error;
+    }
+    d->class_code = v;
     d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
 
     return 0;
diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
index c2486f0..f1e1c30 100644
--- a/hw/xen/xen-host-pci-device.h
+++ b/hw/xen/xen-host-pci-device.h
@@ -25,6 +25,7 @@ typedef struct XenHostPCIDevice {
 
     uint16_t vendor_id;
     uint16_t device_id;
+    uint32_t class_code;
     int irq;
 
     XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index be4220b..dac4238 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -450,6 +450,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
                    d->rom.size, d->rom.base_addr);
     }
 
+    xen_pt_register_vga_regions(d);
     return 0;
 }
 
@@ -470,6 +471,8 @@ static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
     if (d->rom.base_addr && d->rom.size) {
         memory_region_destroy(&s->rom);
     }
+
+    xen_pt_unregister_vga_regions(d);
 }
 
 /* region mapping */
@@ -693,6 +696,13 @@ static int xen_pt_initfn(PCIDevice *d)
     /* Handle real device's MMIO/PIO BARs */
     xen_pt_register_regions(s);
 
+    /* Setup VGA bios for passthrough GFX */
+    if (xen_pt_setup_vga(&s->real_device) < 0) {
+        XEN_PT_ERR(d, "Setup VGA BIOS of passthrough GFX failed!\n");
+        xen_host_pci_device_put(&s->real_device);
+        return -1;
+    }
+
     /* reinitialize each config register to be emulated */
     if (xen_pt_config_init(s)) {
         XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 942dc60..4d3a18d 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -298,5 +298,9 @@ static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
     return s->msix && s->msix->bar_index == bar;
 }
 
+extern int xen_has_gfx_passthru;
+int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
+int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
+int xen_pt_setup_vga(XenHostPCIDevice *dev);
 
 #endif /* !XEN_PT_H */
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
new file mode 100644
index 0000000..461e526
--- /dev/null
+++ b/hw/xen/xen_pt_graphics.c
@@ -0,0 +1,232 @@
+/*
+ * graphics passthrough
+ */
+#include "xen_pt.h"
+#include "xen-host-pci-device.h"
+#include "hw/xen/xen_backend.h"
+
+static int is_vga_passthrough(XenHostPCIDevice *dev)
+{
+    return (xen_has_gfx_passthru
+            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
+}
+
+typedef struct VGARegion {
+    int type;           /* Memory or port I/O */
+    uint64_t guest_base_addr;
+    uint64_t machine_base_addr;
+    uint64_t size;    /* size of the region */
+    int rc;
+} VGARegion;
+
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+
+static struct VGARegion vga_args[] = {
+    {
+        .type = IORESOURCE_IO,
+        .guest_base_addr = 0x3B0,
+        .machine_base_addr = 0x3B0,
+        .size = 0xC,
+        .rc = -1,
+    },
+    {
+        .type = IORESOURCE_IO,
+        .guest_base_addr = 0x3C0,
+        .machine_base_addr = 0x3C0,
+        .size = 0x20,
+        .rc = -1,
+    },
+    {
+        .type = IORESOURCE_MEM,
+        .guest_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
+        .machine_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
+        .size = 0x20,
+        .rc = -1,
+    },
+};
+
+/*
+ * register VGA resources for the domain with assigned gfx
+ */
+int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
+{
+    int i = 0;
+
+    if (!is_vga_passthrough(dev)) {
+        return 0;
+    }
+
+    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
+        if (vga_args[i].type == IORESOURCE_IO) {
+            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                            vga_args[i].guest_base_addr,
+                            vga_args[i].machine_base_addr,
+                            vga_args[i].size, DPCI_ADD_MAPPING);
+        } else {
+            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                            vga_args[i].guest_base_addr,
+                            vga_args[i].machine_base_addr,
+                            vga_args[i].size, DPCI_ADD_MAPPING);
+        }
+
+        if (vga_args[i].rc) {
+            XEN_PT_ERR(NULL, "VGA %s mapping failed! (rc: %i)\n",
+                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
+                    vga_args[i].rc);
+            return vga_args[i].rc;
+        }
+    }
+
+    return 0;
+}
+
+/*
+ * unregister VGA resources for the domain with assigned gfx
+ */
+int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
+{
+    int i = 0;
+
+    if (!is_vga_passthrough(dev)) {
+        return 0;
+    }
+
+    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
+        if (vga_args[i].type == IORESOURCE_IO) {
+            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                            vga_args[i].guest_base_addr,
+                            vga_args[i].machine_base_addr,
+                            vga_args[i].size, DPCI_REMOVE_MAPPING);
+        } else {
+            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                            vga_args[i].guest_base_addr,
+                            vga_args[i].machine_base_addr,
+                            vga_args[i].size, DPCI_REMOVE_MAPPING);
+        }
+
+        if (vga_args[i].rc) {
+            XEN_PT_ERR(NULL, "VGA %s unmapping failed! (rc: %i)\n",
+                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
+                    vga_args[i].rc);
+            return vga_args[i].rc;
+        }
+    }
+
+    return 0;
+}
+
+static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
+{
+    char rom_file[64];
+    FILE *fp;
+    uint8_t val;
+    struct stat st;
+    uint16_t magic = 0;
+    int ret = 0;
+
+    snprintf(rom_file, sizeof(rom_file),
+             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
+             dev->domain, dev->bus, dev->dev,
+             dev->func);
+
+    if (stat(rom_file, &st)) {
+        return -ENODEV;
+    }
+
+    if (access(rom_file, F_OK)) {
+        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
+                    rom_file);
+        return -ENODEV;
+    }
+
+    /* Write "1" to the ROM file to enable it */
+    fp = fopen(rom_file, "r+");
+    if (fp == NULL) {
+        return -EACCES;
+    }
+    val = 1;
+    if (fwrite(&val, 1, 1, fp) != 1) {
+        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
+        ret = -EIO;
+        goto close_rom;
+    }
+    fseek(fp, 0, SEEK_SET);
+
+    /*
+     * Check if it a real bios extension.
+     * The magic number is 0xAA55.
+     */
+    if (!fread(&magic, sizeof(magic), 1, fp)) {
+        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
+        ret = -ENODEV;
+        goto close_rom;
+    }
+    if (magic != 0xAA55) {
+        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
+        ret = -ENODEV;
+        goto close_rom;
+    }
+    fseek(fp, 0, SEEK_SET);
+
+    if (!fread(buf, 1, st.st_size, fp)) {
+        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s", rom_file);
+        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are probably invalid "
+                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
+                     "or load from file with romfile=\n");
+    }
+
+close_rom:
+    /* Write "0" to disable ROM */
+    fseek(fp, 0, SEEK_SET);
+    val = 0;
+    if (!fwrite(&val, 1, 1, fp)) {
+        ret = -EIO;
+        XEN_PT_LOG("%s\n", "Failed to disable pci-sysfs rom file");
+    }
+    fclose(fp);
+    return ret;
+}
+
+/* Allocated 128K for the vga bios */
+#define VGA_BIOS_DEFAULT_SIZE (0x20000)
+
+int xen_pt_setup_vga(XenHostPCIDevice *dev)
+{
+    unsigned char *bios = NULL;
+    int bios_size = 0;
+    char *c = NULL;
+    char checksum = 0;
+    int rc = 0;
+
+    if (!is_vga_passthrough(dev)) {
+        return rc;
+    }
+
+    bios = g_malloc0(VGA_BIOS_DEFAULT_SIZE);
+
+    bios_size = get_vgabios(bios, dev);
+    if (bios_size) {
+        XEN_PT_ERR(NULL, "VGA: Error %d getting VBIOS!\n", bios_size);
+        if (bios_size < 0) {
+            XEN_PT_ERR(NULL, "VGA: Error (%s).\n", strerror(bios_size));
+        }
+        rc = -1;
+        goto out;
+    }
+
+    /* Adjust the bios checksum */
+    for (c = (char *)bios; c < ((char *)bios + bios_size); c++) {
+        checksum += *c;
+    }
+    if (checksum) {
+        bios[bios_size - 1] -= checksum;
+        XEN_PT_LOG(NULL, "vga bios checksum is adjusted!\n");
+    }
+
+    /* Currently we fixed this address as a primary. */
+    cpu_physical_memory_rw(0xc0000, bios, bios_size, 1);
+out:
+    g_free(bios);
+    return rc;
+}
diff --git a/qemu-options.hx b/qemu-options.hx
index ff76ad4..1c77baa 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1066,6 +1066,15 @@ STEXI
 Rotate graphical output some deg left (only PXA LCD).
 ETEXI
 
+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
+
 DEF("vga", HAS_ARG, QEMU_OPTION_vga,
     "-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|none]\n"
     "                select video card type\n", QEMU_ARCH_ALL)
diff --git a/vl.c b/vl.c
index a1686ef..c5b572d 100644
--- a/vl.c
+++ b/vl.c
@@ -1418,6 +1418,13 @@ static void configure_msg(QemuOpts *opts)
     enable_timestamp_msg = qemu_opt_get_bool(opts, "timestamp", true);
 }
 
+/* We still need this for compatibility with XEN. */
+int xen_has_gfx_passthru;
+static void xen_gfx_passthru(const char *optarg)
+{
+    xen_has_gfx_passthru = 1;
+}
+
 /***********************************************************/
 /* USB devices */
 
@@ -3945,6 +3952,9 @@ int main(int argc, char **argv, char **envp)
                     exit(1);
                 }
                 break;
+            case QEMU_OPTION_gfx_passthru:
+                xen_gfx_passthru(optarg);
+                break;
             default:
                 os_parse_cmd_args(popt->index, optarg);
             }
-- 
1.9.1

Re: [Qemu-devel] [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Paolo Bonzini]

Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> +static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
> +{
> +    char rom_file[64];
> +    FILE *fp;
> +    uint8_t val;
> +    struct stat st;
> +    uint16_t magic = 0;
> +    int ret = 0;
> +
> +    snprintf(rom_file, sizeof(rom_file),
> +             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
> +             dev->domain, dev->bus, dev->dev,
> +             dev->func);
> +
> +    if (stat(rom_file, &st)) {
> +        return -ENODEV;
> +    }
> +
> +    if (access(rom_file, F_OK)) {
> +        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
> +                    rom_file);
> +        return -ENODEV;
> +    }

These two checks (stat and access) are useless.

> +    /* Write "1" to the ROM file to enable it */
> +    fp = fopen(rom_file, "r+");
> +    if (fp == NULL) {
> +        return -EACCES;
> +    }
> +    val = 1;
> +    if (fwrite(&val, 1, 1, fp) != 1) {
> +        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
> +        ret = -EIO;
> +        goto close_rom;
> +    }
> +    fseek(fp, 0, SEEK_SET);
> +
> +    /*
> +     * Check if it a real bios extension.
> +     * The magic number is 0xAA55.
> +     */
> +    if (!fread(&magic, sizeof(magic), 1, fp)) {
> +        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
> +        ret = -ENODEV;
> +        goto close_rom;
> +    }
> +    if (magic != 0xAA55) {
> +        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
> +        ret = -ENODEV;
> +        goto close_rom;
> +    }
> +    fseek(fp, 0, SEEK_SET);
> +
> +    if (!fread(buf, 1, st.st_size, fp)) {
> +        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s", rom_file);
> +        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are probably invalid "
> +                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
> +                     "or load from file with romfile=\n");
> +    }
> +

Why is this graphics passthrough specific?  Should QEMU's Xen PCI 
passthrough read ROM BAR contents from network cards too, for example?

Paolo

Re: [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Paolo Bonzini]

Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> +static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
> +{
> +    char rom_file[64];
> +    FILE *fp;
> +    uint8_t val;
> +    struct stat st;
> +    uint16_t magic = 0;
> +    int ret = 0;
> +
> +    snprintf(rom_file, sizeof(rom_file),
> +             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
> +             dev->domain, dev->bus, dev->dev,
> +             dev->func);
> +
> +    if (stat(rom_file, &st)) {
> +        return -ENODEV;
> +    }
> +
> +    if (access(rom_file, F_OK)) {
> +        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
> +                    rom_file);
> +        return -ENODEV;
> +    }

These two checks (stat and access) are useless.

> +    /* Write "1" to the ROM file to enable it */
> +    fp = fopen(rom_file, "r+");
> +    if (fp == NULL) {
> +        return -EACCES;
> +    }
> +    val = 1;
> +    if (fwrite(&val, 1, 1, fp) != 1) {
> +        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
> +        ret = -EIO;
> +        goto close_rom;
> +    }
> +    fseek(fp, 0, SEEK_SET);
> +
> +    /*
> +     * Check if it a real bios extension.
> +     * The magic number is 0xAA55.
> +     */
> +    if (!fread(&magic, sizeof(magic), 1, fp)) {
> +        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
> +        ret = -ENODEV;
> +        goto close_rom;
> +    }
> +    if (magic != 0xAA55) {
> +        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
> +        ret = -ENODEV;
> +        goto close_rom;
> +    }
> +    fseek(fp, 0, SEEK_SET);
> +
> +    if (!fread(buf, 1, st.st_size, fp)) {
> +        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s", rom_file);
> +        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are probably invalid "
> +                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
> +                     "or load from file with romfile=\n");
> +    }
> +

Why is this graphics passthrough specific?  Should QEMU's Xen PCI 
passthrough read ROM BAR contents from network cards too, for example?

Paolo

Re: [Qemu-devel] [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Chen, Tiejun]

On 2014/6/25 14:21, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> +static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
>> +{
>> +    char rom_file[64];
>> +    FILE *fp;
>> +    uint8_t val;
>> +    struct stat st;
>> +    uint16_t magic = 0;
>> +    int ret = 0;
>> +
>> +    snprintf(rom_file, sizeof(rom_file),
>> +             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
>> +             dev->domain, dev->bus, dev->dev,
>> +             dev->func);
>> +
>> +    if (stat(rom_file, &st)) {
>> +        return -ENODEV;
>> +    }
>> +
>> +    if (access(rom_file, F_OK)) {
>> +        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
>> +                    rom_file);
>> +        return -ENODEV;
>> +    }
>
> These two checks (stat and access) are useless.

Will remove this.

>
>> +    /* Write "1" to the ROM file to enable it */
>> +    fp = fopen(rom_file, "r+");
>> +    if (fp == NULL) {
>> +        return -EACCES;
>> +    }
>> +    val = 1;
>> +    if (fwrite(&val, 1, 1, fp) != 1) {
>> +        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
>> +        ret = -EIO;
>> +        goto close_rom;
>> +    }
>> +    fseek(fp, 0, SEEK_SET);
>> +
>> +    /*
>> +     * Check if it a real bios extension.
>> +     * The magic number is 0xAA55.
>> +     */
>> +    if (!fread(&magic, sizeof(magic), 1, fp)) {
>> +        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
>> +        ret = -ENODEV;
>> +        goto close_rom;
>> +    }
>> +    if (magic != 0xAA55) {
>> +        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
>> +        ret = -ENODEV;
>> +        goto close_rom;
>> +    }
>> +    fseek(fp, 0, SEEK_SET);
>> +
>> +    if (!fread(buf, 1, st.st_size, fp)) {
>> +        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s",
>> rom_file);
>> +        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are
>> probably invalid "
>> +                     "(check dmesg).\nSkip option ROM probe with
>> rombar=0, "
>> +                     "or load from file with romfile=\n");
>> +    }
>> +
>
> Why is this graphics passthrough specific?  Should QEMU's Xen PCI
> passthrough read ROM BAR contents from network cards too, for example?
>

I think this should not be same simply since we need to call VBIOS from 
RAM, not a ROM BAR of the device.

Thanks
Tiejun

Re: [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Chen, Tiejun]

On 2014/6/25 14:21, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> +static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
>> +{
>> +    char rom_file[64];
>> +    FILE *fp;
>> +    uint8_t val;
>> +    struct stat st;
>> +    uint16_t magic = 0;
>> +    int ret = 0;
>> +
>> +    snprintf(rom_file, sizeof(rom_file),
>> +             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
>> +             dev->domain, dev->bus, dev->dev,
>> +             dev->func);
>> +
>> +    if (stat(rom_file, &st)) {
>> +        return -ENODEV;
>> +    }
>> +
>> +    if (access(rom_file, F_OK)) {
>> +        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
>> +                    rom_file);
>> +        return -ENODEV;
>> +    }
>
> These two checks (stat and access) are useless.

Will remove this.

>
>> +    /* Write "1" to the ROM file to enable it */
>> +    fp = fopen(rom_file, "r+");
>> +    if (fp == NULL) {
>> +        return -EACCES;
>> +    }
>> +    val = 1;
>> +    if (fwrite(&val, 1, 1, fp) != 1) {
>> +        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
>> +        ret = -EIO;
>> +        goto close_rom;
>> +    }
>> +    fseek(fp, 0, SEEK_SET);
>> +
>> +    /*
>> +     * Check if it a real bios extension.
>> +     * The magic number is 0xAA55.
>> +     */
>> +    if (!fread(&magic, sizeof(magic), 1, fp)) {
>> +        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
>> +        ret = -ENODEV;
>> +        goto close_rom;
>> +    }
>> +    if (magic != 0xAA55) {
>> +        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
>> +        ret = -ENODEV;
>> +        goto close_rom;
>> +    }
>> +    fseek(fp, 0, SEEK_SET);
>> +
>> +    if (!fread(buf, 1, st.st_size, fp)) {
>> +        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s",
>> rom_file);
>> +        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are
>> probably invalid "
>> +                     "(check dmesg).\nSkip option ROM probe with
>> rombar=0, "
>> +                     "or load from file with romfile=\n");
>> +    }
>> +
>
> Why is this graphics passthrough specific?  Should QEMU's Xen PCI
> passthrough read ROM BAR contents from network cards too, for example?
>

I think this should not be same simply since we need to call VBIOS from 
RAM, not a ROM BAR of the device.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:17:17AM +0800, Tiejun Chen wrote:
> basic gfx passthrough support:
> - add a vga type for gfx passthrough
> - retrieve VGA bios from sysfs, then load it to guest at 0xC0000
> - register/unregister legacy VGA I/O ports and MMIOs for passthrough GFX
> 
> The original patch is from Weidong Han <weidong.han@intel.com>
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> Cc: Weidong Han <weidong.han@intel.com>

ROM loading code is duplicated from assigned_dev_load_option_rom.
Would it be a problem for you to create a memory region holding
the ROM?
You won't need cpu_physical_memory_rw then, either, or need
the VGA_BIOS_DEFAULT_SIZE hack.




> ---
> v5:
> 
> * Just rebase.
> 
> v4:
> 
> * Fix some typos in the patch head description.
> * Improve some comments.
> * Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
>   are called unconditionally, so we just return 0 there.
> * Remove one spurious change.
> 
> v3:
> 
> * Fix some typos.
> * Add more comments to make that readable.
> * Improve some return paths.
> 
> v2:
> 
> * retrieve VGA bios from sysfs properly.
> * redefine some function name.
> 
>  hw/xen/Makefile.objs         |   2 +-
>  hw/xen/xen-host-pci-device.c |   5 +
>  hw/xen/xen-host-pci-device.h |   1 +
>  hw/xen/xen_pt.c              |  10 ++
>  hw/xen/xen_pt.h              |   4 +
>  hw/xen/xen_pt_graphics.c     | 232 +++++++++++++++++++++++++++++++++++++++++++
>  qemu-options.hx              |   9 ++
>  vl.c                         |  10 ++
>  8 files changed, 272 insertions(+), 1 deletion(-)
>  create mode 100644 hw/xen/xen_pt_graphics.c
> 
> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> index a0ca0aa..77b7dae 100644
> --- a/hw/xen/Makefile.objs
> +++ b/hw/xen/Makefile.objs
> @@ -2,4 +2,4 @@
>  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
>  
>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> -obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
> +obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o xen_pt_graphics.o
> diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
> index 743b37b..a54b7de 100644
> --- a/hw/xen/xen-host-pci-device.c
> +++ b/hw/xen/xen-host-pci-device.c
> @@ -376,6 +376,11 @@ int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
>          goto error;
>      }
>      d->irq = v;
> +    rc = xen_host_pci_get_hex_value(d, "class", &v);
> +    if (rc) {
> +        goto error;
> +    }
> +    d->class_code = v;
>      d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
>  
>      return 0;
> diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
> index c2486f0..f1e1c30 100644
> --- a/hw/xen/xen-host-pci-device.h
> +++ b/hw/xen/xen-host-pci-device.h
> @@ -25,6 +25,7 @@ typedef struct XenHostPCIDevice {
>  
>      uint16_t vendor_id;
>      uint16_t device_id;
> +    uint32_t class_code;
>      int irq;
>  
>      XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> index be4220b..dac4238 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -450,6 +450,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
>                     d->rom.size, d->rom.base_addr);
>      }
>  
> +    xen_pt_register_vga_regions(d);
>      return 0;
>  }
>  
> @@ -470,6 +471,8 @@ static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
>      if (d->rom.base_addr && d->rom.size) {
>          memory_region_destroy(&s->rom);
>      }
> +
> +    xen_pt_unregister_vga_regions(d);
>  }
>  
>  /* region mapping */
> @@ -693,6 +696,13 @@ static int xen_pt_initfn(PCIDevice *d)
>      /* Handle real device's MMIO/PIO BARs */
>      xen_pt_register_regions(s);
>  
> +    /* Setup VGA bios for passthrough GFX */
> +    if (xen_pt_setup_vga(&s->real_device) < 0) {
> +        XEN_PT_ERR(d, "Setup VGA BIOS of passthrough GFX failed!\n");
> +        xen_host_pci_device_put(&s->real_device);
> +        return -1;
> +    }
> +
>      /* reinitialize each config register to be emulated */
>      if (xen_pt_config_init(s)) {
>          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 942dc60..4d3a18d 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -298,5 +298,9 @@ static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
>      return s->msix && s->msix->bar_index == bar;
>  }
>  
> +extern int xen_has_gfx_passthru;
> +int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
> +int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
> +int xen_pt_setup_vga(XenHostPCIDevice *dev);
>  
>  #endif /* !XEN_PT_H */
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> new file mode 100644
> index 0000000..461e526
> --- /dev/null
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -0,0 +1,232 @@
> +/*
> + * graphics passthrough
> + */
> +#include "xen_pt.h"
> +#include "xen-host-pci-device.h"
> +#include "hw/xen/xen_backend.h"
> +
> +static int is_vga_passthrough(XenHostPCIDevice *dev)
> +{
> +    return (xen_has_gfx_passthru
> +            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
> +}
> +
> +typedef struct VGARegion {
> +    int type;           /* Memory or port I/O */
> +    uint64_t guest_base_addr;
> +    uint64_t machine_base_addr;
> +    uint64_t size;    /* size of the region */
> +    int rc;
> +} VGARegion;
> +
> +#define IORESOURCE_IO           0x00000100
> +#define IORESOURCE_MEM          0x00000200
> +
> +static struct VGARegion vga_args[] = {
> +    {
> +        .type = IORESOURCE_IO,
> +        .guest_base_addr = 0x3B0,
> +        .machine_base_addr = 0x3B0,
> +        .size = 0xC,
> +        .rc = -1,
> +    },
> +    {
> +        .type = IORESOURCE_IO,
> +        .guest_base_addr = 0x3C0,
> +        .machine_base_addr = 0x3C0,
> +        .size = 0x20,
> +        .rc = -1,
> +    },
> +    {
> +        .type = IORESOURCE_MEM,
> +        .guest_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
> +        .machine_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
> +        .size = 0x20,
> +        .rc = -1,
> +    },
> +};
> +
> +/*
> + * register VGA resources for the domain with assigned gfx
> + */
> +int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
> +{
> +    int i = 0;
> +
> +    if (!is_vga_passthrough(dev)) {
> +        return 0;
> +    }
> +
> +    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
> +        if (vga_args[i].type == IORESOURCE_IO) {
> +            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
> +                            vga_args[i].guest_base_addr,
> +                            vga_args[i].machine_base_addr,
> +                            vga_args[i].size, DPCI_ADD_MAPPING);
> +        } else {
> +            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                            vga_args[i].guest_base_addr,
> +                            vga_args[i].machine_base_addr,
> +                            vga_args[i].size, DPCI_ADD_MAPPING);
> +        }
> +
> +        if (vga_args[i].rc) {
> +            XEN_PT_ERR(NULL, "VGA %s mapping failed! (rc: %i)\n",
> +                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
> +                    vga_args[i].rc);
> +            return vga_args[i].rc;
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/*
> + * unregister VGA resources for the domain with assigned gfx
> + */
> +int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
> +{
> +    int i = 0;
> +
> +    if (!is_vga_passthrough(dev)) {
> +        return 0;
> +    }
> +
> +    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
> +        if (vga_args[i].type == IORESOURCE_IO) {
> +            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
> +                            vga_args[i].guest_base_addr,
> +                            vga_args[i].machine_base_addr,
> +                            vga_args[i].size, DPCI_REMOVE_MAPPING);
> +        } else {
> +            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                            vga_args[i].guest_base_addr,
> +                            vga_args[i].machine_base_addr,
> +                            vga_args[i].size, DPCI_REMOVE_MAPPING);
> +        }
> +
> +        if (vga_args[i].rc) {
> +            XEN_PT_ERR(NULL, "VGA %s unmapping failed! (rc: %i)\n",
> +                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
> +                    vga_args[i].rc);
> +            return vga_args[i].rc;
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
> +{
> +    char rom_file[64];
> +    FILE *fp;
> +    uint8_t val;
> +    struct stat st;
> +    uint16_t magic = 0;
> +    int ret = 0;
> +
> +    snprintf(rom_file, sizeof(rom_file),
> +             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
> +             dev->domain, dev->bus, dev->dev,
> +             dev->func);
> +
> +    if (stat(rom_file, &st)) {
> +        return -ENODEV;
> +    }
> +
> +    if (access(rom_file, F_OK)) {
> +        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
> +                    rom_file);
> +        return -ENODEV;
> +    }
> +
> +    /* Write "1" to the ROM file to enable it */
> +    fp = fopen(rom_file, "r+");
> +    if (fp == NULL) {
> +        return -EACCES;
> +    }
> +    val = 1;
> +    if (fwrite(&val, 1, 1, fp) != 1) {
> +        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
> +        ret = -EIO;
> +        goto close_rom;
> +    }
> +    fseek(fp, 0, SEEK_SET);
> +
> +    /*
> +     * Check if it a real bios extension.
> +     * The magic number is 0xAA55.
> +     */
> +    if (!fread(&magic, sizeof(magic), 1, fp)) {
> +        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
> +        ret = -ENODEV;
> +        goto close_rom;
> +    }
> +    if (magic != 0xAA55) {
> +        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
> +        ret = -ENODEV;
> +        goto close_rom;
> +    }
> +    fseek(fp, 0, SEEK_SET);
> +
> +    if (!fread(buf, 1, st.st_size, fp)) {
> +        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s", rom_file);
> +        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are probably invalid "
> +                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
> +                     "or load from file with romfile=\n");
> +    }
> +
> +close_rom:
> +    /* Write "0" to disable ROM */
> +    fseek(fp, 0, SEEK_SET);
> +    val = 0;
> +    if (!fwrite(&val, 1, 1, fp)) {
> +        ret = -EIO;
> +        XEN_PT_LOG("%s\n", "Failed to disable pci-sysfs rom file");
> +    }
> +    fclose(fp);
> +    return ret;
> +}
> +
> +/* Allocated 128K for the vga bios */
> +#define VGA_BIOS_DEFAULT_SIZE (0x20000)
> +
> +int xen_pt_setup_vga(XenHostPCIDevice *dev)
> +{
> +    unsigned char *bios = NULL;
> +    int bios_size = 0;
> +    char *c = NULL;
> +    char checksum = 0;
> +    int rc = 0;
> +
> +    if (!is_vga_passthrough(dev)) {
> +        return rc;
> +    }
> +
> +    bios = g_malloc0(VGA_BIOS_DEFAULT_SIZE);
> +
> +    bios_size = get_vgabios(bios, dev);
> +    if (bios_size) {
> +        XEN_PT_ERR(NULL, "VGA: Error %d getting VBIOS!\n", bios_size);
> +        if (bios_size < 0) {
> +            XEN_PT_ERR(NULL, "VGA: Error (%s).\n", strerror(bios_size));
> +        }
> +        rc = -1;
> +        goto out;
> +    }
> +
> +    /* Adjust the bios checksum */

It's easy to see that you do this here, but *why* do you do it?
That's what the comment should explain.
Do you see many ROMs with an invalid checksum
in the field?

> +    for (c = (char *)bios; c < ((char *)bios + bios_size); c++) {
> +        checksum += *c;
> +    }
> +    if (checksum) {
> +        bios[bios_size - 1] -= checksum;
> +        XEN_PT_LOG(NULL, "vga bios checksum is adjusted!\n");
> +    }
> +
> +    /* Currently we fixed this address as a primary. */
> +    cpu_physical_memory_rw(0xc0000, bios, bios_size, 1);
> +out:
> +    g_free(bios);
> +    return rc;
> +}
> diff --git a/qemu-options.hx b/qemu-options.hx
> index ff76ad4..1c77baa 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1066,6 +1066,15 @@ STEXI
>  Rotate graphical output some deg left (only PXA LCD).
>  ETEXI
>  
> +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
> +
>  DEF("vga", HAS_ARG, QEMU_OPTION_vga,
>      "-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|none]\n"
>      "                select video card type\n", QEMU_ARCH_ALL)
> diff --git a/vl.c b/vl.c
> index a1686ef..c5b572d 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1418,6 +1418,13 @@ static void configure_msg(QemuOpts *opts)
>      enable_timestamp_msg = qemu_opt_get_bool(opts, "timestamp", true);
>  }
>  
> +/* We still need this for compatibility with XEN. */
> +int xen_has_gfx_passthru;
> +static void xen_gfx_passthru(const char *optarg)
> +{
> +    xen_has_gfx_passthru = 1;
> +}
> +
>  /***********************************************************/
>  /* USB devices */
>  
> @@ -3945,6 +3952,9 @@ int main(int argc, char **argv, char **envp)
>                      exit(1);
>                  }
>                  break;
> +            case QEMU_OPTION_gfx_passthru:
> +                xen_gfx_passthru(optarg);
> +                break;
>              default:
>                  os_parse_cmd_args(popt->index, optarg);
>              }
> -- 
> 1.9.1

Re: [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:17:17AM +0800, Tiejun Chen wrote:
> basic gfx passthrough support:
> - add a vga type for gfx passthrough
> - retrieve VGA bios from sysfs, then load it to guest at 0xC0000
> - register/unregister legacy VGA I/O ports and MMIOs for passthrough GFX
> 
> The original patch is from Weidong Han <weidong.han@intel.com>
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> Cc: Weidong Han <weidong.han@intel.com>

ROM loading code is duplicated from assigned_dev_load_option_rom.
Would it be a problem for you to create a memory region holding
the ROM?
You won't need cpu_physical_memory_rw then, either, or need
the VGA_BIOS_DEFAULT_SIZE hack.




> ---
> v5:
> 
> * Just rebase.
> 
> v4:
> 
> * Fix some typos in the patch head description.
> * Improve some comments.
> * Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
>   are called unconditionally, so we just return 0 there.
> * Remove one spurious change.
> 
> v3:
> 
> * Fix some typos.
> * Add more comments to make that readable.
> * Improve some return paths.
> 
> v2:
> 
> * retrieve VGA bios from sysfs properly.
> * redefine some function name.
> 
>  hw/xen/Makefile.objs         |   2 +-
>  hw/xen/xen-host-pci-device.c |   5 +
>  hw/xen/xen-host-pci-device.h |   1 +
>  hw/xen/xen_pt.c              |  10 ++
>  hw/xen/xen_pt.h              |   4 +
>  hw/xen/xen_pt_graphics.c     | 232 +++++++++++++++++++++++++++++++++++++++++++
>  qemu-options.hx              |   9 ++
>  vl.c                         |  10 ++
>  8 files changed, 272 insertions(+), 1 deletion(-)
>  create mode 100644 hw/xen/xen_pt_graphics.c
> 
> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> index a0ca0aa..77b7dae 100644
> --- a/hw/xen/Makefile.objs
> +++ b/hw/xen/Makefile.objs
> @@ -2,4 +2,4 @@
>  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
>  
>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> -obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
> +obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o xen_pt_graphics.o
> diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
> index 743b37b..a54b7de 100644
> --- a/hw/xen/xen-host-pci-device.c
> +++ b/hw/xen/xen-host-pci-device.c
> @@ -376,6 +376,11 @@ int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
>          goto error;
>      }
>      d->irq = v;
> +    rc = xen_host_pci_get_hex_value(d, "class", &v);
> +    if (rc) {
> +        goto error;
> +    }
> +    d->class_code = v;
>      d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
>  
>      return 0;
> diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
> index c2486f0..f1e1c30 100644
> --- a/hw/xen/xen-host-pci-device.h
> +++ b/hw/xen/xen-host-pci-device.h
> @@ -25,6 +25,7 @@ typedef struct XenHostPCIDevice {
>  
>      uint16_t vendor_id;
>      uint16_t device_id;
> +    uint32_t class_code;
>      int irq;
>  
>      XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> index be4220b..dac4238 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -450,6 +450,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
>                     d->rom.size, d->rom.base_addr);
>      }
>  
> +    xen_pt_register_vga_regions(d);
>      return 0;
>  }
>  
> @@ -470,6 +471,8 @@ static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
>      if (d->rom.base_addr && d->rom.size) {
>          memory_region_destroy(&s->rom);
>      }
> +
> +    xen_pt_unregister_vga_regions(d);
>  }
>  
>  /* region mapping */
> @@ -693,6 +696,13 @@ static int xen_pt_initfn(PCIDevice *d)
>      /* Handle real device's MMIO/PIO BARs */
>      xen_pt_register_regions(s);
>  
> +    /* Setup VGA bios for passthrough GFX */
> +    if (xen_pt_setup_vga(&s->real_device) < 0) {
> +        XEN_PT_ERR(d, "Setup VGA BIOS of passthrough GFX failed!\n");
> +        xen_host_pci_device_put(&s->real_device);
> +        return -1;
> +    }
> +
>      /* reinitialize each config register to be emulated */
>      if (xen_pt_config_init(s)) {
>          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 942dc60..4d3a18d 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -298,5 +298,9 @@ static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
>      return s->msix && s->msix->bar_index == bar;
>  }
>  
> +extern int xen_has_gfx_passthru;
> +int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
> +int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
> +int xen_pt_setup_vga(XenHostPCIDevice *dev);
>  
>  #endif /* !XEN_PT_H */
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> new file mode 100644
> index 0000000..461e526
> --- /dev/null
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -0,0 +1,232 @@
> +/*
> + * graphics passthrough
> + */
> +#include "xen_pt.h"
> +#include "xen-host-pci-device.h"
> +#include "hw/xen/xen_backend.h"
> +
> +static int is_vga_passthrough(XenHostPCIDevice *dev)
> +{
> +    return (xen_has_gfx_passthru
> +            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
> +}
> +
> +typedef struct VGARegion {
> +    int type;           /* Memory or port I/O */
> +    uint64_t guest_base_addr;
> +    uint64_t machine_base_addr;
> +    uint64_t size;    /* size of the region */
> +    int rc;
> +} VGARegion;
> +
> +#define IORESOURCE_IO           0x00000100
> +#define IORESOURCE_MEM          0x00000200
> +
> +static struct VGARegion vga_args[] = {
> +    {
> +        .type = IORESOURCE_IO,
> +        .guest_base_addr = 0x3B0,
> +        .machine_base_addr = 0x3B0,
> +        .size = 0xC,
> +        .rc = -1,
> +    },
> +    {
> +        .type = IORESOURCE_IO,
> +        .guest_base_addr = 0x3C0,
> +        .machine_base_addr = 0x3C0,
> +        .size = 0x20,
> +        .rc = -1,
> +    },
> +    {
> +        .type = IORESOURCE_MEM,
> +        .guest_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
> +        .machine_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
> +        .size = 0x20,
> +        .rc = -1,
> +    },
> +};
> +
> +/*
> + * register VGA resources for the domain with assigned gfx
> + */
> +int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
> +{
> +    int i = 0;
> +
> +    if (!is_vga_passthrough(dev)) {
> +        return 0;
> +    }
> +
> +    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
> +        if (vga_args[i].type == IORESOURCE_IO) {
> +            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
> +                            vga_args[i].guest_base_addr,
> +                            vga_args[i].machine_base_addr,
> +                            vga_args[i].size, DPCI_ADD_MAPPING);
> +        } else {
> +            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                            vga_args[i].guest_base_addr,
> +                            vga_args[i].machine_base_addr,
> +                            vga_args[i].size, DPCI_ADD_MAPPING);
> +        }
> +
> +        if (vga_args[i].rc) {
> +            XEN_PT_ERR(NULL, "VGA %s mapping failed! (rc: %i)\n",
> +                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
> +                    vga_args[i].rc);
> +            return vga_args[i].rc;
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +/*
> + * unregister VGA resources for the domain with assigned gfx
> + */
> +int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
> +{
> +    int i = 0;
> +
> +    if (!is_vga_passthrough(dev)) {
> +        return 0;
> +    }
> +
> +    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
> +        if (vga_args[i].type == IORESOURCE_IO) {
> +            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
> +                            vga_args[i].guest_base_addr,
> +                            vga_args[i].machine_base_addr,
> +                            vga_args[i].size, DPCI_REMOVE_MAPPING);
> +        } else {
> +            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                            vga_args[i].guest_base_addr,
> +                            vga_args[i].machine_base_addr,
> +                            vga_args[i].size, DPCI_REMOVE_MAPPING);
> +        }
> +
> +        if (vga_args[i].rc) {
> +            XEN_PT_ERR(NULL, "VGA %s unmapping failed! (rc: %i)\n",
> +                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
> +                    vga_args[i].rc);
> +            return vga_args[i].rc;
> +        }
> +    }
> +
> +    return 0;
> +}
> +
> +static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
> +{
> +    char rom_file[64];
> +    FILE *fp;
> +    uint8_t val;
> +    struct stat st;
> +    uint16_t magic = 0;
> +    int ret = 0;
> +
> +    snprintf(rom_file, sizeof(rom_file),
> +             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
> +             dev->domain, dev->bus, dev->dev,
> +             dev->func);
> +
> +    if (stat(rom_file, &st)) {
> +        return -ENODEV;
> +    }
> +
> +    if (access(rom_file, F_OK)) {
> +        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
> +                    rom_file);
> +        return -ENODEV;
> +    }
> +
> +    /* Write "1" to the ROM file to enable it */
> +    fp = fopen(rom_file, "r+");
> +    if (fp == NULL) {
> +        return -EACCES;
> +    }
> +    val = 1;
> +    if (fwrite(&val, 1, 1, fp) != 1) {
> +        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
> +        ret = -EIO;
> +        goto close_rom;
> +    }
> +    fseek(fp, 0, SEEK_SET);
> +
> +    /*
> +     * Check if it a real bios extension.
> +     * The magic number is 0xAA55.
> +     */
> +    if (!fread(&magic, sizeof(magic), 1, fp)) {
> +        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
> +        ret = -ENODEV;
> +        goto close_rom;
> +    }
> +    if (magic != 0xAA55) {
> +        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
> +        ret = -ENODEV;
> +        goto close_rom;
> +    }
> +    fseek(fp, 0, SEEK_SET);
> +
> +    if (!fread(buf, 1, st.st_size, fp)) {
> +        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s", rom_file);
> +        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are probably invalid "
> +                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
> +                     "or load from file with romfile=\n");
> +    }
> +
> +close_rom:
> +    /* Write "0" to disable ROM */
> +    fseek(fp, 0, SEEK_SET);
> +    val = 0;
> +    if (!fwrite(&val, 1, 1, fp)) {
> +        ret = -EIO;
> +        XEN_PT_LOG("%s\n", "Failed to disable pci-sysfs rom file");
> +    }
> +    fclose(fp);
> +    return ret;
> +}
> +
> +/* Allocated 128K for the vga bios */
> +#define VGA_BIOS_DEFAULT_SIZE (0x20000)
> +
> +int xen_pt_setup_vga(XenHostPCIDevice *dev)
> +{
> +    unsigned char *bios = NULL;
> +    int bios_size = 0;
> +    char *c = NULL;
> +    char checksum = 0;
> +    int rc = 0;
> +
> +    if (!is_vga_passthrough(dev)) {
> +        return rc;
> +    }
> +
> +    bios = g_malloc0(VGA_BIOS_DEFAULT_SIZE);
> +
> +    bios_size = get_vgabios(bios, dev);
> +    if (bios_size) {
> +        XEN_PT_ERR(NULL, "VGA: Error %d getting VBIOS!\n", bios_size);
> +        if (bios_size < 0) {
> +            XEN_PT_ERR(NULL, "VGA: Error (%s).\n", strerror(bios_size));
> +        }
> +        rc = -1;
> +        goto out;
> +    }
> +
> +    /* Adjust the bios checksum */

It's easy to see that you do this here, but *why* do you do it?
That's what the comment should explain.
Do you see many ROMs with an invalid checksum
in the field?

> +    for (c = (char *)bios; c < ((char *)bios + bios_size); c++) {
> +        checksum += *c;
> +    }
> +    if (checksum) {
> +        bios[bios_size - 1] -= checksum;
> +        XEN_PT_LOG(NULL, "vga bios checksum is adjusted!\n");
> +    }
> +
> +    /* Currently we fixed this address as a primary. */
> +    cpu_physical_memory_rw(0xc0000, bios, bios_size, 1);
> +out:
> +    g_free(bios);
> +    return rc;
> +}
> diff --git a/qemu-options.hx b/qemu-options.hx
> index ff76ad4..1c77baa 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1066,6 +1066,15 @@ STEXI
>  Rotate graphical output some deg left (only PXA LCD).
>  ETEXI
>  
> +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
> +
>  DEF("vga", HAS_ARG, QEMU_OPTION_vga,
>      "-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|none]\n"
>      "                select video card type\n", QEMU_ARCH_ALL)
> diff --git a/vl.c b/vl.c
> index a1686ef..c5b572d 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1418,6 +1418,13 @@ static void configure_msg(QemuOpts *opts)
>      enable_timestamp_msg = qemu_opt_get_bool(opts, "timestamp", true);
>  }
>  
> +/* We still need this for compatibility with XEN. */
> +int xen_has_gfx_passthru;
> +static void xen_gfx_passthru(const char *optarg)
> +{
> +    xen_has_gfx_passthru = 1;
> +}
> +
>  /***********************************************************/
>  /* USB devices */
>  
> @@ -3945,6 +3952,9 @@ int main(int argc, char **argv, char **envp)
>                      exit(1);
>                  }
>                  break;
> +            case QEMU_OPTION_gfx_passthru:
> +                xen_gfx_passthru(optarg);
> +                break;
>              default:
>                  os_parse_cmd_args(popt->index, optarg);
>              }
> -- 
> 1.9.1

Re: [Qemu-devel] [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Chen, Tiejun]

On 2014/6/25 14:35, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:17:17AM +0800, Tiejun Chen wrote:
>> basic gfx passthrough support:
>> - add a vga type for gfx passthrough
>> - retrieve VGA bios from sysfs, then load it to guest at 0xC0000
>> - register/unregister legacy VGA I/O ports and MMIOs for passthrough GFX
>>
>> The original patch is from Weidong Han <weidong.han@intel.com>
>>
>> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> Cc: Weidong Han <weidong.han@intel.com>
>
> ROM loading code is duplicated from assigned_dev_load_option_rom.

Yes. Do you hint we need to split this?

> Would it be a problem for you to create a memory region holding
> the ROM?

Sorry, could you tell me what should do exactly?

> You won't need cpu_physical_memory_rw then, either, or need

How to make sure this is fixed at 0xc0000?

Thanks
Tiejun

> the VGA_BIOS_DEFAULT_SIZE hack.
>
>
>
>
>> ---
>> v5:
>>
>> * Just rebase.
>>
>> v4:
>>
>> * Fix some typos in the patch head description.
>> * Improve some comments.
>> * Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
>>    are called unconditionally, so we just return 0 there.
>> * Remove one spurious change.
>>
>> v3:
>>
>> * Fix some typos.
>> * Add more comments to make that readable.
>> * Improve some return paths.
>>
>> v2:
>>
>> * retrieve VGA bios from sysfs properly.
>> * redefine some function name.
>>
>>   hw/xen/Makefile.objs         |   2 +-
>>   hw/xen/xen-host-pci-device.c |   5 +
>>   hw/xen/xen-host-pci-device.h |   1 +
>>   hw/xen/xen_pt.c              |  10 ++
>>   hw/xen/xen_pt.h              |   4 +
>>   hw/xen/xen_pt_graphics.c     | 232 +++++++++++++++++++++++++++++++++++++++++++
>>   qemu-options.hx              |   9 ++
>>   vl.c                         |  10 ++
>>   8 files changed, 272 insertions(+), 1 deletion(-)
>>   create mode 100644 hw/xen/xen_pt_graphics.c
>>
>> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
>> index a0ca0aa..77b7dae 100644
>> --- a/hw/xen/Makefile.objs
>> +++ b/hw/xen/Makefile.objs
>> @@ -2,4 +2,4 @@
>>   common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
>>
>>   obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
>> -obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
>> +obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o xen_pt_graphics.o
>> diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
>> index 743b37b..a54b7de 100644
>> --- a/hw/xen/xen-host-pci-device.c
>> +++ b/hw/xen/xen-host-pci-device.c
>> @@ -376,6 +376,11 @@ int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
>>           goto error;
>>       }
>>       d->irq = v;
>> +    rc = xen_host_pci_get_hex_value(d, "class", &v);
>> +    if (rc) {
>> +        goto error;
>> +    }
>> +    d->class_code = v;
>>       d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
>>
>>       return 0;
>> diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
>> index c2486f0..f1e1c30 100644
>> --- a/hw/xen/xen-host-pci-device.h
>> +++ b/hw/xen/xen-host-pci-device.h
>> @@ -25,6 +25,7 @@ typedef struct XenHostPCIDevice {
>>
>>       uint16_t vendor_id;
>>       uint16_t device_id;
>> +    uint32_t class_code;
>>       int irq;
>>
>>       XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
>> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
>> index be4220b..dac4238 100644
>> --- a/hw/xen/xen_pt.c
>> +++ b/hw/xen/xen_pt.c
>> @@ -450,6 +450,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
>>                      d->rom.size, d->rom.base_addr);
>>       }
>>
>> +    xen_pt_register_vga_regions(d);
>>       return 0;
>>   }
>>
>> @@ -470,6 +471,8 @@ static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
>>       if (d->rom.base_addr && d->rom.size) {
>>           memory_region_destroy(&s->rom);
>>       }
>> +
>> +    xen_pt_unregister_vga_regions(d);
>>   }
>>
>>   /* region mapping */
>> @@ -693,6 +696,13 @@ static int xen_pt_initfn(PCIDevice *d)
>>       /* Handle real device's MMIO/PIO BARs */
>>       xen_pt_register_regions(s);
>>
>> +    /* Setup VGA bios for passthrough GFX */
>> +    if (xen_pt_setup_vga(&s->real_device) < 0) {
>> +        XEN_PT_ERR(d, "Setup VGA BIOS of passthrough GFX failed!\n");
>> +        xen_host_pci_device_put(&s->real_device);
>> +        return -1;
>> +    }
>> +
>>       /* reinitialize each config register to be emulated */
>>       if (xen_pt_config_init(s)) {
>>           XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
>> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
>> index 942dc60..4d3a18d 100644
>> --- a/hw/xen/xen_pt.h
>> +++ b/hw/xen/xen_pt.h
>> @@ -298,5 +298,9 @@ static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
>>       return s->msix && s->msix->bar_index == bar;
>>   }
>>
>> +extern int xen_has_gfx_passthru;
>> +int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
>> +int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
>> +int xen_pt_setup_vga(XenHostPCIDevice *dev);
>>
>>   #endif /* !XEN_PT_H */
>> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
>> new file mode 100644
>> index 0000000..461e526
>> --- /dev/null
>> +++ b/hw/xen/xen_pt_graphics.c
>> @@ -0,0 +1,232 @@
>> +/*
>> + * graphics passthrough
>> + */
>> +#include "xen_pt.h"
>> +#include "xen-host-pci-device.h"
>> +#include "hw/xen/xen_backend.h"
>> +
>> +static int is_vga_passthrough(XenHostPCIDevice *dev)
>> +{
>> +    return (xen_has_gfx_passthru
>> +            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
>> +}
>> +
>> +typedef struct VGARegion {
>> +    int type;           /* Memory or port I/O */
>> +    uint64_t guest_base_addr;
>> +    uint64_t machine_base_addr;
>> +    uint64_t size;    /* size of the region */
>> +    int rc;
>> +} VGARegion;
>> +
>> +#define IORESOURCE_IO           0x00000100
>> +#define IORESOURCE_MEM          0x00000200
>> +
>> +static struct VGARegion vga_args[] = {
>> +    {
>> +        .type = IORESOURCE_IO,
>> +        .guest_base_addr = 0x3B0,
>> +        .machine_base_addr = 0x3B0,
>> +        .size = 0xC,
>> +        .rc = -1,
>> +    },
>> +    {
>> +        .type = IORESOURCE_IO,
>> +        .guest_base_addr = 0x3C0,
>> +        .machine_base_addr = 0x3C0,
>> +        .size = 0x20,
>> +        .rc = -1,
>> +    },
>> +    {
>> +        .type = IORESOURCE_MEM,
>> +        .guest_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
>> +        .machine_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
>> +        .size = 0x20,
>> +        .rc = -1,
>> +    },
>> +};
>> +
>> +/*
>> + * register VGA resources for the domain with assigned gfx
>> + */
>> +int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
>> +{
>> +    int i = 0;
>> +
>> +    if (!is_vga_passthrough(dev)) {
>> +        return 0;
>> +    }
>> +
>> +    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
>> +        if (vga_args[i].type == IORESOURCE_IO) {
>> +            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
>> +                            vga_args[i].guest_base_addr,
>> +                            vga_args[i].machine_base_addr,
>> +                            vga_args[i].size, DPCI_ADD_MAPPING);
>> +        } else {
>> +            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
>> +                            vga_args[i].guest_base_addr,
>> +                            vga_args[i].machine_base_addr,
>> +                            vga_args[i].size, DPCI_ADD_MAPPING);
>> +        }
>> +
>> +        if (vga_args[i].rc) {
>> +            XEN_PT_ERR(NULL, "VGA %s mapping failed! (rc: %i)\n",
>> +                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
>> +                    vga_args[i].rc);
>> +            return vga_args[i].rc;
>> +        }
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +/*
>> + * unregister VGA resources for the domain with assigned gfx
>> + */
>> +int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
>> +{
>> +    int i = 0;
>> +
>> +    if (!is_vga_passthrough(dev)) {
>> +        return 0;
>> +    }
>> +
>> +    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
>> +        if (vga_args[i].type == IORESOURCE_IO) {
>> +            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
>> +                            vga_args[i].guest_base_addr,
>> +                            vga_args[i].machine_base_addr,
>> +                            vga_args[i].size, DPCI_REMOVE_MAPPING);
>> +        } else {
>> +            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
>> +                            vga_args[i].guest_base_addr,
>> +                            vga_args[i].machine_base_addr,
>> +                            vga_args[i].size, DPCI_REMOVE_MAPPING);
>> +        }
>> +
>> +        if (vga_args[i].rc) {
>> +            XEN_PT_ERR(NULL, "VGA %s unmapping failed! (rc: %i)\n",
>> +                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
>> +                    vga_args[i].rc);
>> +            return vga_args[i].rc;
>> +        }
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
>> +{
>> +    char rom_file[64];
>> +    FILE *fp;
>> +    uint8_t val;
>> +    struct stat st;
>> +    uint16_t magic = 0;
>> +    int ret = 0;
>> +
>> +    snprintf(rom_file, sizeof(rom_file),
>> +             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
>> +             dev->domain, dev->bus, dev->dev,
>> +             dev->func);
>> +
>> +    if (stat(rom_file, &st)) {
>> +        return -ENODEV;
>> +    }
>> +
>> +    if (access(rom_file, F_OK)) {
>> +        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
>> +                    rom_file);
>> +        return -ENODEV;
>> +    }
>> +
>> +    /* Write "1" to the ROM file to enable it */
>> +    fp = fopen(rom_file, "r+");
>> +    if (fp == NULL) {
>> +        return -EACCES;
>> +    }
>> +    val = 1;
>> +    if (fwrite(&val, 1, 1, fp) != 1) {
>> +        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
>> +        ret = -EIO;
>> +        goto close_rom;
>> +    }
>> +    fseek(fp, 0, SEEK_SET);
>> +
>> +    /*
>> +     * Check if it a real bios extension.
>> +     * The magic number is 0xAA55.
>> +     */
>> +    if (!fread(&magic, sizeof(magic), 1, fp)) {
>> +        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
>> +        ret = -ENODEV;
>> +        goto close_rom;
>> +    }
>> +    if (magic != 0xAA55) {
>> +        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
>> +        ret = -ENODEV;
>> +        goto close_rom;
>> +    }
>> +    fseek(fp, 0, SEEK_SET);
>> +
>> +    if (!fread(buf, 1, st.st_size, fp)) {
>> +        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s", rom_file);
>> +        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are probably invalid "
>> +                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
>> +                     "or load from file with romfile=\n");
>> +    }
>> +
>> +close_rom:
>> +    /* Write "0" to disable ROM */
>> +    fseek(fp, 0, SEEK_SET);
>> +    val = 0;
>> +    if (!fwrite(&val, 1, 1, fp)) {
>> +        ret = -EIO;
>> +        XEN_PT_LOG("%s\n", "Failed to disable pci-sysfs rom file");
>> +    }
>> +    fclose(fp);
>> +    return ret;
>> +}
>> +
>> +/* Allocated 128K for the vga bios */
>> +#define VGA_BIOS_DEFAULT_SIZE (0x20000)
>> +
>> +int xen_pt_setup_vga(XenHostPCIDevice *dev)
>> +{
>> +    unsigned char *bios = NULL;
>> +    int bios_size = 0;
>> +    char *c = NULL;
>> +    char checksum = 0;
>> +    int rc = 0;
>> +
>> +    if (!is_vga_passthrough(dev)) {
>> +        return rc;
>> +    }
>> +
>> +    bios = g_malloc0(VGA_BIOS_DEFAULT_SIZE);
>> +
>> +    bios_size = get_vgabios(bios, dev);
>> +    if (bios_size) {
>> +        XEN_PT_ERR(NULL, "VGA: Error %d getting VBIOS!\n", bios_size);
>> +        if (bios_size < 0) {
>> +            XEN_PT_ERR(NULL, "VGA: Error (%s).\n", strerror(bios_size));
>> +        }
>> +        rc = -1;
>> +        goto out;
>> +    }
>> +
>> +    /* Adjust the bios checksum */
>
> It's easy to see that you do this here, but *why* do you do it?
> That's what the comment should explain.
> Do you see many ROMs with an invalid checksum
> in the field?
>
>> +    for (c = (char *)bios; c < ((char *)bios + bios_size); c++) {
>> +        checksum += *c;
>> +    }
>> +    if (checksum) {
>> +        bios[bios_size - 1] -= checksum;
>> +        XEN_PT_LOG(NULL, "vga bios checksum is adjusted!\n");
>> +    }
>> +
>> +    /* Currently we fixed this address as a primary. */
>> +    cpu_physical_memory_rw(0xc0000, bios, bios_size, 1);
>> +out:
>> +    g_free(bios);
>> +    return rc;
>> +}
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index ff76ad4..1c77baa 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -1066,6 +1066,15 @@ STEXI
>>   Rotate graphical output some deg left (only PXA LCD).
>>   ETEXI
>>
>> +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
>> +
>>   DEF("vga", HAS_ARG, QEMU_OPTION_vga,
>>       "-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|none]\n"
>>       "                select video card type\n", QEMU_ARCH_ALL)
>> diff --git a/vl.c b/vl.c
>> index a1686ef..c5b572d 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -1418,6 +1418,13 @@ static void configure_msg(QemuOpts *opts)
>>       enable_timestamp_msg = qemu_opt_get_bool(opts, "timestamp", true);
>>   }
>>
>> +/* We still need this for compatibility with XEN. */
>> +int xen_has_gfx_passthru;
>> +static void xen_gfx_passthru(const char *optarg)
>> +{
>> +    xen_has_gfx_passthru = 1;
>> +}
>> +
>>   /***********************************************************/
>>   /* USB devices */
>>
>> @@ -3945,6 +3952,9 @@ int main(int argc, char **argv, char **envp)
>>                       exit(1);
>>                   }
>>                   break;
>> +            case QEMU_OPTION_gfx_passthru:
>> +                xen_gfx_passthru(optarg);
>> +                break;
>>               default:
>>                   os_parse_cmd_args(popt->index, optarg);
>>               }
>> --
>> 1.9.1
>
>

Re: [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Chen, Tiejun]

On 2014/6/25 14:35, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:17:17AM +0800, Tiejun Chen wrote:
>> basic gfx passthrough support:
>> - add a vga type for gfx passthrough
>> - retrieve VGA bios from sysfs, then load it to guest at 0xC0000
>> - register/unregister legacy VGA I/O ports and MMIOs for passthrough GFX
>>
>> The original patch is from Weidong Han <weidong.han@intel.com>
>>
>> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> Cc: Weidong Han <weidong.han@intel.com>
>
> ROM loading code is duplicated from assigned_dev_load_option_rom.

Yes. Do you hint we need to split this?

> Would it be a problem for you to create a memory region holding
> the ROM?

Sorry, could you tell me what should do exactly?

> You won't need cpu_physical_memory_rw then, either, or need

How to make sure this is fixed at 0xc0000?

Thanks
Tiejun

> the VGA_BIOS_DEFAULT_SIZE hack.
>
>
>
>
>> ---
>> v5:
>>
>> * Just rebase.
>>
>> v4:
>>
>> * Fix some typos in the patch head description.
>> * Improve some comments.
>> * Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
>>    are called unconditionally, so we just return 0 there.
>> * Remove one spurious change.
>>
>> v3:
>>
>> * Fix some typos.
>> * Add more comments to make that readable.
>> * Improve some return paths.
>>
>> v2:
>>
>> * retrieve VGA bios from sysfs properly.
>> * redefine some function name.
>>
>>   hw/xen/Makefile.objs         |   2 +-
>>   hw/xen/xen-host-pci-device.c |   5 +
>>   hw/xen/xen-host-pci-device.h |   1 +
>>   hw/xen/xen_pt.c              |  10 ++
>>   hw/xen/xen_pt.h              |   4 +
>>   hw/xen/xen_pt_graphics.c     | 232 +++++++++++++++++++++++++++++++++++++++++++
>>   qemu-options.hx              |   9 ++
>>   vl.c                         |  10 ++
>>   8 files changed, 272 insertions(+), 1 deletion(-)
>>   create mode 100644 hw/xen/xen_pt_graphics.c
>>
>> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
>> index a0ca0aa..77b7dae 100644
>> --- a/hw/xen/Makefile.objs
>> +++ b/hw/xen/Makefile.objs
>> @@ -2,4 +2,4 @@
>>   common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
>>
>>   obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
>> -obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
>> +obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o xen_pt_graphics.o
>> diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
>> index 743b37b..a54b7de 100644
>> --- a/hw/xen/xen-host-pci-device.c
>> +++ b/hw/xen/xen-host-pci-device.c
>> @@ -376,6 +376,11 @@ int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
>>           goto error;
>>       }
>>       d->irq = v;
>> +    rc = xen_host_pci_get_hex_value(d, "class", &v);
>> +    if (rc) {
>> +        goto error;
>> +    }
>> +    d->class_code = v;
>>       d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
>>
>>       return 0;
>> diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
>> index c2486f0..f1e1c30 100644
>> --- a/hw/xen/xen-host-pci-device.h
>> +++ b/hw/xen/xen-host-pci-device.h
>> @@ -25,6 +25,7 @@ typedef struct XenHostPCIDevice {
>>
>>       uint16_t vendor_id;
>>       uint16_t device_id;
>> +    uint32_t class_code;
>>       int irq;
>>
>>       XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
>> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
>> index be4220b..dac4238 100644
>> --- a/hw/xen/xen_pt.c
>> +++ b/hw/xen/xen_pt.c
>> @@ -450,6 +450,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
>>                      d->rom.size, d->rom.base_addr);
>>       }
>>
>> +    xen_pt_register_vga_regions(d);
>>       return 0;
>>   }
>>
>> @@ -470,6 +471,8 @@ static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
>>       if (d->rom.base_addr && d->rom.size) {
>>           memory_region_destroy(&s->rom);
>>       }
>> +
>> +    xen_pt_unregister_vga_regions(d);
>>   }
>>
>>   /* region mapping */
>> @@ -693,6 +696,13 @@ static int xen_pt_initfn(PCIDevice *d)
>>       /* Handle real device's MMIO/PIO BARs */
>>       xen_pt_register_regions(s);
>>
>> +    /* Setup VGA bios for passthrough GFX */
>> +    if (xen_pt_setup_vga(&s->real_device) < 0) {
>> +        XEN_PT_ERR(d, "Setup VGA BIOS of passthrough GFX failed!\n");
>> +        xen_host_pci_device_put(&s->real_device);
>> +        return -1;
>> +    }
>> +
>>       /* reinitialize each config register to be emulated */
>>       if (xen_pt_config_init(s)) {
>>           XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
>> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
>> index 942dc60..4d3a18d 100644
>> --- a/hw/xen/xen_pt.h
>> +++ b/hw/xen/xen_pt.h
>> @@ -298,5 +298,9 @@ static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
>>       return s->msix && s->msix->bar_index == bar;
>>   }
>>
>> +extern int xen_has_gfx_passthru;
>> +int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
>> +int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
>> +int xen_pt_setup_vga(XenHostPCIDevice *dev);
>>
>>   #endif /* !XEN_PT_H */
>> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
>> new file mode 100644
>> index 0000000..461e526
>> --- /dev/null
>> +++ b/hw/xen/xen_pt_graphics.c
>> @@ -0,0 +1,232 @@
>> +/*
>> + * graphics passthrough
>> + */
>> +#include "xen_pt.h"
>> +#include "xen-host-pci-device.h"
>> +#include "hw/xen/xen_backend.h"
>> +
>> +static int is_vga_passthrough(XenHostPCIDevice *dev)
>> +{
>> +    return (xen_has_gfx_passthru
>> +            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
>> +}
>> +
>> +typedef struct VGARegion {
>> +    int type;           /* Memory or port I/O */
>> +    uint64_t guest_base_addr;
>> +    uint64_t machine_base_addr;
>> +    uint64_t size;    /* size of the region */
>> +    int rc;
>> +} VGARegion;
>> +
>> +#define IORESOURCE_IO           0x00000100
>> +#define IORESOURCE_MEM          0x00000200
>> +
>> +static struct VGARegion vga_args[] = {
>> +    {
>> +        .type = IORESOURCE_IO,
>> +        .guest_base_addr = 0x3B0,
>> +        .machine_base_addr = 0x3B0,
>> +        .size = 0xC,
>> +        .rc = -1,
>> +    },
>> +    {
>> +        .type = IORESOURCE_IO,
>> +        .guest_base_addr = 0x3C0,
>> +        .machine_base_addr = 0x3C0,
>> +        .size = 0x20,
>> +        .rc = -1,
>> +    },
>> +    {
>> +        .type = IORESOURCE_MEM,
>> +        .guest_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
>> +        .machine_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
>> +        .size = 0x20,
>> +        .rc = -1,
>> +    },
>> +};
>> +
>> +/*
>> + * register VGA resources for the domain with assigned gfx
>> + */
>> +int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
>> +{
>> +    int i = 0;
>> +
>> +    if (!is_vga_passthrough(dev)) {
>> +        return 0;
>> +    }
>> +
>> +    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
>> +        if (vga_args[i].type == IORESOURCE_IO) {
>> +            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
>> +                            vga_args[i].guest_base_addr,
>> +                            vga_args[i].machine_base_addr,
>> +                            vga_args[i].size, DPCI_ADD_MAPPING);
>> +        } else {
>> +            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
>> +                            vga_args[i].guest_base_addr,
>> +                            vga_args[i].machine_base_addr,
>> +                            vga_args[i].size, DPCI_ADD_MAPPING);
>> +        }
>> +
>> +        if (vga_args[i].rc) {
>> +            XEN_PT_ERR(NULL, "VGA %s mapping failed! (rc: %i)\n",
>> +                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
>> +                    vga_args[i].rc);
>> +            return vga_args[i].rc;
>> +        }
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +/*
>> + * unregister VGA resources for the domain with assigned gfx
>> + */
>> +int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
>> +{
>> +    int i = 0;
>> +
>> +    if (!is_vga_passthrough(dev)) {
>> +        return 0;
>> +    }
>> +
>> +    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
>> +        if (vga_args[i].type == IORESOURCE_IO) {
>> +            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
>> +                            vga_args[i].guest_base_addr,
>> +                            vga_args[i].machine_base_addr,
>> +                            vga_args[i].size, DPCI_REMOVE_MAPPING);
>> +        } else {
>> +            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
>> +                            vga_args[i].guest_base_addr,
>> +                            vga_args[i].machine_base_addr,
>> +                            vga_args[i].size, DPCI_REMOVE_MAPPING);
>> +        }
>> +
>> +        if (vga_args[i].rc) {
>> +            XEN_PT_ERR(NULL, "VGA %s unmapping failed! (rc: %i)\n",
>> +                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
>> +                    vga_args[i].rc);
>> +            return vga_args[i].rc;
>> +        }
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
>> +{
>> +    char rom_file[64];
>> +    FILE *fp;
>> +    uint8_t val;
>> +    struct stat st;
>> +    uint16_t magic = 0;
>> +    int ret = 0;
>> +
>> +    snprintf(rom_file, sizeof(rom_file),
>> +             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
>> +             dev->domain, dev->bus, dev->dev,
>> +             dev->func);
>> +
>> +    if (stat(rom_file, &st)) {
>> +        return -ENODEV;
>> +    }
>> +
>> +    if (access(rom_file, F_OK)) {
>> +        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
>> +                    rom_file);
>> +        return -ENODEV;
>> +    }
>> +
>> +    /* Write "1" to the ROM file to enable it */
>> +    fp = fopen(rom_file, "r+");
>> +    if (fp == NULL) {
>> +        return -EACCES;
>> +    }
>> +    val = 1;
>> +    if (fwrite(&val, 1, 1, fp) != 1) {
>> +        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
>> +        ret = -EIO;
>> +        goto close_rom;
>> +    }
>> +    fseek(fp, 0, SEEK_SET);
>> +
>> +    /*
>> +     * Check if it a real bios extension.
>> +     * The magic number is 0xAA55.
>> +     */
>> +    if (!fread(&magic, sizeof(magic), 1, fp)) {
>> +        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
>> +        ret = -ENODEV;
>> +        goto close_rom;
>> +    }
>> +    if (magic != 0xAA55) {
>> +        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
>> +        ret = -ENODEV;
>> +        goto close_rom;
>> +    }
>> +    fseek(fp, 0, SEEK_SET);
>> +
>> +    if (!fread(buf, 1, st.st_size, fp)) {
>> +        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s", rom_file);
>> +        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are probably invalid "
>> +                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
>> +                     "or load from file with romfile=\n");
>> +    }
>> +
>> +close_rom:
>> +    /* Write "0" to disable ROM */
>> +    fseek(fp, 0, SEEK_SET);
>> +    val = 0;
>> +    if (!fwrite(&val, 1, 1, fp)) {
>> +        ret = -EIO;
>> +        XEN_PT_LOG("%s\n", "Failed to disable pci-sysfs rom file");
>> +    }
>> +    fclose(fp);
>> +    return ret;
>> +}
>> +
>> +/* Allocated 128K for the vga bios */
>> +#define VGA_BIOS_DEFAULT_SIZE (0x20000)
>> +
>> +int xen_pt_setup_vga(XenHostPCIDevice *dev)
>> +{
>> +    unsigned char *bios = NULL;
>> +    int bios_size = 0;
>> +    char *c = NULL;
>> +    char checksum = 0;
>> +    int rc = 0;
>> +
>> +    if (!is_vga_passthrough(dev)) {
>> +        return rc;
>> +    }
>> +
>> +    bios = g_malloc0(VGA_BIOS_DEFAULT_SIZE);
>> +
>> +    bios_size = get_vgabios(bios, dev);
>> +    if (bios_size) {
>> +        XEN_PT_ERR(NULL, "VGA: Error %d getting VBIOS!\n", bios_size);
>> +        if (bios_size < 0) {
>> +            XEN_PT_ERR(NULL, "VGA: Error (%s).\n", strerror(bios_size));
>> +        }
>> +        rc = -1;
>> +        goto out;
>> +    }
>> +
>> +    /* Adjust the bios checksum */
>
> It's easy to see that you do this here, but *why* do you do it?
> That's what the comment should explain.
> Do you see many ROMs with an invalid checksum
> in the field?
>
>> +    for (c = (char *)bios; c < ((char *)bios + bios_size); c++) {
>> +        checksum += *c;
>> +    }
>> +    if (checksum) {
>> +        bios[bios_size - 1] -= checksum;
>> +        XEN_PT_LOG(NULL, "vga bios checksum is adjusted!\n");
>> +    }
>> +
>> +    /* Currently we fixed this address as a primary. */
>> +    cpu_physical_memory_rw(0xc0000, bios, bios_size, 1);
>> +out:
>> +    g_free(bios);
>> +    return rc;
>> +}
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index ff76ad4..1c77baa 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -1066,6 +1066,15 @@ STEXI
>>   Rotate graphical output some deg left (only PXA LCD).
>>   ETEXI
>>
>> +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
>> +
>>   DEF("vga", HAS_ARG, QEMU_OPTION_vga,
>>       "-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|none]\n"
>>       "                select video card type\n", QEMU_ARCH_ALL)
>> diff --git a/vl.c b/vl.c
>> index a1686ef..c5b572d 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -1418,6 +1418,13 @@ static void configure_msg(QemuOpts *opts)
>>       enable_timestamp_msg = qemu_opt_get_bool(opts, "timestamp", true);
>>   }
>>
>> +/* We still need this for compatibility with XEN. */
>> +int xen_has_gfx_passthru;
>> +static void xen_gfx_passthru(const char *optarg)
>> +{
>> +    xen_has_gfx_passthru = 1;
>> +}
>> +
>>   /***********************************************************/
>>   /* USB devices */
>>
>> @@ -3945,6 +3952,9 @@ int main(int argc, char **argv, char **envp)
>>                       exit(1);
>>                   }
>>                   break;
>> +            case QEMU_OPTION_gfx_passthru:
>> +                xen_gfx_passthru(optarg);
>> +                break;
>>               default:
>>                   os_parse_cmd_args(popt->index, optarg);
>>               }
>> --
>> 1.9.1
>
>

Re: [Qemu-devel] [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 05:06:37PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 14:35, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:17:17AM +0800, Tiejun Chen wrote:
> >>basic gfx passthrough support:
> >>- add a vga type for gfx passthrough
> >>- retrieve VGA bios from sysfs, then load it to guest at 0xC0000
> >>- register/unregister legacy VGA I/O ports and MMIOs for passthrough GFX
> >>
> >>The original patch is from Weidong Han <weidong.han@intel.com>
> >>
> >>Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>Cc: Weidong Han <weidong.han@intel.com>
> >
> >ROM loading code is duplicated from assigned_dev_load_option_rom.
> 
> Yes. Do you hint we need to split this?

Absolutely. These two drivers need to start sharing code.

> >Would it be a problem for you to create a memory region holding
> >the ROM?
> 
> Sorry, could you tell me what should do exactly?

Split common code out and reuse :)

> >You won't need cpu_physical_memory_rw then, either, or need
> 
> How to make sure this is fixed at 0xc0000?
> 
> Thanks
> Tiejun

I guess you just add it as subregion of system memory at this offset,
maybe with a higher priority than RAM.
Right, Paolo?

> >the VGA_BIOS_DEFAULT_SIZE hack.
> >
> >
> >
> >
> >>---
> >>v5:
> >>
> >>* Just rebase.
> >>
> >>v4:
> >>
> >>* Fix some typos in the patch head description.
> >>* Improve some comments.
> >>* Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
> >>   are called unconditionally, so we just return 0 there.
> >>* Remove one spurious change.
> >>
> >>v3:
> >>
> >>* Fix some typos.
> >>* Add more comments to make that readable.
> >>* Improve some return paths.
> >>
> >>v2:
> >>
> >>* retrieve VGA bios from sysfs properly.
> >>* redefine some function name.
> >>
> >>  hw/xen/Makefile.objs         |   2 +-
> >>  hw/xen/xen-host-pci-device.c |   5 +
> >>  hw/xen/xen-host-pci-device.h |   1 +
> >>  hw/xen/xen_pt.c              |  10 ++
> >>  hw/xen/xen_pt.h              |   4 +
> >>  hw/xen/xen_pt_graphics.c     | 232 +++++++++++++++++++++++++++++++++++++++++++
> >>  qemu-options.hx              |   9 ++
> >>  vl.c                         |  10 ++
> >>  8 files changed, 272 insertions(+), 1 deletion(-)
> >>  create mode 100644 hw/xen/xen_pt_graphics.c
> >>
> >>diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> >>index a0ca0aa..77b7dae 100644
> >>--- a/hw/xen/Makefile.objs
> >>+++ b/hw/xen/Makefile.objs
> >>@@ -2,4 +2,4 @@
> >>  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
> >>
> >>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> >>-obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
> >>+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o xen_pt_graphics.o
> >>diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
> >>index 743b37b..a54b7de 100644
> >>--- a/hw/xen/xen-host-pci-device.c
> >>+++ b/hw/xen/xen-host-pci-device.c
> >>@@ -376,6 +376,11 @@ int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
> >>          goto error;
> >>      }
> >>      d->irq = v;
> >>+    rc = xen_host_pci_get_hex_value(d, "class", &v);
> >>+    if (rc) {
> >>+        goto error;
> >>+    }
> >>+    d->class_code = v;
> >>      d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
> >>
> >>      return 0;
> >>diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
> >>index c2486f0..f1e1c30 100644
> >>--- a/hw/xen/xen-host-pci-device.h
> >>+++ b/hw/xen/xen-host-pci-device.h
> >>@@ -25,6 +25,7 @@ typedef struct XenHostPCIDevice {
> >>
> >>      uint16_t vendor_id;
> >>      uint16_t device_id;
> >>+    uint32_t class_code;
> >>      int irq;
> >>
> >>      XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
> >>diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> >>index be4220b..dac4238 100644
> >>--- a/hw/xen/xen_pt.c
> >>+++ b/hw/xen/xen_pt.c
> >>@@ -450,6 +450,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
> >>                     d->rom.size, d->rom.base_addr);
> >>      }
> >>
> >>+    xen_pt_register_vga_regions(d);
> >>      return 0;
> >>  }
> >>
> >>@@ -470,6 +471,8 @@ static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
> >>      if (d->rom.base_addr && d->rom.size) {
> >>          memory_region_destroy(&s->rom);
> >>      }
> >>+
> >>+    xen_pt_unregister_vga_regions(d);
> >>  }
> >>
> >>  /* region mapping */
> >>@@ -693,6 +696,13 @@ static int xen_pt_initfn(PCIDevice *d)
> >>      /* Handle real device's MMIO/PIO BARs */
> >>      xen_pt_register_regions(s);
> >>
> >>+    /* Setup VGA bios for passthrough GFX */
> >>+    if (xen_pt_setup_vga(&s->real_device) < 0) {
> >>+        XEN_PT_ERR(d, "Setup VGA BIOS of passthrough GFX failed!\n");
> >>+        xen_host_pci_device_put(&s->real_device);
> >>+        return -1;
> >>+    }
> >>+
> >>      /* reinitialize each config register to be emulated */
> >>      if (xen_pt_config_init(s)) {
> >>          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
> >>diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> >>index 942dc60..4d3a18d 100644
> >>--- a/hw/xen/xen_pt.h
> >>+++ b/hw/xen/xen_pt.h
> >>@@ -298,5 +298,9 @@ static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
> >>      return s->msix && s->msix->bar_index == bar;
> >>  }
> >>
> >>+extern int xen_has_gfx_passthru;
> >>+int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
> >>+int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
> >>+int xen_pt_setup_vga(XenHostPCIDevice *dev);
> >>
> >>  #endif /* !XEN_PT_H */
> >>diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> >>new file mode 100644
> >>index 0000000..461e526
> >>--- /dev/null
> >>+++ b/hw/xen/xen_pt_graphics.c
> >>@@ -0,0 +1,232 @@
> >>+/*
> >>+ * graphics passthrough
> >>+ */
> >>+#include "xen_pt.h"
> >>+#include "xen-host-pci-device.h"
> >>+#include "hw/xen/xen_backend.h"
> >>+
> >>+static int is_vga_passthrough(XenHostPCIDevice *dev)
> >>+{
> >>+    return (xen_has_gfx_passthru
> >>+            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
> >>+}
> >>+
> >>+typedef struct VGARegion {
> >>+    int type;           /* Memory or port I/O */
> >>+    uint64_t guest_base_addr;
> >>+    uint64_t machine_base_addr;
> >>+    uint64_t size;    /* size of the region */
> >>+    int rc;
> >>+} VGARegion;
> >>+
> >>+#define IORESOURCE_IO           0x00000100
> >>+#define IORESOURCE_MEM          0x00000200
> >>+
> >>+static struct VGARegion vga_args[] = {
> >>+    {
> >>+        .type = IORESOURCE_IO,
> >>+        .guest_base_addr = 0x3B0,
> >>+        .machine_base_addr = 0x3B0,
> >>+        .size = 0xC,
> >>+        .rc = -1,
> >>+    },
> >>+    {
> >>+        .type = IORESOURCE_IO,
> >>+        .guest_base_addr = 0x3C0,
> >>+        .machine_base_addr = 0x3C0,
> >>+        .size = 0x20,
> >>+        .rc = -1,
> >>+    },
> >>+    {
> >>+        .type = IORESOURCE_MEM,
> >>+        .guest_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
> >>+        .machine_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
> >>+        .size = 0x20,
> >>+        .rc = -1,
> >>+    },
> >>+};
> >>+
> >>+/*
> >>+ * register VGA resources for the domain with assigned gfx
> >>+ */
> >>+int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
> >>+{
> >>+    int i = 0;
> >>+
> >>+    if (!is_vga_passthrough(dev)) {
> >>+        return 0;
> >>+    }
> >>+
> >>+    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
> >>+        if (vga_args[i].type == IORESOURCE_IO) {
> >>+            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
> >>+                            vga_args[i].guest_base_addr,
> >>+                            vga_args[i].machine_base_addr,
> >>+                            vga_args[i].size, DPCI_ADD_MAPPING);
> >>+        } else {
> >>+            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> >>+                            vga_args[i].guest_base_addr,
> >>+                            vga_args[i].machine_base_addr,
> >>+                            vga_args[i].size, DPCI_ADD_MAPPING);
> >>+        }
> >>+
> >>+        if (vga_args[i].rc) {
> >>+            XEN_PT_ERR(NULL, "VGA %s mapping failed! (rc: %i)\n",
> >>+                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
> >>+                    vga_args[i].rc);
> >>+            return vga_args[i].rc;
> >>+        }
> >>+    }
> >>+
> >>+    return 0;
> >>+}
> >>+
> >>+/*
> >>+ * unregister VGA resources for the domain with assigned gfx
> >>+ */
> >>+int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
> >>+{
> >>+    int i = 0;
> >>+
> >>+    if (!is_vga_passthrough(dev)) {
> >>+        return 0;
> >>+    }
> >>+
> >>+    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
> >>+        if (vga_args[i].type == IORESOURCE_IO) {
> >>+            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
> >>+                            vga_args[i].guest_base_addr,
> >>+                            vga_args[i].machine_base_addr,
> >>+                            vga_args[i].size, DPCI_REMOVE_MAPPING);
> >>+        } else {
> >>+            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> >>+                            vga_args[i].guest_base_addr,
> >>+                            vga_args[i].machine_base_addr,
> >>+                            vga_args[i].size, DPCI_REMOVE_MAPPING);
> >>+        }
> >>+
> >>+        if (vga_args[i].rc) {
> >>+            XEN_PT_ERR(NULL, "VGA %s unmapping failed! (rc: %i)\n",
> >>+                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
> >>+                    vga_args[i].rc);
> >>+            return vga_args[i].rc;
> >>+        }
> >>+    }
> >>+
> >>+    return 0;
> >>+}
> >>+
> >>+static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
> >>+{
> >>+    char rom_file[64];
> >>+    FILE *fp;
> >>+    uint8_t val;
> >>+    struct stat st;
> >>+    uint16_t magic = 0;
> >>+    int ret = 0;
> >>+
> >>+    snprintf(rom_file, sizeof(rom_file),
> >>+             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
> >>+             dev->domain, dev->bus, dev->dev,
> >>+             dev->func);
> >>+
> >>+    if (stat(rom_file, &st)) {
> >>+        return -ENODEV;
> >>+    }
> >>+
> >>+    if (access(rom_file, F_OK)) {
> >>+        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
> >>+                    rom_file);
> >>+        return -ENODEV;
> >>+    }
> >>+
> >>+    /* Write "1" to the ROM file to enable it */
> >>+    fp = fopen(rom_file, "r+");
> >>+    if (fp == NULL) {
> >>+        return -EACCES;
> >>+    }
> >>+    val = 1;
> >>+    if (fwrite(&val, 1, 1, fp) != 1) {
> >>+        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
> >>+        ret = -EIO;
> >>+        goto close_rom;
> >>+    }
> >>+    fseek(fp, 0, SEEK_SET);
> >>+
> >>+    /*
> >>+     * Check if it a real bios extension.
> >>+     * The magic number is 0xAA55.
> >>+     */
> >>+    if (!fread(&magic, sizeof(magic), 1, fp)) {
> >>+        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
> >>+        ret = -ENODEV;
> >>+        goto close_rom;
> >>+    }
> >>+    if (magic != 0xAA55) {
> >>+        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
> >>+        ret = -ENODEV;
> >>+        goto close_rom;
> >>+    }
> >>+    fseek(fp, 0, SEEK_SET);
> >>+
> >>+    if (!fread(buf, 1, st.st_size, fp)) {
> >>+        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s", rom_file);
> >>+        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are probably invalid "
> >>+                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
> >>+                     "or load from file with romfile=\n");
> >>+    }
> >>+
> >>+close_rom:
> >>+    /* Write "0" to disable ROM */
> >>+    fseek(fp, 0, SEEK_SET);
> >>+    val = 0;
> >>+    if (!fwrite(&val, 1, 1, fp)) {
> >>+        ret = -EIO;
> >>+        XEN_PT_LOG("%s\n", "Failed to disable pci-sysfs rom file");
> >>+    }
> >>+    fclose(fp);
> >>+    return ret;
> >>+}
> >>+
> >>+/* Allocated 128K for the vga bios */
> >>+#define VGA_BIOS_DEFAULT_SIZE (0x20000)
> >>+
> >>+int xen_pt_setup_vga(XenHostPCIDevice *dev)
> >>+{
> >>+    unsigned char *bios = NULL;
> >>+    int bios_size = 0;
> >>+    char *c = NULL;
> >>+    char checksum = 0;
> >>+    int rc = 0;
> >>+
> >>+    if (!is_vga_passthrough(dev)) {
> >>+        return rc;
> >>+    }
> >>+
> >>+    bios = g_malloc0(VGA_BIOS_DEFAULT_SIZE);
> >>+
> >>+    bios_size = get_vgabios(bios, dev);
> >>+    if (bios_size) {
> >>+        XEN_PT_ERR(NULL, "VGA: Error %d getting VBIOS!\n", bios_size);
> >>+        if (bios_size < 0) {
> >>+            XEN_PT_ERR(NULL, "VGA: Error (%s).\n", strerror(bios_size));
> >>+        }
> >>+        rc = -1;
> >>+        goto out;
> >>+    }
> >>+
> >>+    /* Adjust the bios checksum */
> >
> >It's easy to see that you do this here, but *why* do you do it?
> >That's what the comment should explain.
> >Do you see many ROMs with an invalid checksum
> >in the field?
> >
> >>+    for (c = (char *)bios; c < ((char *)bios + bios_size); c++) {
> >>+        checksum += *c;
> >>+    }
> >>+    if (checksum) {
> >>+        bios[bios_size - 1] -= checksum;
> >>+        XEN_PT_LOG(NULL, "vga bios checksum is adjusted!\n");
> >>+    }
> >>+
> >>+    /* Currently we fixed this address as a primary. */
> >>+    cpu_physical_memory_rw(0xc0000, bios, bios_size, 1);
> >>+out:
> >>+    g_free(bios);
> >>+    return rc;
> >>+}
> >>diff --git a/qemu-options.hx b/qemu-options.hx
> >>index ff76ad4..1c77baa 100644
> >>--- a/qemu-options.hx
> >>+++ b/qemu-options.hx
> >>@@ -1066,6 +1066,15 @@ STEXI
> >>  Rotate graphical output some deg left (only PXA LCD).
> >>  ETEXI
> >>
> >>+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
> >>+
> >>  DEF("vga", HAS_ARG, QEMU_OPTION_vga,
> >>      "-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|none]\n"
> >>      "                select video card type\n", QEMU_ARCH_ALL)
> >>diff --git a/vl.c b/vl.c
> >>index a1686ef..c5b572d 100644
> >>--- a/vl.c
> >>+++ b/vl.c
> >>@@ -1418,6 +1418,13 @@ static void configure_msg(QemuOpts *opts)
> >>      enable_timestamp_msg = qemu_opt_get_bool(opts, "timestamp", true);
> >>  }
> >>
> >>+/* We still need this for compatibility with XEN. */
> >>+int xen_has_gfx_passthru;
> >>+static void xen_gfx_passthru(const char *optarg)
> >>+{
> >>+    xen_has_gfx_passthru = 1;
> >>+}
> >>+
> >>  /***********************************************************/
> >>  /* USB devices */
> >>
> >>@@ -3945,6 +3952,9 @@ int main(int argc, char **argv, char **envp)
> >>                      exit(1);
> >>                  }
> >>                  break;
> >>+            case QEMU_OPTION_gfx_passthru:
> >>+                xen_gfx_passthru(optarg);
> >>+                break;
> >>              default:
> >>                  os_parse_cmd_args(popt->index, optarg);
> >>              }
> >>--
> >>1.9.1
> >
> >

Re: [v5][PATCH 1/5] xen, gfx passthrough: basic graphics passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 05:06:37PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 14:35, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:17:17AM +0800, Tiejun Chen wrote:
> >>basic gfx passthrough support:
> >>- add a vga type for gfx passthrough
> >>- retrieve VGA bios from sysfs, then load it to guest at 0xC0000
> >>- register/unregister legacy VGA I/O ports and MMIOs for passthrough GFX
> >>
> >>The original patch is from Weidong Han <weidong.han@intel.com>
> >>
> >>Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>Cc: Weidong Han <weidong.han@intel.com>
> >
> >ROM loading code is duplicated from assigned_dev_load_option_rom.
> 
> Yes. Do you hint we need to split this?

Absolutely. These two drivers need to start sharing code.

> >Would it be a problem for you to create a memory region holding
> >the ROM?
> 
> Sorry, could you tell me what should do exactly?

Split common code out and reuse :)

> >You won't need cpu_physical_memory_rw then, either, or need
> 
> How to make sure this is fixed at 0xc0000?
> 
> Thanks
> Tiejun

I guess you just add it as subregion of system memory at this offset,
maybe with a higher priority than RAM.
Right, Paolo?

> >the VGA_BIOS_DEFAULT_SIZE hack.
> >
> >
> >
> >
> >>---
> >>v5:
> >>
> >>* Just rebase.
> >>
> >>v4:
> >>
> >>* Fix some typos in the patch head description.
> >>* Improve some comments.
> >>* Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
> >>   are called unconditionally, so we just return 0 there.
> >>* Remove one spurious change.
> >>
> >>v3:
> >>
> >>* Fix some typos.
> >>* Add more comments to make that readable.
> >>* Improve some return paths.
> >>
> >>v2:
> >>
> >>* retrieve VGA bios from sysfs properly.
> >>* redefine some function name.
> >>
> >>  hw/xen/Makefile.objs         |   2 +-
> >>  hw/xen/xen-host-pci-device.c |   5 +
> >>  hw/xen/xen-host-pci-device.h |   1 +
> >>  hw/xen/xen_pt.c              |  10 ++
> >>  hw/xen/xen_pt.h              |   4 +
> >>  hw/xen/xen_pt_graphics.c     | 232 +++++++++++++++++++++++++++++++++++++++++++
> >>  qemu-options.hx              |   9 ++
> >>  vl.c                         |  10 ++
> >>  8 files changed, 272 insertions(+), 1 deletion(-)
> >>  create mode 100644 hw/xen/xen_pt_graphics.c
> >>
> >>diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> >>index a0ca0aa..77b7dae 100644
> >>--- a/hw/xen/Makefile.objs
> >>+++ b/hw/xen/Makefile.objs
> >>@@ -2,4 +2,4 @@
> >>  common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
> >>
> >>  obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> >>-obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
> >>+obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o xen_pt_graphics.o
> >>diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
> >>index 743b37b..a54b7de 100644
> >>--- a/hw/xen/xen-host-pci-device.c
> >>+++ b/hw/xen/xen-host-pci-device.c
> >>@@ -376,6 +376,11 @@ int xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
> >>          goto error;
> >>      }
> >>      d->irq = v;
> >>+    rc = xen_host_pci_get_hex_value(d, "class", &v);
> >>+    if (rc) {
> >>+        goto error;
> >>+    }
> >>+    d->class_code = v;
> >>      d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
> >>
> >>      return 0;
> >>diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
> >>index c2486f0..f1e1c30 100644
> >>--- a/hw/xen/xen-host-pci-device.h
> >>+++ b/hw/xen/xen-host-pci-device.h
> >>@@ -25,6 +25,7 @@ typedef struct XenHostPCIDevice {
> >>
> >>      uint16_t vendor_id;
> >>      uint16_t device_id;
> >>+    uint32_t class_code;
> >>      int irq;
> >>
> >>      XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
> >>diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> >>index be4220b..dac4238 100644
> >>--- a/hw/xen/xen_pt.c
> >>+++ b/hw/xen/xen_pt.c
> >>@@ -450,6 +450,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
> >>                     d->rom.size, d->rom.base_addr);
> >>      }
> >>
> >>+    xen_pt_register_vga_regions(d);
> >>      return 0;
> >>  }
> >>
> >>@@ -470,6 +471,8 @@ static void xen_pt_unregister_regions(XenPCIPassthroughState *s)
> >>      if (d->rom.base_addr && d->rom.size) {
> >>          memory_region_destroy(&s->rom);
> >>      }
> >>+
> >>+    xen_pt_unregister_vga_regions(d);
> >>  }
> >>
> >>  /* region mapping */
> >>@@ -693,6 +696,13 @@ static int xen_pt_initfn(PCIDevice *d)
> >>      /* Handle real device's MMIO/PIO BARs */
> >>      xen_pt_register_regions(s);
> >>
> >>+    /* Setup VGA bios for passthrough GFX */
> >>+    if (xen_pt_setup_vga(&s->real_device) < 0) {
> >>+        XEN_PT_ERR(d, "Setup VGA BIOS of passthrough GFX failed!\n");
> >>+        xen_host_pci_device_put(&s->real_device);
> >>+        return -1;
> >>+    }
> >>+
> >>      /* reinitialize each config register to be emulated */
> >>      if (xen_pt_config_init(s)) {
> >>          XEN_PT_ERR(d, "PCI Config space initialisation failed.\n");
> >>diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> >>index 942dc60..4d3a18d 100644
> >>--- a/hw/xen/xen_pt.h
> >>+++ b/hw/xen/xen_pt.h
> >>@@ -298,5 +298,9 @@ static inline bool xen_pt_has_msix_mapping(XenPCIPassthroughState *s, int bar)
> >>      return s->msix && s->msix->bar_index == bar;
> >>  }
> >>
> >>+extern int xen_has_gfx_passthru;
> >>+int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
> >>+int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
> >>+int xen_pt_setup_vga(XenHostPCIDevice *dev);
> >>
> >>  #endif /* !XEN_PT_H */
> >>diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> >>new file mode 100644
> >>index 0000000..461e526
> >>--- /dev/null
> >>+++ b/hw/xen/xen_pt_graphics.c
> >>@@ -0,0 +1,232 @@
> >>+/*
> >>+ * graphics passthrough
> >>+ */
> >>+#include "xen_pt.h"
> >>+#include "xen-host-pci-device.h"
> >>+#include "hw/xen/xen_backend.h"
> >>+
> >>+static int is_vga_passthrough(XenHostPCIDevice *dev)
> >>+{
> >>+    return (xen_has_gfx_passthru
> >>+            && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
> >>+}
> >>+
> >>+typedef struct VGARegion {
> >>+    int type;           /* Memory or port I/O */
> >>+    uint64_t guest_base_addr;
> >>+    uint64_t machine_base_addr;
> >>+    uint64_t size;    /* size of the region */
> >>+    int rc;
> >>+} VGARegion;
> >>+
> >>+#define IORESOURCE_IO           0x00000100
> >>+#define IORESOURCE_MEM          0x00000200
> >>+
> >>+static struct VGARegion vga_args[] = {
> >>+    {
> >>+        .type = IORESOURCE_IO,
> >>+        .guest_base_addr = 0x3B0,
> >>+        .machine_base_addr = 0x3B0,
> >>+        .size = 0xC,
> >>+        .rc = -1,
> >>+    },
> >>+    {
> >>+        .type = IORESOURCE_IO,
> >>+        .guest_base_addr = 0x3C0,
> >>+        .machine_base_addr = 0x3C0,
> >>+        .size = 0x20,
> >>+        .rc = -1,
> >>+    },
> >>+    {
> >>+        .type = IORESOURCE_MEM,
> >>+        .guest_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
> >>+        .machine_base_addr = 0xa0000 >> XC_PAGE_SHIFT,
> >>+        .size = 0x20,
> >>+        .rc = -1,
> >>+    },
> >>+};
> >>+
> >>+/*
> >>+ * register VGA resources for the domain with assigned gfx
> >>+ */
> >>+int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
> >>+{
> >>+    int i = 0;
> >>+
> >>+    if (!is_vga_passthrough(dev)) {
> >>+        return 0;
> >>+    }
> >>+
> >>+    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
> >>+        if (vga_args[i].type == IORESOURCE_IO) {
> >>+            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
> >>+                            vga_args[i].guest_base_addr,
> >>+                            vga_args[i].machine_base_addr,
> >>+                            vga_args[i].size, DPCI_ADD_MAPPING);
> >>+        } else {
> >>+            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> >>+                            vga_args[i].guest_base_addr,
> >>+                            vga_args[i].machine_base_addr,
> >>+                            vga_args[i].size, DPCI_ADD_MAPPING);
> >>+        }
> >>+
> >>+        if (vga_args[i].rc) {
> >>+            XEN_PT_ERR(NULL, "VGA %s mapping failed! (rc: %i)\n",
> >>+                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
> >>+                    vga_args[i].rc);
> >>+            return vga_args[i].rc;
> >>+        }
> >>+    }
> >>+
> >>+    return 0;
> >>+}
> >>+
> >>+/*
> >>+ * unregister VGA resources for the domain with assigned gfx
> >>+ */
> >>+int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
> >>+{
> >>+    int i = 0;
> >>+
> >>+    if (!is_vga_passthrough(dev)) {
> >>+        return 0;
> >>+    }
> >>+
> >>+    for (i = 0 ; i < ARRAY_SIZE(vga_args); i++) {
> >>+        if (vga_args[i].type == IORESOURCE_IO) {
> >>+            vga_args[i].rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
> >>+                            vga_args[i].guest_base_addr,
> >>+                            vga_args[i].machine_base_addr,
> >>+                            vga_args[i].size, DPCI_REMOVE_MAPPING);
> >>+        } else {
> >>+            vga_args[i].rc = xc_domain_memory_mapping(xen_xc, xen_domid,
> >>+                            vga_args[i].guest_base_addr,
> >>+                            vga_args[i].machine_base_addr,
> >>+                            vga_args[i].size, DPCI_REMOVE_MAPPING);
> >>+        }
> >>+
> >>+        if (vga_args[i].rc) {
> >>+            XEN_PT_ERR(NULL, "VGA %s unmapping failed! (rc: %i)\n",
> >>+                    vga_args[i].type == IORESOURCE_IO ? "ioport" : "memory",
> >>+                    vga_args[i].rc);
> >>+            return vga_args[i].rc;
> >>+        }
> >>+    }
> >>+
> >>+    return 0;
> >>+}
> >>+
> >>+static int get_vgabios(unsigned char *buf, XenHostPCIDevice *dev)
> >>+{
> >>+    char rom_file[64];
> >>+    FILE *fp;
> >>+    uint8_t val;
> >>+    struct stat st;
> >>+    uint16_t magic = 0;
> >>+    int ret = 0;
> >>+
> >>+    snprintf(rom_file, sizeof(rom_file),
> >>+             "/sys/bus/pci/devices/%04x:%02x:%02x.%d/rom",
> >>+             dev->domain, dev->bus, dev->dev,
> >>+             dev->func);
> >>+
> >>+    if (stat(rom_file, &st)) {
> >>+        return -ENODEV;
> >>+    }
> >>+
> >>+    if (access(rom_file, F_OK)) {
> >>+        XEN_PT_ERR(NULL, "pci-assign: Insufficient privileges for %s",
> >>+                    rom_file);
> >>+        return -ENODEV;
> >>+    }
> >>+
> >>+    /* Write "1" to the ROM file to enable it */
> >>+    fp = fopen(rom_file, "r+");
> >>+    if (fp == NULL) {
> >>+        return -EACCES;
> >>+    }
> >>+    val = 1;
> >>+    if (fwrite(&val, 1, 1, fp) != 1) {
> >>+        XEN_PT_LOG("%s\n", "Failed to enable pci-sysfs rom file");
> >>+        ret = -EIO;
> >>+        goto close_rom;
> >>+    }
> >>+    fseek(fp, 0, SEEK_SET);
> >>+
> >>+    /*
> >>+     * Check if it a real bios extension.
> >>+     * The magic number is 0xAA55.
> >>+     */
> >>+    if (!fread(&magic, sizeof(magic), 1, fp)) {
> >>+        XEN_PT_ERR(NULL, "VGA: can't get magic.\n");
> >>+        ret = -ENODEV;
> >>+        goto close_rom;
> >>+    }
> >>+    if (magic != 0xAA55) {
> >>+        XEN_PT_ERR(NULL, "VGA: wrong magic %x.\n", magic);
> >>+        ret = -ENODEV;
> >>+        goto close_rom;
> >>+    }
> >>+    fseek(fp, 0, SEEK_SET);
> >>+
> >>+    if (!fread(buf, 1, st.st_size, fp)) {
> >>+        XEN_PT_ERR(NULL, "VGA: pci-assign: Cannot read from host %s", rom_file);
> >>+        XEN_PT_LOG(NULL, "VGA: Device option ROM contents are probably invalid "
> >>+                     "(check dmesg).\nSkip option ROM probe with rombar=0, "
> >>+                     "or load from file with romfile=\n");
> >>+    }
> >>+
> >>+close_rom:
> >>+    /* Write "0" to disable ROM */
> >>+    fseek(fp, 0, SEEK_SET);
> >>+    val = 0;
> >>+    if (!fwrite(&val, 1, 1, fp)) {
> >>+        ret = -EIO;
> >>+        XEN_PT_LOG("%s\n", "Failed to disable pci-sysfs rom file");
> >>+    }
> >>+    fclose(fp);
> >>+    return ret;
> >>+}
> >>+
> >>+/* Allocated 128K for the vga bios */
> >>+#define VGA_BIOS_DEFAULT_SIZE (0x20000)
> >>+
> >>+int xen_pt_setup_vga(XenHostPCIDevice *dev)
> >>+{
> >>+    unsigned char *bios = NULL;
> >>+    int bios_size = 0;
> >>+    char *c = NULL;
> >>+    char checksum = 0;
> >>+    int rc = 0;
> >>+
> >>+    if (!is_vga_passthrough(dev)) {
> >>+        return rc;
> >>+    }
> >>+
> >>+    bios = g_malloc0(VGA_BIOS_DEFAULT_SIZE);
> >>+
> >>+    bios_size = get_vgabios(bios, dev);
> >>+    if (bios_size) {
> >>+        XEN_PT_ERR(NULL, "VGA: Error %d getting VBIOS!\n", bios_size);
> >>+        if (bios_size < 0) {
> >>+            XEN_PT_ERR(NULL, "VGA: Error (%s).\n", strerror(bios_size));
> >>+        }
> >>+        rc = -1;
> >>+        goto out;
> >>+    }
> >>+
> >>+    /* Adjust the bios checksum */
> >
> >It's easy to see that you do this here, but *why* do you do it?
> >That's what the comment should explain.
> >Do you see many ROMs with an invalid checksum
> >in the field?
> >
> >>+    for (c = (char *)bios; c < ((char *)bios + bios_size); c++) {
> >>+        checksum += *c;
> >>+    }
> >>+    if (checksum) {
> >>+        bios[bios_size - 1] -= checksum;
> >>+        XEN_PT_LOG(NULL, "vga bios checksum is adjusted!\n");
> >>+    }
> >>+
> >>+    /* Currently we fixed this address as a primary. */
> >>+    cpu_physical_memory_rw(0xc0000, bios, bios_size, 1);
> >>+out:
> >>+    g_free(bios);
> >>+    return rc;
> >>+}
> >>diff --git a/qemu-options.hx b/qemu-options.hx
> >>index ff76ad4..1c77baa 100644
> >>--- a/qemu-options.hx
> >>+++ b/qemu-options.hx
> >>@@ -1066,6 +1066,15 @@ STEXI
> >>  Rotate graphical output some deg left (only PXA LCD).
> >>  ETEXI
> >>
> >>+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
> >>+
> >>  DEF("vga", HAS_ARG, QEMU_OPTION_vga,
> >>      "-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|none]\n"
> >>      "                select video card type\n", QEMU_ARCH_ALL)
> >>diff --git a/vl.c b/vl.c
> >>index a1686ef..c5b572d 100644
> >>--- a/vl.c
> >>+++ b/vl.c
> >>@@ -1418,6 +1418,13 @@ static void configure_msg(QemuOpts *opts)
> >>      enable_timestamp_msg = qemu_opt_get_bool(opts, "timestamp", true);
> >>  }
> >>
> >>+/* We still need this for compatibility with XEN. */
> >>+int xen_has_gfx_passthru;
> >>+static void xen_gfx_passthru(const char *optarg)
> >>+{
> >>+    xen_has_gfx_passthru = 1;
> >>+}
> >>+
> >>  /***********************************************************/
> >>  /* USB devices */
> >>
> >>@@ -3945,6 +3952,9 @@ int main(int argc, char **argv, char **envp)
> >>                      exit(1);
> >>                  }
> >>                  break;
> >>+            case QEMU_OPTION_gfx_passthru:
> >>+                xen_gfx_passthru(optarg);
> >>+                break;
> >>              default:
> >>                  os_parse_cmd_args(popt->index, optarg);
> >>              }
> >>--
> >>1.9.1
> >
> >

[Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Tiejun Chen]

ISA bridge is needed since Intel gfx drive will probe with Dev31:Fun0
to make graphics device passthrough work well for VMM, that only need
to expose this pseudo ISA bridge to let driver know the real hardware
underneath.

The original patch is from Allen Kay <allen.m.kay@intel.com>

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Cc: Allen Kay <allen.m.kay@intel.com>
---
v5:

* Don't set this ISA class property, instead, just fake this ISA bridge
  with 00:1f.0. 

v4:

* Remove some unnecessary "return" in void foo().

v3:

* Fix some typos.
* Improve some return paths.

v2:

* Nothing is changed.

 hw/xen/xen_pt_graphics.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 61 insertions(+)

diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 461e526..974b7e9 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -230,3 +230,64 @@ out:
     g_free(bios);
     return rc;
 }
+
+static uint32_t isa_bridge_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    return pci_default_read_config(d, addr, len);
+}
+
+static void isa_bridge_write_config(PCIDevice *d, uint32_t addr, uint32_t v,
+                                    int len)
+{
+    pci_default_write_config(d, addr, v, len);
+}
+
+static void isa_bridge_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->config_read = isa_bridge_read_config;
+    k->config_write = isa_bridge_write_config;
+};
+
+typedef struct {
+    PCIDevice dev;
+} ISABridgeState;
+
+static TypeInfo isa_bridge_info = {
+    .name          = "pseudo-intel-pch-isa-bridge",
+    .parent        = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(ISABridgeState),
+    .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 int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
+{
+    struct PCIDevice *dev;
+
+    char rid;
+
+    /* We havt to use a simple PCI device to fake this ISA bridge
+     * to avoid making some confusion to BIOS and ACPI.
+     */
+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
+
+    qdev_init_nofail(&dev->qdev);
+
+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
+    pci_config_set_device_id(dev->config, hdev->device_id);
+
+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
+
+    pci_config_set_revision(dev->config, rid);
+
+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
+    return 0;
+}
-- 
1.9.1

[v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Tiejun Chen]

ISA bridge is needed since Intel gfx drive will probe with Dev31:Fun0
to make graphics device passthrough work well for VMM, that only need
to expose this pseudo ISA bridge to let driver know the real hardware
underneath.

The original patch is from Allen Kay <allen.m.kay@intel.com>

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Cc: Allen Kay <allen.m.kay@intel.com>
---
v5:

* Don't set this ISA class property, instead, just fake this ISA bridge
  with 00:1f.0. 

v4:

* Remove some unnecessary "return" in void foo().

v3:

* Fix some typos.
* Improve some return paths.

v2:

* Nothing is changed.

 hw/xen/xen_pt_graphics.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 61 insertions(+)

diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 461e526..974b7e9 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -230,3 +230,64 @@ out:
     g_free(bios);
     return rc;
 }
+
+static uint32_t isa_bridge_read_config(PCIDevice *d, uint32_t addr, int len)
+{
+    return pci_default_read_config(d, addr, len);
+}
+
+static void isa_bridge_write_config(PCIDevice *d, uint32_t addr, uint32_t v,
+                                    int len)
+{
+    pci_default_write_config(d, addr, v, len);
+}
+
+static void isa_bridge_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->config_read = isa_bridge_read_config;
+    k->config_write = isa_bridge_write_config;
+};
+
+typedef struct {
+    PCIDevice dev;
+} ISABridgeState;
+
+static TypeInfo isa_bridge_info = {
+    .name          = "pseudo-intel-pch-isa-bridge",
+    .parent        = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(ISABridgeState),
+    .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 int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
+{
+    struct PCIDevice *dev;
+
+    char rid;
+
+    /* We havt to use a simple PCI device to fake this ISA bridge
+     * to avoid making some confusion to BIOS and ACPI.
+     */
+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
+
+    qdev_init_nofail(&dev->qdev);
+
+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
+    pci_config_set_device_id(dev->config, hdev->device_id);
+
+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
+
+    pci_config_set_revision(dev->config, rid);
+
+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
+    return 0;
+}
-- 
1.9.1

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Paolo Bonzini]

Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
> +{
> +    struct PCIDevice *dev;
> +
> +    char rid;
> +
> +    /* We havt to use a simple PCI device to fake this ISA bridge
> +     * to avoid making some confusion to BIOS and ACPI.
> +     */
> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
> +
> +    qdev_init_nofail(&dev->qdev);
> +
> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> +    pci_config_set_device_id(dev->config, hdev->device_id);
> +
> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> +
> +    pci_config_set_revision(dev->config, rid);
> +
> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> +    return 0;
> +}

This patch doesn't compile on its own (this static function is unused).

pci_create_pch should be moved in this patch.

Paolo

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Paolo Bonzini]

Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
> +{
> +    struct PCIDevice *dev;
> +
> +    char rid;
> +
> +    /* We havt to use a simple PCI device to fake this ISA bridge
> +     * to avoid making some confusion to BIOS and ACPI.
> +     */
> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
> +
> +    qdev_init_nofail(&dev->qdev);
> +
> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> +    pci_config_set_device_id(dev->config, hdev->device_id);
> +
> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> +
> +    pci_config_set_revision(dev->config, rid);
> +
> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> +    return 0;
> +}

This patch doesn't compile on its own (this static function is unused).

pci_create_pch should be moved in this patch.

Paolo

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 14:22, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>> *hdev)
>> +{
>> +    struct PCIDevice *dev;
>> +
>> +    char rid;
>> +
>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>> +     * to avoid making some confusion to BIOS and ACPI.
>> +     */
>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>> "pseudo-intel-pch-isa-bridge");
>> +
>> +    qdev_init_nofail(&dev->qdev);
>> +
>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>> +
>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>> +
>> +    pci_config_set_revision(dev->config, rid);
>> +
>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>> +    return 0;
>> +}
>
> This patch doesn't compile on its own (this static function is unused).
>
> pci_create_pch should be moved in this patch.
>

Okay I will try this.

Thanks
Tiejun

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 14:22, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>> *hdev)
>> +{
>> +    struct PCIDevice *dev;
>> +
>> +    char rid;
>> +
>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>> +     * to avoid making some confusion to BIOS and ACPI.
>> +     */
>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>> "pseudo-intel-pch-isa-bridge");
>> +
>> +    qdev_init_nofail(&dev->qdev);
>> +
>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>> +
>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>> +
>> +    pci_config_set_revision(dev->config, rid);
>> +
>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>> +    return 0;
>> +}
>
> This patch doesn't compile on its own (this static function is unused).
>
> pci_create_pch should be moved in this patch.
>

Okay I will try this.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:17:18AM +0800, Tiejun Chen wrote:
> ISA bridge is needed since Intel gfx drive will probe with Dev31:Fun0
> to make graphics device passthrough work well for VMM, that only need
> to expose this pseudo ISA bridge to let driver know the real hardware
> underneath.
> 
> The original patch is from Allen Kay <allen.m.kay@intel.com>
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> Cc: Allen Kay <allen.m.kay@intel.com>
> ---
> v5:
> 
> * Don't set this ISA class property, instead, just fake this ISA bridge
>   with 00:1f.0. 
> 
> v4:
> 
> * Remove some unnecessary "return" in void foo().
> 
> v3:
> 
> * Fix some typos.
> * Improve some return paths.
> 
> v2:
> 
> * Nothing is changed.
> 
>  hw/xen/xen_pt_graphics.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 61 insertions(+)
> 
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> index 461e526..974b7e9 100644
> --- a/hw/xen/xen_pt_graphics.c
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -230,3 +230,64 @@ out:
>      g_free(bios);
>      return rc;
>  }
> +
> +static uint32_t isa_bridge_read_config(PCIDevice *d, uint32_t addr, int len)
> +{
> +    return pci_default_read_config(d, addr, len);
> +}
> +
> +static void isa_bridge_write_config(PCIDevice *d, uint32_t addr, uint32_t v,
> +                                    int len)
> +{
> +    pci_default_write_config(d, addr, v, len);
> +}
> +
> +static void isa_bridge_class_init(ObjectClass *klass, void *data)
> +{
> +    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> +
> +    k->config_read = isa_bridge_read_config;
> +    k->config_write = isa_bridge_write_config;
> +};

You don't need these stubs, just don't fill anything,
pci core will use defaults then.

> +
> +typedef struct {
> +    PCIDevice dev;
> +} ISABridgeState;
> +

Nor do you need an empty structure if it has no state.

> +static TypeInfo isa_bridge_info = {
> +    .name          = "pseudo-intel-pch-isa-bridge",
> +    .parent        = TYPE_PCI_DEVICE,
> +    .instance_size = sizeof(ISABridgeState),
> +    .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 int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
> +{
> +    struct PCIDevice *dev;
> +
> +    char rid;
> +
> +    /* We havt to use a simple PCI device to fake this ISA bridge
> +     * to avoid making some confusion to BIOS and ACPI.
> +     */

A typo and confusing wording above, I'm not really
sure what this comment means.
Maybe:

/* Create a fake ISA bridge device at the location expected by guests. */


> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
> +
> +    qdev_init_nofail(&dev->qdev);
> +
> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> +    pci_config_set_device_id(dev->config, hdev->device_id);
> +
> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);

Host PCI device is the VGA card?
So why does it make sense to get it's vendor/device/revision and
stick in the ISA bridge?

Also change rid to uint8_t, you won't need to cast then.

> +
> +    pci_config_set_revision(dev->config, rid);
> +
> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> +    return 0;
> +}
> -- 
> 1.9.1

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:17:18AM +0800, Tiejun Chen wrote:
> ISA bridge is needed since Intel gfx drive will probe with Dev31:Fun0
> to make graphics device passthrough work well for VMM, that only need
> to expose this pseudo ISA bridge to let driver know the real hardware
> underneath.
> 
> The original patch is from Allen Kay <allen.m.kay@intel.com>
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> Cc: Allen Kay <allen.m.kay@intel.com>
> ---
> v5:
> 
> * Don't set this ISA class property, instead, just fake this ISA bridge
>   with 00:1f.0. 
> 
> v4:
> 
> * Remove some unnecessary "return" in void foo().
> 
> v3:
> 
> * Fix some typos.
> * Improve some return paths.
> 
> v2:
> 
> * Nothing is changed.
> 
>  hw/xen/xen_pt_graphics.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 61 insertions(+)
> 
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> index 461e526..974b7e9 100644
> --- a/hw/xen/xen_pt_graphics.c
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -230,3 +230,64 @@ out:
>      g_free(bios);
>      return rc;
>  }
> +
> +static uint32_t isa_bridge_read_config(PCIDevice *d, uint32_t addr, int len)
> +{
> +    return pci_default_read_config(d, addr, len);
> +}
> +
> +static void isa_bridge_write_config(PCIDevice *d, uint32_t addr, uint32_t v,
> +                                    int len)
> +{
> +    pci_default_write_config(d, addr, v, len);
> +}
> +
> +static void isa_bridge_class_init(ObjectClass *klass, void *data)
> +{
> +    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> +
> +    k->config_read = isa_bridge_read_config;
> +    k->config_write = isa_bridge_write_config;
> +};

You don't need these stubs, just don't fill anything,
pci core will use defaults then.

> +
> +typedef struct {
> +    PCIDevice dev;
> +} ISABridgeState;
> +

Nor do you need an empty structure if it has no state.

> +static TypeInfo isa_bridge_info = {
> +    .name          = "pseudo-intel-pch-isa-bridge",
> +    .parent        = TYPE_PCI_DEVICE,
> +    .instance_size = sizeof(ISABridgeState),
> +    .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 int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
> +{
> +    struct PCIDevice *dev;
> +
> +    char rid;
> +
> +    /* We havt to use a simple PCI device to fake this ISA bridge
> +     * to avoid making some confusion to BIOS and ACPI.
> +     */

A typo and confusing wording above, I'm not really
sure what this comment means.
Maybe:

/* Create a fake ISA bridge device at the location expected by guests. */


> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
> +
> +    qdev_init_nofail(&dev->qdev);
> +
> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> +    pci_config_set_device_id(dev->config, hdev->device_id);
> +
> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);

Host PCI device is the VGA card?
So why does it make sense to get it's vendor/device/revision and
stick in the ISA bridge?

Also change rid to uint8_t, you won't need to cast then.

> +
> +    pci_config_set_revision(dev->config, rid);
> +
> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> +    return 0;
> +}
> -- 
> 1.9.1

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 14:45, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:17:18AM +0800, Tiejun Chen wrote:
>> ISA bridge is needed since Intel gfx drive will probe with Dev31:Fun0
>> to make graphics device passthrough work well for VMM, that only need
>> to expose this pseudo ISA bridge to let driver know the real hardware
>> underneath.
>>
>> The original patch is from Allen Kay <allen.m.kay@intel.com>
>>
>> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> Cc: Allen Kay <allen.m.kay@intel.com>
>> ---
>> v5:
>>
>> * Don't set this ISA class property, instead, just fake this ISA bridge
>>    with 00:1f.0.
>>
>> v4:
>>
>> * Remove some unnecessary "return" in void foo().
>>
>> v3:
>>
>> * Fix some typos.
>> * Improve some return paths.
>>
>> v2:
>>
>> * Nothing is changed.
>>
>>   hw/xen/xen_pt_graphics.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 61 insertions(+)
>>
>> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
>> index 461e526..974b7e9 100644
>> --- a/hw/xen/xen_pt_graphics.c
>> +++ b/hw/xen/xen_pt_graphics.c
>> @@ -230,3 +230,64 @@ out:
>>       g_free(bios);
>>       return rc;
>>   }
>> +
>> +static uint32_t isa_bridge_read_config(PCIDevice *d, uint32_t addr, int len)
>> +{
>> +    return pci_default_read_config(d, addr, len);
>> +}
>> +
>> +static void isa_bridge_write_config(PCIDevice *d, uint32_t addr, uint32_t v,
>> +                                    int len)
>> +{
>> +    pci_default_write_config(d, addr, v, len);
>> +}
>> +
>> +static void isa_bridge_class_init(ObjectClass *klass, void *data)
>> +{
>> +    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>> +
>> +    k->config_read = isa_bridge_read_config;
>> +    k->config_write = isa_bridge_write_config;
>> +};
>
> You don't need these stubs, just don't fill anything,
> pci core will use defaults then.

I guess these stubs are left to extend something in the future. But 
maybe we can remove them now.

>
>> +
>> +typedef struct {
>> +    PCIDevice dev;
>> +} ISABridgeState;
>> +
>
> Nor do you need an empty structure if it has no state.
>
>> +static TypeInfo isa_bridge_info = {
>> +    .name          = "pseudo-intel-pch-isa-bridge",
>> +    .parent        = TYPE_PCI_DEVICE,
>> +    .instance_size = sizeof(ISABridgeState),
>> +    .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 int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
>> +{
>> +    struct PCIDevice *dev;
>> +
>> +    char rid;
>> +
>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>> +     * to avoid making some confusion to BIOS and ACPI.
>> +     */
>
> A typo and confusing wording above, I'm not really
> sure what this comment means.
> Maybe:
>
> /* Create a fake ISA bridge device at the location expected by guests. */
>

Good comments so thanks so much.

>
>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
>> +
>> +    qdev_init_nofail(&dev->qdev);
>> +
>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>> +
>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>
> Host PCI device is the VGA card?

This is a real ISA bridge.

> So why does it make sense to get it's vendor/device/revision and
> stick in the ISA bridge?

The Intel generation of integrated graphics needs to probe this ISA 
bridge to initialize the i915 driver properly.

Thanks
Tiejun

>
> Also change rid to uint8_t, you won't need to cast then.
>
>> +
>> +    pci_config_set_revision(dev->config, rid);
>> +
>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>> +    return 0;
>> +}
>> --
>> 1.9.1
>
>

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 14:45, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:17:18AM +0800, Tiejun Chen wrote:
>> ISA bridge is needed since Intel gfx drive will probe with Dev31:Fun0
>> to make graphics device passthrough work well for VMM, that only need
>> to expose this pseudo ISA bridge to let driver know the real hardware
>> underneath.
>>
>> The original patch is from Allen Kay <allen.m.kay@intel.com>
>>
>> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> Cc: Allen Kay <allen.m.kay@intel.com>
>> ---
>> v5:
>>
>> * Don't set this ISA class property, instead, just fake this ISA bridge
>>    with 00:1f.0.
>>
>> v4:
>>
>> * Remove some unnecessary "return" in void foo().
>>
>> v3:
>>
>> * Fix some typos.
>> * Improve some return paths.
>>
>> v2:
>>
>> * Nothing is changed.
>>
>>   hw/xen/xen_pt_graphics.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 61 insertions(+)
>>
>> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
>> index 461e526..974b7e9 100644
>> --- a/hw/xen/xen_pt_graphics.c
>> +++ b/hw/xen/xen_pt_graphics.c
>> @@ -230,3 +230,64 @@ out:
>>       g_free(bios);
>>       return rc;
>>   }
>> +
>> +static uint32_t isa_bridge_read_config(PCIDevice *d, uint32_t addr, int len)
>> +{
>> +    return pci_default_read_config(d, addr, len);
>> +}
>> +
>> +static void isa_bridge_write_config(PCIDevice *d, uint32_t addr, uint32_t v,
>> +                                    int len)
>> +{
>> +    pci_default_write_config(d, addr, v, len);
>> +}
>> +
>> +static void isa_bridge_class_init(ObjectClass *klass, void *data)
>> +{
>> +    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>> +
>> +    k->config_read = isa_bridge_read_config;
>> +    k->config_write = isa_bridge_write_config;
>> +};
>
> You don't need these stubs, just don't fill anything,
> pci core will use defaults then.

I guess these stubs are left to extend something in the future. But 
maybe we can remove them now.

>
>> +
>> +typedef struct {
>> +    PCIDevice dev;
>> +} ISABridgeState;
>> +
>
> Nor do you need an empty structure if it has no state.
>
>> +static TypeInfo isa_bridge_info = {
>> +    .name          = "pseudo-intel-pch-isa-bridge",
>> +    .parent        = TYPE_PCI_DEVICE,
>> +    .instance_size = sizeof(ISABridgeState),
>> +    .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 int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
>> +{
>> +    struct PCIDevice *dev;
>> +
>> +    char rid;
>> +
>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>> +     * to avoid making some confusion to BIOS and ACPI.
>> +     */
>
> A typo and confusing wording above, I'm not really
> sure what this comment means.
> Maybe:
>
> /* Create a fake ISA bridge device at the location expected by guests. */
>

Good comments so thanks so much.

>
>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
>> +
>> +    qdev_init_nofail(&dev->qdev);
>> +
>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>> +
>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>
> Host PCI device is the VGA card?

This is a real ISA bridge.

> So why does it make sense to get it's vendor/device/revision and
> stick in the ISA bridge?

The Intel generation of integrated graphics needs to probe this ISA 
bridge to initialize the i915 driver properly.

Thanks
Tiejun

>
> Also change rid to uint8_t, you won't need to cast then.
>
>> +
>> +    pci_config_set_revision(dev->config, rid);
>> +
>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>> +    return 0;
>> +}
>> --
>> 1.9.1
>
>

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 04:10:44PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 14:45, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:17:18AM +0800, Tiejun Chen wrote:
> >>ISA bridge is needed since Intel gfx drive will probe with Dev31:Fun0
> >>to make graphics device passthrough work well for VMM, that only need
> >>to expose this pseudo ISA bridge to let driver know the real hardware
> >>underneath.
> >>
> >>The original patch is from Allen Kay <allen.m.kay@intel.com>
> >>
> >>Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>Cc: Allen Kay <allen.m.kay@intel.com>
> >>---
> >>v5:
> >>
> >>* Don't set this ISA class property, instead, just fake this ISA bridge
> >>   with 00:1f.0.
> >>
> >>v4:
> >>
> >>* Remove some unnecessary "return" in void foo().
> >>
> >>v3:
> >>
> >>* Fix some typos.
> >>* Improve some return paths.
> >>
> >>v2:
> >>
> >>* Nothing is changed.
> >>
> >>  hw/xen/xen_pt_graphics.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 61 insertions(+)
> >>
> >>diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> >>index 461e526..974b7e9 100644
> >>--- a/hw/xen/xen_pt_graphics.c
> >>+++ b/hw/xen/xen_pt_graphics.c
> >>@@ -230,3 +230,64 @@ out:
> >>      g_free(bios);
> >>      return rc;
> >>  }
> >>+
> >>+static uint32_t isa_bridge_read_config(PCIDevice *d, uint32_t addr, int len)
> >>+{
> >>+    return pci_default_read_config(d, addr, len);
> >>+}
> >>+
> >>+static void isa_bridge_write_config(PCIDevice *d, uint32_t addr, uint32_t v,
> >>+                                    int len)
> >>+{
> >>+    pci_default_write_config(d, addr, v, len);
> >>+}
> >>+
> >>+static void isa_bridge_class_init(ObjectClass *klass, void *data)
> >>+{
> >>+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> >>+
> >>+    k->config_read = isa_bridge_read_config;
> >>+    k->config_write = isa_bridge_write_config;
> >>+};
> >
> >You don't need these stubs, just don't fill anything,
> >pci core will use defaults then.
> 
> I guess these stubs are left to extend something in the future. But maybe we
> can remove them now.
> 
> >
> >>+
> >>+typedef struct {
> >>+    PCIDevice dev;
> >>+} ISABridgeState;
> >>+
> >
> >Nor do you need an empty structure if it has no state.
> >
> >>+static TypeInfo isa_bridge_info = {
> >>+    .name          = "pseudo-intel-pch-isa-bridge",
> >>+    .parent        = TYPE_PCI_DEVICE,
> >>+    .instance_size = sizeof(ISABridgeState),
> >>+    .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 int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
> >>+{
> >>+    struct PCIDevice *dev;
> >>+
> >>+    char rid;
> >>+
> >>+    /* We havt to use a simple PCI device to fake this ISA bridge
> >>+     * to avoid making some confusion to BIOS and ACPI.
> >>+     */
> >
> >A typo and confusing wording above, I'm not really
> >sure what this comment means.
> >Maybe:
> >
> >/* Create a fake ISA bridge device at the location expected by guests. */
> >
> 
> Good comments so thanks so much.
> 
> >
> >>+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
> >>+
> >>+    qdev_init_nofail(&dev->qdev);
> >>+
> >>+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> >>+    pci_config_set_device_id(dev->config, hdev->device_id);
> >>+
> >>+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> >
> >Host PCI device is the VGA card?
> 
> This is a real ISA bridge.
> 
> >So why does it make sense to get it's vendor/device/revision and
> >stick in the ISA bridge?
> 
> The Intel generation of integrated graphics needs to probe this ISA bridge
> to initialize the i915 driver properly.
> 
> Thanks
> Tiejun

So vendor/device/revision IDs must match real device then?
Stick this in the comment then.

In fact it's exactly what passthrough does.
I wonder if more bits from ./hw/i386/kvm/pci-assign.c
can be reused. How do you poke at the host device? sysfs?



> >
> >Also change rid to uint8_t, you won't need to cast then.
> >
> >>+
> >>+    pci_config_set_revision(dev->config, rid);
> >>+
> >>+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> >>+    return 0;
> >>+}
> >>--
> >>1.9.1
> >
> >

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 04:10:44PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 14:45, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:17:18AM +0800, Tiejun Chen wrote:
> >>ISA bridge is needed since Intel gfx drive will probe with Dev31:Fun0
> >>to make graphics device passthrough work well for VMM, that only need
> >>to expose this pseudo ISA bridge to let driver know the real hardware
> >>underneath.
> >>
> >>The original patch is from Allen Kay <allen.m.kay@intel.com>
> >>
> >>Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>Cc: Allen Kay <allen.m.kay@intel.com>
> >>---
> >>v5:
> >>
> >>* Don't set this ISA class property, instead, just fake this ISA bridge
> >>   with 00:1f.0.
> >>
> >>v4:
> >>
> >>* Remove some unnecessary "return" in void foo().
> >>
> >>v3:
> >>
> >>* Fix some typos.
> >>* Improve some return paths.
> >>
> >>v2:
> >>
> >>* Nothing is changed.
> >>
> >>  hw/xen/xen_pt_graphics.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 61 insertions(+)
> >>
> >>diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> >>index 461e526..974b7e9 100644
> >>--- a/hw/xen/xen_pt_graphics.c
> >>+++ b/hw/xen/xen_pt_graphics.c
> >>@@ -230,3 +230,64 @@ out:
> >>      g_free(bios);
> >>      return rc;
> >>  }
> >>+
> >>+static uint32_t isa_bridge_read_config(PCIDevice *d, uint32_t addr, int len)
> >>+{
> >>+    return pci_default_read_config(d, addr, len);
> >>+}
> >>+
> >>+static void isa_bridge_write_config(PCIDevice *d, uint32_t addr, uint32_t v,
> >>+                                    int len)
> >>+{
> >>+    pci_default_write_config(d, addr, v, len);
> >>+}
> >>+
> >>+static void isa_bridge_class_init(ObjectClass *klass, void *data)
> >>+{
> >>+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> >>+
> >>+    k->config_read = isa_bridge_read_config;
> >>+    k->config_write = isa_bridge_write_config;
> >>+};
> >
> >You don't need these stubs, just don't fill anything,
> >pci core will use defaults then.
> 
> I guess these stubs are left to extend something in the future. But maybe we
> can remove them now.
> 
> >
> >>+
> >>+typedef struct {
> >>+    PCIDevice dev;
> >>+} ISABridgeState;
> >>+
> >
> >Nor do you need an empty structure if it has no state.
> >
> >>+static TypeInfo isa_bridge_info = {
> >>+    .name          = "pseudo-intel-pch-isa-bridge",
> >>+    .parent        = TYPE_PCI_DEVICE,
> >>+    .instance_size = sizeof(ISABridgeState),
> >>+    .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 int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
> >>+{
> >>+    struct PCIDevice *dev;
> >>+
> >>+    char rid;
> >>+
> >>+    /* We havt to use a simple PCI device to fake this ISA bridge
> >>+     * to avoid making some confusion to BIOS and ACPI.
> >>+     */
> >
> >A typo and confusing wording above, I'm not really
> >sure what this comment means.
> >Maybe:
> >
> >/* Create a fake ISA bridge device at the location expected by guests. */
> >
> 
> Good comments so thanks so much.
> 
> >
> >>+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
> >>+
> >>+    qdev_init_nofail(&dev->qdev);
> >>+
> >>+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> >>+    pci_config_set_device_id(dev->config, hdev->device_id);
> >>+
> >>+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> >
> >Host PCI device is the VGA card?
> 
> This is a real ISA bridge.
> 
> >So why does it make sense to get it's vendor/device/revision and
> >stick in the ISA bridge?
> 
> The Intel generation of integrated graphics needs to probe this ISA bridge
> to initialize the i915 driver properly.
> 
> Thanks
> Tiejun

So vendor/device/revision IDs must match real device then?
Stick this in the comment then.

In fact it's exactly what passthrough does.
I wonder if more bits from ./hw/i386/kvm/pci-assign.c
can be reused. How do you poke at the host device? sysfs?



> >
> >Also change rid to uint8_t, you won't need to cast then.
> >
> >>+
> >>+    pci_config_set_revision(dev->config, rid);
> >>+
> >>+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> >>+    return 0;
> >>+}
> >>--
> >>1.9.1
> >
> >

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 16:28, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 04:10:44PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 14:45, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 10:17:18AM +0800, Tiejun Chen wrote:
>>>> ISA bridge is needed since Intel gfx drive will probe with Dev31:Fun0
>>>> to make graphics device passthrough work well for VMM, that only need
>>>> to expose this pseudo ISA bridge to let driver know the real hardware
>>>> underneath.
>>>>
>>>> The original patch is from Allen Kay <allen.m.kay@intel.com>
>>>>
>>>> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>> Cc: Allen Kay <allen.m.kay@intel.com>
>>>> ---
>>>> v5:
>>>>
>>>> * Don't set this ISA class property, instead, just fake this ISA bridge
>>>>    with 00:1f.0.
>>>>
>>>> v4:
>>>>
>>>> * Remove some unnecessary "return" in void foo().
>>>>
>>>> v3:
>>>>
>>>> * Fix some typos.
>>>> * Improve some return paths.
>>>>
>>>> v2:
>>>>
>>>> * Nothing is changed.
>>>>
>>>>   hw/xen/xen_pt_graphics.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>   1 file changed, 61 insertions(+)
>>>>
>>>> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
>>>> index 461e526..974b7e9 100644
>>>> --- a/hw/xen/xen_pt_graphics.c
>>>> +++ b/hw/xen/xen_pt_graphics.c
>>>> @@ -230,3 +230,64 @@ out:
>>>>       g_free(bios);
>>>>       return rc;
>>>>   }
>>>> +
>>>> +static uint32_t isa_bridge_read_config(PCIDevice *d, uint32_t addr, int len)
>>>> +{
>>>> +    return pci_default_read_config(d, addr, len);
>>>> +}
>>>> +
>>>> +static void isa_bridge_write_config(PCIDevice *d, uint32_t addr, uint32_t v,
>>>> +                                    int len)
>>>> +{
>>>> +    pci_default_write_config(d, addr, v, len);
>>>> +}
>>>> +
>>>> +static void isa_bridge_class_init(ObjectClass *klass, void *data)
>>>> +{
>>>> +    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>>>> +
>>>> +    k->config_read = isa_bridge_read_config;
>>>> +    k->config_write = isa_bridge_write_config;
>>>> +};
>>>
>>> You don't need these stubs, just don't fill anything,
>>> pci core will use defaults then.
>>
>> I guess these stubs are left to extend something in the future. But maybe we
>> can remove them now.
>>
>>>
>>>> +
>>>> +typedef struct {
>>>> +    PCIDevice dev;
>>>> +} ISABridgeState;
>>>> +
>>>
>>> Nor do you need an empty structure if it has no state.
>>>
>>>> +static TypeInfo isa_bridge_info = {
>>>> +    .name          = "pseudo-intel-pch-isa-bridge",
>>>> +    .parent        = TYPE_PCI_DEVICE,
>>>> +    .instance_size = sizeof(ISABridgeState),
>>>> +    .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 int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
>>>> +{
>>>> +    struct PCIDevice *dev;
>>>> +
>>>> +    char rid;
>>>> +
>>>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>>>> +     * to avoid making some confusion to BIOS and ACPI.
>>>> +     */
>>>
>>> A typo and confusing wording above, I'm not really
>>> sure what this comment means.
>>> Maybe:
>>>
>>> /* Create a fake ISA bridge device at the location expected by guests. */
>>>
>>
>> Good comments so thanks so much.
>>
>>>
>>>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
>>>> +
>>>> +    qdev_init_nofail(&dev->qdev);
>>>> +
>>>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>>>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>>>> +
>>>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>>>
>>> Host PCI device is the VGA card?
>>
>> This is a real ISA bridge.
>>
>>> So why does it make sense to get it's vendor/device/revision and
>>> stick in the ISA bridge?
>>
>> The Intel generation of integrated graphics needs to probe this ISA bridge
>> to initialize the i915 driver properly.
>>
>> Thanks
>> Tiejun
>
> So vendor/device/revision IDs must match real device then?

Yes, the i915 driver needs these information of PCH to determine how to 
work. And this is just why we expose this ISA bridge to guest ugly :(

> Stick this in the comment then.
>

Sure.

> In fact it's exactly what passthrough does.
> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> can be reused. How do you poke at the host device? sysfs?

Yes, sysfs.

Thanks
Tiejun

>
>
>
>>>
>>> Also change rid to uint8_t, you won't need to cast then.
>>>
>>>> +
>>>> +    pci_config_set_revision(dev->config, rid);
>>>> +
>>>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>>> +    return 0;
>>>> +}
>>>> --
>>>> 1.9.1
>>>
>>>
>
>
>

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 16:28, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 04:10:44PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 14:45, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 10:17:18AM +0800, Tiejun Chen wrote:
>>>> ISA bridge is needed since Intel gfx drive will probe with Dev31:Fun0
>>>> to make graphics device passthrough work well for VMM, that only need
>>>> to expose this pseudo ISA bridge to let driver know the real hardware
>>>> underneath.
>>>>
>>>> The original patch is from Allen Kay <allen.m.kay@intel.com>
>>>>
>>>> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>> Cc: Allen Kay <allen.m.kay@intel.com>
>>>> ---
>>>> v5:
>>>>
>>>> * Don't set this ISA class property, instead, just fake this ISA bridge
>>>>    with 00:1f.0.
>>>>
>>>> v4:
>>>>
>>>> * Remove some unnecessary "return" in void foo().
>>>>
>>>> v3:
>>>>
>>>> * Fix some typos.
>>>> * Improve some return paths.
>>>>
>>>> v2:
>>>>
>>>> * Nothing is changed.
>>>>
>>>>   hw/xen/xen_pt_graphics.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>   1 file changed, 61 insertions(+)
>>>>
>>>> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
>>>> index 461e526..974b7e9 100644
>>>> --- a/hw/xen/xen_pt_graphics.c
>>>> +++ b/hw/xen/xen_pt_graphics.c
>>>> @@ -230,3 +230,64 @@ out:
>>>>       g_free(bios);
>>>>       return rc;
>>>>   }
>>>> +
>>>> +static uint32_t isa_bridge_read_config(PCIDevice *d, uint32_t addr, int len)
>>>> +{
>>>> +    return pci_default_read_config(d, addr, len);
>>>> +}
>>>> +
>>>> +static void isa_bridge_write_config(PCIDevice *d, uint32_t addr, uint32_t v,
>>>> +                                    int len)
>>>> +{
>>>> +    pci_default_write_config(d, addr, v, len);
>>>> +}
>>>> +
>>>> +static void isa_bridge_class_init(ObjectClass *klass, void *data)
>>>> +{
>>>> +    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>>>> +
>>>> +    k->config_read = isa_bridge_read_config;
>>>> +    k->config_write = isa_bridge_write_config;
>>>> +};
>>>
>>> You don't need these stubs, just don't fill anything,
>>> pci core will use defaults then.
>>
>> I guess these stubs are left to extend something in the future. But maybe we
>> can remove them now.
>>
>>>
>>>> +
>>>> +typedef struct {
>>>> +    PCIDevice dev;
>>>> +} ISABridgeState;
>>>> +
>>>
>>> Nor do you need an empty structure if it has no state.
>>>
>>>> +static TypeInfo isa_bridge_info = {
>>>> +    .name          = "pseudo-intel-pch-isa-bridge",
>>>> +    .parent        = TYPE_PCI_DEVICE,
>>>> +    .instance_size = sizeof(ISABridgeState),
>>>> +    .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 int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
>>>> +{
>>>> +    struct PCIDevice *dev;
>>>> +
>>>> +    char rid;
>>>> +
>>>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>>>> +     * to avoid making some confusion to BIOS and ACPI.
>>>> +     */
>>>
>>> A typo and confusing wording above, I'm not really
>>> sure what this comment means.
>>> Maybe:
>>>
>>> /* Create a fake ISA bridge device at the location expected by guests. */
>>>
>>
>> Good comments so thanks so much.
>>
>>>
>>>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), "pseudo-intel-pch-isa-bridge");
>>>> +
>>>> +    qdev_init_nofail(&dev->qdev);
>>>> +
>>>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>>>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>>>> +
>>>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>>>
>>> Host PCI device is the VGA card?
>>
>> This is a real ISA bridge.
>>
>>> So why does it make sense to get it's vendor/device/revision and
>>> stick in the ISA bridge?
>>
>> The Intel generation of integrated graphics needs to probe this ISA bridge
>> to initialize the i915 driver properly.
>>
>> Thanks
>> Tiejun
>
> So vendor/device/revision IDs must match real device then?

Yes, the i915 driver needs these information of PCH to determine how to 
work. And this is just why we expose this ISA bridge to guest ugly :(

> Stick this in the comment then.
>

Sure.

> In fact it's exactly what passthrough does.
> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> can be reused. How do you poke at the host device? sysfs?

Yes, sysfs.

Thanks
Tiejun

>
>
>
>>>
>>> Also change rid to uint8_t, you won't need to cast then.
>>>
>>>> +
>>>> +    pci_config_set_revision(dev->config, rid);
>>>> +
>>>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>>> +    return 0;
>>>> +}
>>>> --
>>>> 1.9.1
>>>
>>>
>
>
>

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> >In fact it's exactly what passthrough does.
> >I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> >can be reused. How do you poke at the host device? sysfs?
> 
> Yes, sysfs.
> 
> Thanks
> Tiejun

Then you should be able to re-use large chunks of
./hw/i386/kvm/pci-assign.c: basically everything
that deals with emulation.

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> >In fact it's exactly what passthrough does.
> >I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> >can be reused. How do you poke at the host device? sysfs?
> 
> Yes, sysfs.
> 
> Thanks
> Tiejun

Then you should be able to re-use large chunks of
./hw/i386/kvm/pci-assign.c: basically everything
that deals with emulation.

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>> In fact it's exactly what passthrough does.
>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>> can be reused. How do you poke at the host device? sysfs?
>>
>> Yes, sysfs.
>>
>> Thanks
>> Tiejun
>
> Then you should be able to re-use large chunks of
> ./hw/i386/kvm/pci-assign.c: basically everything
> that deals with emulation.

Do you mean those hooks to get info from the real device? Xen have its 
own wrapper, xen_host_pci_get_block(), so we always go there in xen 
scenario.

Thanks
Tiejun
>
>
>
>

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>> In fact it's exactly what passthrough does.
>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>> can be reused. How do you poke at the host device? sysfs?
>>
>> Yes, sysfs.
>>
>> Thanks
>> Tiejun
>
> Then you should be able to re-use large chunks of
> ./hw/i386/kvm/pci-assign.c: basically everything
> that deals with emulation.

Do you mean those hooks to get info from the real device? Xen have its 
own wrapper, xen_host_pci_get_block(), so we always go there in xen 
scenario.

Thanks
Tiejun
>
>
>
>

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> >>>In fact it's exactly what passthrough does.
> >>>I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> >>>can be reused. How do you poke at the host device? sysfs?
> >>
> >>Yes, sysfs.
> >>
> >>Thanks
> >>Tiejun
> >
> >Then you should be able to re-use large chunks of
> >./hw/i386/kvm/pci-assign.c: basically everything
> >that deals with emulation.
> 
> Do you mean those hooks to get info from the real device? Xen have its own
> wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
> 
> Thanks
> Tiejun

Yes and that's not good.  We have two pieces of code doing mostly
identical things slightly differently.
hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
but these really need to be unified.

> >
> >
> >
> >

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> >>>In fact it's exactly what passthrough does.
> >>>I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> >>>can be reused. How do you poke at the host device? sysfs?
> >>
> >>Yes, sysfs.
> >>
> >>Thanks
> >>Tiejun
> >
> >Then you should be able to re-use large chunks of
> >./hw/i386/kvm/pci-assign.c: basically everything
> >that deals with emulation.
> 
> Do you mean those hooks to get info from the real device? Xen have its own
> wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
> 
> Thanks
> Tiejun

Yes and that's not good.  We have two pieces of code doing mostly
identical things slightly differently.
hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
but these really need to be unified.

> >
> >
> >
> >

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>> In fact it's exactly what passthrough does.
>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>
>>>> Yes, sysfs.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> Then you should be able to re-use large chunks of
>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>> that deals with emulation.
>>
>> Do you mean those hooks to get info from the real device? Xen have its own
>> wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
>>
>> Thanks
>> Tiejun
>
> Yes and that's not good.  We have two pieces of code doing mostly
> identical things slightly differently.
> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> but these really need to be unified.
>

Sorry, take a look at this again,

xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
	|
	+ xen_host_pci_config_read(d, pos, buf, len)
		|
		+ pread(d->config_fd, buf, len, pos)

I thinks this should be same as kvm.

Thanks
Tiejun

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>> In fact it's exactly what passthrough does.
>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>
>>>> Yes, sysfs.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> Then you should be able to re-use large chunks of
>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>> that deals with emulation.
>>
>> Do you mean those hooks to get info from the real device? Xen have its own
>> wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
>>
>> Thanks
>> Tiejun
>
> Yes and that's not good.  We have two pieces of code doing mostly
> identical things slightly differently.
> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> but these really need to be unified.
>

Sorry, take a look at this again,

xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
	|
	+ xen_host_pci_config_read(d, pos, buf, len)
		|
		+ pread(d->config_fd, buf, len, pos)

I thinks this should be same as kvm.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> >>>>>In fact it's exactly what passthrough does.
> >>>>>I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> >>>>>can be reused. How do you poke at the host device? sysfs?
> >>>>
> >>>>Yes, sysfs.
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>Then you should be able to re-use large chunks of
> >>>./hw/i386/kvm/pci-assign.c: basically everything
> >>>that deals with emulation.
> >>
> >>Do you mean those hooks to get info from the real device? Xen have its own
> >>wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
> >>
> >>Thanks
> >>Tiejun
> >
> >Yes and that's not good.  We have two pieces of code doing mostly
> >identical things slightly differently.
> >hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> >but these really need to be unified.
> >
> 
> Sorry, take a look at this again,
> 
> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
> 	|
> 	+ xen_host_pci_config_read(d, pos, buf, len)
> 		|
> 		+ pread(d->config_fd, buf, len, pos)
> 
> I thinks this should be same as kvm.
> 
> Thanks
> Tiejun

get_block is trivial.

I really mean the whole PT infrastructure for
- discovering host devices through sysfs
- virtualizing devices

rom, bars, msi ...
the list goes on.

logic is mostly the same.



-- 
MST

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> >>>>>In fact it's exactly what passthrough does.
> >>>>>I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> >>>>>can be reused. How do you poke at the host device? sysfs?
> >>>>
> >>>>Yes, sysfs.
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>Then you should be able to re-use large chunks of
> >>>./hw/i386/kvm/pci-assign.c: basically everything
> >>>that deals with emulation.
> >>
> >>Do you mean those hooks to get info from the real device? Xen have its own
> >>wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
> >>
> >>Thanks
> >>Tiejun
> >
> >Yes and that's not good.  We have two pieces of code doing mostly
> >identical things slightly differently.
> >hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> >but these really need to be unified.
> >
> 
> Sorry, take a look at this again,
> 
> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
> 	|
> 	+ xen_host_pci_config_read(d, pos, buf, len)
> 		|
> 		+ pread(d->config_fd, buf, len, pos)
> 
> I thinks this should be same as kvm.
> 
> Thanks
> Tiejun

get_block is trivial.

I really mean the whole PT infrastructure for
- discovering host devices through sysfs
- virtualizing devices

rom, bars, msi ...
the list goes on.

logic is mostly the same.



-- 
MST

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>>>> In fact it's exactly what passthrough does.
>>>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>>>
>>>>>> Yes, sysfs.
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>> Then you should be able to re-use large chunks of
>>>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>>>> that deals with emulation.
>>>>
>>>> Do you mean those hooks to get info from the real device? Xen have its own
>>>> wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> Yes and that's not good.  We have two pieces of code doing mostly
>>> identical things slightly differently.
>>> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
>>> but these really need to be unified.
>>>
>>
>> Sorry, take a look at this again,
>>
>> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
>> 	|
>> 	+ xen_host_pci_config_read(d, pos, buf, len)
>> 		|
>> 		+ pread(d->config_fd, buf, len, pos)
>>
>> I thinks this should be same as kvm.
>>
>> Thanks
>> Tiejun
>
> get_block is trivial.
>
> I really mean the whole PT infrastructure for
> - discovering host devices through sysfs
> - virtualizing devices
>
> rom, bars, msi ...
> the list goes on.
>
> logic is mostly the same.
>

Looks you mean we can unify the entire PT infrastructure between kvm and 
xen inside qemu. But I'm afraid its not easy to do in a short time, so 
maybe we can queue this as next phase.

Thanks
Tiejun

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>>>> In fact it's exactly what passthrough does.
>>>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>>>
>>>>>> Yes, sysfs.
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>> Then you should be able to re-use large chunks of
>>>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>>>> that deals with emulation.
>>>>
>>>> Do you mean those hooks to get info from the real device? Xen have its own
>>>> wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> Yes and that's not good.  We have two pieces of code doing mostly
>>> identical things slightly differently.
>>> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
>>> but these really need to be unified.
>>>
>>
>> Sorry, take a look at this again,
>>
>> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
>> 	|
>> 	+ xen_host_pci_config_read(d, pos, buf, len)
>> 		|
>> 		+ pread(d->config_fd, buf, len, pos)
>>
>> I thinks this should be same as kvm.
>>
>> Thanks
>> Tiejun
>
> get_block is trivial.
>
> I really mean the whole PT infrastructure for
> - discovering host devices through sysfs
> - virtualizing devices
>
> rom, bars, msi ...
> the list goes on.
>
> logic is mostly the same.
>

Looks you mean we can unify the entire PT infrastructure between kvm and 
xen inside qemu. But I'm afraid its not easy to do in a short time, so 
maybe we can queue this as next phase.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> >>>>>On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> >>>>>>>In fact it's exactly what passthrough does.
> >>>>>>>I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> >>>>>>>can be reused. How do you poke at the host device? sysfs?
> >>>>>>
> >>>>>>Yes, sysfs.
> >>>>>>
> >>>>>>Thanks
> >>>>>>Tiejun
> >>>>>
> >>>>>Then you should be able to re-use large chunks of
> >>>>>./hw/i386/kvm/pci-assign.c: basically everything
> >>>>>that deals with emulation.
> >>>>
> >>>>Do you mean those hooks to get info from the real device? Xen have its own
> >>>>wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>Yes and that's not good.  We have two pieces of code doing mostly
> >>>identical things slightly differently.
> >>>hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> >>>but these really need to be unified.
> >>>
> >>
> >>Sorry, take a look at this again,
> >>
> >>xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
> >>	|
> >>	+ xen_host_pci_config_read(d, pos, buf, len)
> >>		|
> >>		+ pread(d->config_fd, buf, len, pos)
> >>
> >>I thinks this should be same as kvm.
> >>
> >>Thanks
> >>Tiejun
> >
> >get_block is trivial.
> >
> >I really mean the whole PT infrastructure for
> >- discovering host devices through sysfs
> >- virtualizing devices
> >
> >rom, bars, msi ...
> >the list goes on.
> >
> >logic is mostly the same.
> >
> 
> Looks you mean we can unify the entire PT infrastructure between kvm and xen
> inside qemu. But I'm afraid its not easy to do in a short time, so maybe we
> can queue this as next phase.
> 
> Thanks
> Tiejun

I'm afraid once we merge your code, you'll lose interest :)

At least, don't add duplicate code for ROM.


-- 
MST

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> >>>>>On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> >>>>>>>In fact it's exactly what passthrough does.
> >>>>>>>I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> >>>>>>>can be reused. How do you poke at the host device? sysfs?
> >>>>>>
> >>>>>>Yes, sysfs.
> >>>>>>
> >>>>>>Thanks
> >>>>>>Tiejun
> >>>>>
> >>>>>Then you should be able to re-use large chunks of
> >>>>>./hw/i386/kvm/pci-assign.c: basically everything
> >>>>>that deals with emulation.
> >>>>
> >>>>Do you mean those hooks to get info from the real device? Xen have its own
> >>>>wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>Yes and that's not good.  We have two pieces of code doing mostly
> >>>identical things slightly differently.
> >>>hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> >>>but these really need to be unified.
> >>>
> >>
> >>Sorry, take a look at this again,
> >>
> >>xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
> >>	|
> >>	+ xen_host_pci_config_read(d, pos, buf, len)
> >>		|
> >>		+ pread(d->config_fd, buf, len, pos)
> >>
> >>I thinks this should be same as kvm.
> >>
> >>Thanks
> >>Tiejun
> >
> >get_block is trivial.
> >
> >I really mean the whole PT infrastructure for
> >- discovering host devices through sysfs
> >- virtualizing devices
> >
> >rom, bars, msi ...
> >the list goes on.
> >
> >logic is mostly the same.
> >
> 
> Looks you mean we can unify the entire PT infrastructure between kvm and xen
> inside qemu. But I'm afraid its not easy to do in a short time, so maybe we
> can queue this as next phase.
> 
> Thanks
> Tiejun

I'm afraid once we merge your code, you'll lose interest :)

At least, don't add duplicate code for ROM.


-- 
MST

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 17:21, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
>>>>> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>>>>>> In fact it's exactly what passthrough does.
>>>>>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>>>>>
>>>>>>>> Yes, sysfs.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Tiejun
>>>>>>>
>>>>>>> Then you should be able to re-use large chunks of
>>>>>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>>>>>> that deals with emulation.
>>>>>>
>>>>>> Do you mean those hooks to get info from the real device? Xen have its own
>>>>>> wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>> Yes and that's not good.  We have two pieces of code doing mostly
>>>>> identical things slightly differently.
>>>>> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
>>>>> but these really need to be unified.
>>>>>
>>>>
>>>> Sorry, take a look at this again,
>>>>
>>>> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
>>>> 	|
>>>> 	+ xen_host_pci_config_read(d, pos, buf, len)
>>>> 		|
>>>> 		+ pread(d->config_fd, buf, len, pos)
>>>>
>>>> I thinks this should be same as kvm.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> get_block is trivial.
>>>
>>> I really mean the whole PT infrastructure for
>>> - discovering host devices through sysfs
>>> - virtualizing devices
>>>
>>> rom, bars, msi ...
>>> the list goes on.
>>>
>>> logic is mostly the same.
>>>
>>
>> Looks you mean we can unify the entire PT infrastructure between kvm and xen
>> inside qemu. But I'm afraid its not easy to do in a short time, so maybe we
>> can queue this as next phase.
>>
>> Thanks
>> Tiejun
>
> I'm afraid once we merge your code, you'll lose interest :)
>

Currently we have to push this feature into upstream as our first 
priority, so unless something is really needed to address. Of course I 
hope this point what we're talking is not such a thing :)

But I can promise here I'd like to do this optimization with your guide 
next :)

> At least, don't add duplicate code for ROM.
>

Let me try this.

Thanks
Tiejun

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 17:21, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
>>>>> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>>>>>> In fact it's exactly what passthrough does.
>>>>>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>>>>>
>>>>>>>> Yes, sysfs.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Tiejun
>>>>>>>
>>>>>>> Then you should be able to re-use large chunks of
>>>>>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>>>>>> that deals with emulation.
>>>>>>
>>>>>> Do you mean those hooks to get info from the real device? Xen have its own
>>>>>> wrapper, xen_host_pci_get_block(), so we always go there in xen scenario.
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>> Yes and that's not good.  We have two pieces of code doing mostly
>>>>> identical things slightly differently.
>>>>> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
>>>>> but these really need to be unified.
>>>>>
>>>>
>>>> Sorry, take a look at this again,
>>>>
>>>> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf, int len)
>>>> 	|
>>>> 	+ xen_host_pci_config_read(d, pos, buf, len)
>>>> 		|
>>>> 		+ pread(d->config_fd, buf, len, pos)
>>>>
>>>> I thinks this should be same as kvm.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> get_block is trivial.
>>>
>>> I really mean the whole PT infrastructure for
>>> - discovering host devices through sysfs
>>> - virtualizing devices
>>>
>>> rom, bars, msi ...
>>> the list goes on.
>>>
>>> logic is mostly the same.
>>>
>>
>> Looks you mean we can unify the entire PT infrastructure between kvm and xen
>> inside qemu. But I'm afraid its not easy to do in a short time, so maybe we
>> can queue this as next phase.
>>
>> Thanks
>> Tiejun
>
> I'm afraid once we merge your code, you'll lose interest :)
>

Currently we have to push this feature into upstream as our first 
priority, so unless something is really needed to address. Of course I 
hope this point what we're talking is not such a thing :)

But I can promise here I'd like to do this optimization with your guide 
next :)

> At least, don't add duplicate code for ROM.
>

Let me try this.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 17:58, Chen, Tiejun wrote:
> On 2014/6/25 17:44, Michael S. Tsirkin wrote:
>> On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
>>> On 2014/6/25 17:21, Michael S. Tsirkin wrote:
>>>> On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
>>>>> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
>>>>>> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>>>>>>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>>>>>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>>>>>>> In fact it's exactly what passthrough does.
>>>>>>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>>>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>>>>>>
>>>>>>>>> Yes, sysfs.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Tiejun
>>>>>>>>
>>>>>>>> Then you should be able to re-use large chunks of
>>>>>>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>>>>>>> that deals with emulation.
>>>>>>>
>>>>>>> Do you mean those hooks to get info from the real device? Xen
>>>>>>> have its own
>>>>>>> wrapper, xen_host_pci_get_block(), so we always go there in xen
>>>>>>> scenario.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Tiejun
>>>>>>
>>>>>> Yes and that's not good.  We have two pieces of code doing mostly
>>>>>> identical things slightly differently.
>>>>>> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
>>>>>> but these really need to be unified.
>>>>>>
>>>>>
>>>>> Sorry, take a look at this again,
>>>>>
>>>>> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
>>>>> int len)
>>>>>     |
>>>>>     + xen_host_pci_config_read(d, pos, buf, len)
>>>>>         |
>>>>>         + pread(d->config_fd, buf, len, pos)
>>>>>
>>>>> I thinks this should be same as kvm.
>>>>>
>>>>> Thanks
>>>>> Tiejun
>>>>
>>>> get_block is trivial.
>>>>
>>>> I really mean the whole PT infrastructure for
>>>> - discovering host devices through sysfs
>>>> - virtualizing devices
>>>>
>>>> rom, bars, msi ...
>>>> the list goes on.
>>>>
>>>> logic is mostly the same.
>>>>
>>>
>>> Looks you mean we can unify the entire PT infrastructure between kvm
>>> and xen
>>> inside qemu. But I'm afraid its not easy to do in a short time, so
>>> maybe we
>>> can queue this as next phase.
>>>
>>> Thanks
>>> Tiejun
>>
>> I'm afraid once we merge your code, you'll lose interest :)
>>
>
> Currently we have to push this feature into upstream as our first
> priority, so unless something is really needed to address. Of course I
> hope this point what we're talking is not such a thing :)
>
> But I can promise here I'd like to do this optimization with your guide
> next :)
>
>> At least, don't add duplicate code for ROM.
>>
>
> Let me try this.
>

Its not easy as expected.

kvm always work with this structure, AssignedDevice, and especially this 
is just activated in kvm_enabled(). And then set all properties to this 
structure.

In xen case, the similar structure, XenHostPCIDevice, is not easy 
transferred into the structure, AssignedDevice. So this mean we have to 
split assigned_dev_load_option_rom() as line by line for xen and kvm, 
respectively.

I really agree we definitely need to unify PT infrastructure between kvm 
and xen after this try since I can't understand why we originally 
introduce same way to do same thing :(

Do you have better idea? If not, I prefer we open this completely as 
next action to follow-up. But this time I'm afraid I can't get in this.

Thanks
Tiejun

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/6/25 17:58, Chen, Tiejun wrote:
> On 2014/6/25 17:44, Michael S. Tsirkin wrote:
>> On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
>>> On 2014/6/25 17:21, Michael S. Tsirkin wrote:
>>>> On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
>>>>> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
>>>>>> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>>>>>>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>>>>>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>>>>>>> In fact it's exactly what passthrough does.
>>>>>>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>>>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>>>>>>
>>>>>>>>> Yes, sysfs.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Tiejun
>>>>>>>>
>>>>>>>> Then you should be able to re-use large chunks of
>>>>>>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>>>>>>> that deals with emulation.
>>>>>>>
>>>>>>> Do you mean those hooks to get info from the real device? Xen
>>>>>>> have its own
>>>>>>> wrapper, xen_host_pci_get_block(), so we always go there in xen
>>>>>>> scenario.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Tiejun
>>>>>>
>>>>>> Yes and that's not good.  We have two pieces of code doing mostly
>>>>>> identical things slightly differently.
>>>>>> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
>>>>>> but these really need to be unified.
>>>>>>
>>>>>
>>>>> Sorry, take a look at this again,
>>>>>
>>>>> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
>>>>> int len)
>>>>>     |
>>>>>     + xen_host_pci_config_read(d, pos, buf, len)
>>>>>         |
>>>>>         + pread(d->config_fd, buf, len, pos)
>>>>>
>>>>> I thinks this should be same as kvm.
>>>>>
>>>>> Thanks
>>>>> Tiejun
>>>>
>>>> get_block is trivial.
>>>>
>>>> I really mean the whole PT infrastructure for
>>>> - discovering host devices through sysfs
>>>> - virtualizing devices
>>>>
>>>> rom, bars, msi ...
>>>> the list goes on.
>>>>
>>>> logic is mostly the same.
>>>>
>>>
>>> Looks you mean we can unify the entire PT infrastructure between kvm
>>> and xen
>>> inside qemu. But I'm afraid its not easy to do in a short time, so
>>> maybe we
>>> can queue this as next phase.
>>>
>>> Thanks
>>> Tiejun
>>
>> I'm afraid once we merge your code, you'll lose interest :)
>>
>
> Currently we have to push this feature into upstream as our first
> priority, so unless something is really needed to address. Of course I
> hope this point what we're talking is not such a thing :)
>
> But I can promise here I'd like to do this optimization with your guide
> next :)
>
>> At least, don't add duplicate code for ROM.
>>
>
> Let me try this.
>

Its not easy as expected.

kvm always work with this structure, AssignedDevice, and especially this 
is just activated in kvm_enabled(). And then set all properties to this 
structure.

In xen case, the similar structure, XenHostPCIDevice, is not easy 
transferred into the structure, AssignedDevice. So this mean we have to 
split assigned_dev_load_option_rom() as line by line for xen and kvm, 
respectively.

I really agree we definitely need to unify PT infrastructure between kvm 
and xen after this try since I can't understand why we originally 
introduce same way to do same thing :(

Do you have better idea? If not, I prefer we open this completely as 
next action to follow-up. But this time I'm afraid I can't get in this.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Stefano Stabellini]

On Fri, 27 Jun 2014, Chen, Tiejun wrote:
> On 2014/6/25 17:58, Chen, Tiejun wrote:
> > On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> > > On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
> > > > On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> > > > > On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> > > > > > On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> > > > > > > On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> > > > > > > > On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> > > > > > > > > On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> > > > > > > > > > > In fact it's exactly what passthrough does.
> > > > > > > > > > > I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> > > > > > > > > > > can be reused. How do you poke at the host device? sysfs?
> > > > > > > > > > 
> > > > > > > > > > Yes, sysfs.
> > > > > > > > > > 
> > > > > > > > > > Thanks
> > > > > > > > > > Tiejun
> > > > > > > > > 
> > > > > > > > > Then you should be able to re-use large chunks of
> > > > > > > > > ./hw/i386/kvm/pci-assign.c: basically everything
> > > > > > > > > that deals with emulation.
> > > > > > > > 
> > > > > > > > Do you mean those hooks to get info from the real device? Xen
> > > > > > > > have its own
> > > > > > > > wrapper, xen_host_pci_get_block(), so we always go there in xen
> > > > > > > > scenario.
> > > > > > > > 
> > > > > > > > Thanks
> > > > > > > > Tiejun
> > > > > > > 
> > > > > > > Yes and that's not good.  We have two pieces of code doing mostly
> > > > > > > identical things slightly differently.
> > > > > > > hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> > > > > > > but these really need to be unified.
> > > > > > > 
> > > > > > 
> > > > > > Sorry, take a look at this again,
> > > > > > 
> > > > > > xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> > > > > > int len)
> > > > > >     |
> > > > > >     + xen_host_pci_config_read(d, pos, buf, len)
> > > > > >         |
> > > > > >         + pread(d->config_fd, buf, len, pos)
> > > > > > 
> > > > > > I thinks this should be same as kvm.
> > > > > > 
> > > > > > Thanks
> > > > > > Tiejun
> > > > > 
> > > > > get_block is trivial.
> > > > > 
> > > > > I really mean the whole PT infrastructure for
> > > > > - discovering host devices through sysfs
> > > > > - virtualizing devices
> > > > > 
> > > > > rom, bars, msi ...
> > > > > the list goes on.
> > > > > 
> > > > > logic is mostly the same.
> > > > > 
> > > > 
> > > > Looks you mean we can unify the entire PT infrastructure between kvm
> > > > and xen
> > > > inside qemu. But I'm afraid its not easy to do in a short time, so
> > > > maybe we
> > > > can queue this as next phase.
> > > > 
> > > > Thanks
> > > > Tiejun
> > > 
> > > I'm afraid once we merge your code, you'll lose interest :)
> > > 
> > 
> > Currently we have to push this feature into upstream as our first
> > priority, so unless something is really needed to address. Of course I
> > hope this point what we're talking is not such a thing :)
> > 
> > But I can promise here I'd like to do this optimization with your guide
> > next :)
> > 
> > > At least, don't add duplicate code for ROM.
> > > 
> > 
> > Let me try this.
> > 
> 
> Its not easy as expected.
> 
> kvm always work with this structure, AssignedDevice, and especially this is
> just activated in kvm_enabled(). And then set all properties to this
> structure.
> 
> In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
> into the structure, AssignedDevice. So this mean we have to split
> assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
> 
> I really agree we definitely need to unify PT infrastructure between kvm and
> xen after this try since I can't understand why we originally introduce same
> way to do same thing :(
> 
> Do you have better idea? If not, I prefer we open this completely as next
> action to follow-up. But this time I'm afraid I can't get in this.

The Xen PT code came first. At the time Anthony Liguori and I argued for
sharing the PT code with KVM going forward but Avi wanted to retain the
KVM PT code as is in order not to introduce any regressions on KVM.

Ah.. the good old times :-)

http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Stefano Stabellini]

On Fri, 27 Jun 2014, Chen, Tiejun wrote:
> On 2014/6/25 17:58, Chen, Tiejun wrote:
> > On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> > > On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
> > > > On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> > > > > On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> > > > > > On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> > > > > > > On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> > > > > > > > On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> > > > > > > > > On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> > > > > > > > > > > In fact it's exactly what passthrough does.
> > > > > > > > > > > I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> > > > > > > > > > > can be reused. How do you poke at the host device? sysfs?
> > > > > > > > > > 
> > > > > > > > > > Yes, sysfs.
> > > > > > > > > > 
> > > > > > > > > > Thanks
> > > > > > > > > > Tiejun
> > > > > > > > > 
> > > > > > > > > Then you should be able to re-use large chunks of
> > > > > > > > > ./hw/i386/kvm/pci-assign.c: basically everything
> > > > > > > > > that deals with emulation.
> > > > > > > > 
> > > > > > > > Do you mean those hooks to get info from the real device? Xen
> > > > > > > > have its own
> > > > > > > > wrapper, xen_host_pci_get_block(), so we always go there in xen
> > > > > > > > scenario.
> > > > > > > > 
> > > > > > > > Thanks
> > > > > > > > Tiejun
> > > > > > > 
> > > > > > > Yes and that's not good.  We have two pieces of code doing mostly
> > > > > > > identical things slightly differently.
> > > > > > > hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> > > > > > > but these really need to be unified.
> > > > > > > 
> > > > > > 
> > > > > > Sorry, take a look at this again,
> > > > > > 
> > > > > > xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> > > > > > int len)
> > > > > >     |
> > > > > >     + xen_host_pci_config_read(d, pos, buf, len)
> > > > > >         |
> > > > > >         + pread(d->config_fd, buf, len, pos)
> > > > > > 
> > > > > > I thinks this should be same as kvm.
> > > > > > 
> > > > > > Thanks
> > > > > > Tiejun
> > > > > 
> > > > > get_block is trivial.
> > > > > 
> > > > > I really mean the whole PT infrastructure for
> > > > > - discovering host devices through sysfs
> > > > > - virtualizing devices
> > > > > 
> > > > > rom, bars, msi ...
> > > > > the list goes on.
> > > > > 
> > > > > logic is mostly the same.
> > > > > 
> > > > 
> > > > Looks you mean we can unify the entire PT infrastructure between kvm
> > > > and xen
> > > > inside qemu. But I'm afraid its not easy to do in a short time, so
> > > > maybe we
> > > > can queue this as next phase.
> > > > 
> > > > Thanks
> > > > Tiejun
> > > 
> > > I'm afraid once we merge your code, you'll lose interest :)
> > > 
> > 
> > Currently we have to push this feature into upstream as our first
> > priority, so unless something is really needed to address. Of course I
> > hope this point what we're talking is not such a thing :)
> > 
> > But I can promise here I'd like to do this optimization with your guide
> > next :)
> > 
> > > At least, don't add duplicate code for ROM.
> > > 
> > 
> > Let me try this.
> > 
> 
> Its not easy as expected.
> 
> kvm always work with this structure, AssignedDevice, and especially this is
> just activated in kvm_enabled(). And then set all properties to this
> structure.
> 
> In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
> into the structure, AssignedDevice. So this mean we have to split
> assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
> 
> I really agree we definitely need to unify PT infrastructure between kvm and
> xen after this try since I can't understand why we originally introduce same
> way to do same thing :(
> 
> Do you have better idea? If not, I prefer we open this completely as next
> action to follow-up. But this time I'm afraid I can't get in this.

The Xen PT code came first. At the time Anthony Liguori and I argued for
sharing the PT code with KVM going forward but Avi wanted to retain the
KVM PT code as is in order not to introduce any regressions on KVM.

Ah.. the good old times :-)

http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/7/1 3:34, Stefano Stabellini wrote:
> On Fri, 27 Jun 2014, Chen, Tiejun wrote:
>> On 2014/6/25 17:58, Chen, Tiejun wrote:
>>> On 2014/6/25 17:44, Michael S. Tsirkin wrote:
>>>> On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
>>>>> On 2014/6/25 17:21, Michael S. Tsirkin wrote:
>>>>>> On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
>>>>>>> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
>>>>>>>> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>>>>>>>>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>>>>>>>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>> In fact it's exactly what passthrough does.
>>>>>>>>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>>>>>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>>>>>>>>
>>>>>>>>>>> Yes, sysfs.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Tiejun
>>>>>>>>>>
>>>>>>>>>> Then you should be able to re-use large chunks of
>>>>>>>>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>>>>>>>>> that deals with emulation.
>>>>>>>>>
>>>>>>>>> Do you mean those hooks to get info from the real device? Xen
>>>>>>>>> have its own
>>>>>>>>> wrapper, xen_host_pci_get_block(), so we always go there in xen
>>>>>>>>> scenario.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Tiejun
>>>>>>>>
>>>>>>>> Yes and that's not good.  We have two pieces of code doing mostly
>>>>>>>> identical things slightly differently.
>>>>>>>> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
>>>>>>>> but these really need to be unified.
>>>>>>>>
>>>>>>>
>>>>>>> Sorry, take a look at this again,
>>>>>>>
>>>>>>> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
>>>>>>> int len)
>>>>>>>      |
>>>>>>>      + xen_host_pci_config_read(d, pos, buf, len)
>>>>>>>          |
>>>>>>>          + pread(d->config_fd, buf, len, pos)
>>>>>>>
>>>>>>> I thinks this should be same as kvm.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Tiejun
>>>>>>
>>>>>> get_block is trivial.
>>>>>>
>>>>>> I really mean the whole PT infrastructure for
>>>>>> - discovering host devices through sysfs
>>>>>> - virtualizing devices
>>>>>>
>>>>>> rom, bars, msi ...
>>>>>> the list goes on.
>>>>>>
>>>>>> logic is mostly the same.
>>>>>>
>>>>>
>>>>> Looks you mean we can unify the entire PT infrastructure between kvm
>>>>> and xen
>>>>> inside qemu. But I'm afraid its not easy to do in a short time, so
>>>>> maybe we
>>>>> can queue this as next phase.
>>>>>
>>>>> Thanks
>>>>> Tiejun
>>>>
>>>> I'm afraid once we merge your code, you'll lose interest :)
>>>>
>>>
>>> Currently we have to push this feature into upstream as our first
>>> priority, so unless something is really needed to address. Of course I
>>> hope this point what we're talking is not such a thing :)
>>>
>>> But I can promise here I'd like to do this optimization with your guide
>>> next :)
>>>
>>>> At least, don't add duplicate code for ROM.
>>>>
>>>
>>> Let me try this.
>>>
>>
>> Its not easy as expected.
>>
>> kvm always work with this structure, AssignedDevice, and especially this is
>> just activated in kvm_enabled(). And then set all properties to this
>> structure.
>>
>> In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
>> into the structure, AssignedDevice. So this mean we have to split
>> assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
>>
>> I really agree we definitely need to unify PT infrastructure between kvm and
>> xen after this try since I can't understand why we originally introduce same
>> way to do same thing :(
>>
>> Do you have better idea? If not, I prefer we open this completely as next
>> action to follow-up. But this time I'm afraid I can't get in this.
>
> The Xen PT code came first. At the time Anthony Liguori and I argued for
> sharing the PT code with KVM going forward but Avi wanted to retain the
> KVM PT code as is in order not to introduce any regressions on KVM.
>
> Ah.. the good old times :-)

Thanks for your information. So now what's next I should do now?

Thanks
Tiejun

>
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html
>
>

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/7/1 3:34, Stefano Stabellini wrote:
> On Fri, 27 Jun 2014, Chen, Tiejun wrote:
>> On 2014/6/25 17:58, Chen, Tiejun wrote:
>>> On 2014/6/25 17:44, Michael S. Tsirkin wrote:
>>>> On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
>>>>> On 2014/6/25 17:21, Michael S. Tsirkin wrote:
>>>>>> On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
>>>>>>> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
>>>>>>>> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>>>>>>>>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>>>>>>>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>> In fact it's exactly what passthrough does.
>>>>>>>>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>>>>>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>>>>>>>>
>>>>>>>>>>> Yes, sysfs.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Tiejun
>>>>>>>>>>
>>>>>>>>>> Then you should be able to re-use large chunks of
>>>>>>>>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>>>>>>>>> that deals with emulation.
>>>>>>>>>
>>>>>>>>> Do you mean those hooks to get info from the real device? Xen
>>>>>>>>> have its own
>>>>>>>>> wrapper, xen_host_pci_get_block(), so we always go there in xen
>>>>>>>>> scenario.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Tiejun
>>>>>>>>
>>>>>>>> Yes and that's not good.  We have two pieces of code doing mostly
>>>>>>>> identical things slightly differently.
>>>>>>>> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
>>>>>>>> but these really need to be unified.
>>>>>>>>
>>>>>>>
>>>>>>> Sorry, take a look at this again,
>>>>>>>
>>>>>>> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
>>>>>>> int len)
>>>>>>>      |
>>>>>>>      + xen_host_pci_config_read(d, pos, buf, len)
>>>>>>>          |
>>>>>>>          + pread(d->config_fd, buf, len, pos)
>>>>>>>
>>>>>>> I thinks this should be same as kvm.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Tiejun
>>>>>>
>>>>>> get_block is trivial.
>>>>>>
>>>>>> I really mean the whole PT infrastructure for
>>>>>> - discovering host devices through sysfs
>>>>>> - virtualizing devices
>>>>>>
>>>>>> rom, bars, msi ...
>>>>>> the list goes on.
>>>>>>
>>>>>> logic is mostly the same.
>>>>>>
>>>>>
>>>>> Looks you mean we can unify the entire PT infrastructure between kvm
>>>>> and xen
>>>>> inside qemu. But I'm afraid its not easy to do in a short time, so
>>>>> maybe we
>>>>> can queue this as next phase.
>>>>>
>>>>> Thanks
>>>>> Tiejun
>>>>
>>>> I'm afraid once we merge your code, you'll lose interest :)
>>>>
>>>
>>> Currently we have to push this feature into upstream as our first
>>> priority, so unless something is really needed to address. Of course I
>>> hope this point what we're talking is not such a thing :)
>>>
>>> But I can promise here I'd like to do this optimization with your guide
>>> next :)
>>>
>>>> At least, don't add duplicate code for ROM.
>>>>
>>>
>>> Let me try this.
>>>
>>
>> Its not easy as expected.
>>
>> kvm always work with this structure, AssignedDevice, and especially this is
>> just activated in kvm_enabled(). And then set all properties to this
>> structure.
>>
>> In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
>> into the structure, AssignedDevice. So this mean we have to split
>> assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
>>
>> I really agree we definitely need to unify PT infrastructure between kvm and
>> xen after this try since I can't understand why we originally introduce same
>> way to do same thing :(
>>
>> Do you have better idea? If not, I prefer we open this completely as next
>> action to follow-up. But this time I'm afraid I can't get in this.
>
> The Xen PT code came first. At the time Anthony Liguori and I argued for
> sharing the PT code with KVM going forward but Avi wanted to retain the
> KVM PT code as is in order not to introduce any regressions on KVM.
>
> Ah.. the good old times :-)

Thanks for your information. So now what's next I should do now?

Thanks
Tiejun

>
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html
>
>

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 08:34:46PM +0100, Stefano Stabellini wrote:
> On Fri, 27 Jun 2014, Chen, Tiejun wrote:
> > On 2014/6/25 17:58, Chen, Tiejun wrote:
> > > On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
> > > > > On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> > > > > > On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> > > > > > > On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> > > > > > > > On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> > > > > > > > > On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> > > > > > > > > > On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> > > > > > > > > > > > In fact it's exactly what passthrough does.
> > > > > > > > > > > > I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> > > > > > > > > > > > can be reused. How do you poke at the host device? sysfs?
> > > > > > > > > > > 
> > > > > > > > > > > Yes, sysfs.
> > > > > > > > > > > 
> > > > > > > > > > > Thanks
> > > > > > > > > > > Tiejun
> > > > > > > > > > 
> > > > > > > > > > Then you should be able to re-use large chunks of
> > > > > > > > > > ./hw/i386/kvm/pci-assign.c: basically everything
> > > > > > > > > > that deals with emulation.
> > > > > > > > > 
> > > > > > > > > Do you mean those hooks to get info from the real device? Xen
> > > > > > > > > have its own
> > > > > > > > > wrapper, xen_host_pci_get_block(), so we always go there in xen
> > > > > > > > > scenario.
> > > > > > > > > 
> > > > > > > > > Thanks
> > > > > > > > > Tiejun
> > > > > > > > 
> > > > > > > > Yes and that's not good.  We have two pieces of code doing mostly
> > > > > > > > identical things slightly differently.
> > > > > > > > hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> > > > > > > > but these really need to be unified.
> > > > > > > > 
> > > > > > > 
> > > > > > > Sorry, take a look at this again,
> > > > > > > 
> > > > > > > xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> > > > > > > int len)
> > > > > > >     |
> > > > > > >     + xen_host_pci_config_read(d, pos, buf, len)
> > > > > > >         |
> > > > > > >         + pread(d->config_fd, buf, len, pos)
> > > > > > > 
> > > > > > > I thinks this should be same as kvm.
> > > > > > > 
> > > > > > > Thanks
> > > > > > > Tiejun
> > > > > > 
> > > > > > get_block is trivial.
> > > > > > 
> > > > > > I really mean the whole PT infrastructure for
> > > > > > - discovering host devices through sysfs
> > > > > > - virtualizing devices
> > > > > > 
> > > > > > rom, bars, msi ...
> > > > > > the list goes on.
> > > > > > 
> > > > > > logic is mostly the same.
> > > > > > 
> > > > > 
> > > > > Looks you mean we can unify the entire PT infrastructure between kvm
> > > > > and xen
> > > > > inside qemu. But I'm afraid its not easy to do in a short time, so
> > > > > maybe we
> > > > > can queue this as next phase.
> > > > > 
> > > > > Thanks
> > > > > Tiejun
> > > > 
> > > > I'm afraid once we merge your code, you'll lose interest :)
> > > > 
> > > 
> > > Currently we have to push this feature into upstream as our first
> > > priority, so unless something is really needed to address. Of course I
> > > hope this point what we're talking is not such a thing :)
> > > 
> > > But I can promise here I'd like to do this optimization with your guide
> > > next :)
> > > 
> > > > At least, don't add duplicate code for ROM.
> > > > 
> > > 
> > > Let me try this.
> > > 
> > 
> > Its not easy as expected.
> > 
> > kvm always work with this structure, AssignedDevice, and especially this is
> > just activated in kvm_enabled(). And then set all properties to this
> > structure.
> > 
> > In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
> > into the structure, AssignedDevice. So this mean we have to split
> > assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
> > 
> > I really agree we definitely need to unify PT infrastructure between kvm and
> > xen after this try since I can't understand why we originally introduce same
> > way to do same thing :(
> > 
> > Do you have better idea? If not, I prefer we open this completely as next
> > action to follow-up. But this time I'm afraid I can't get in this.
> 
> The Xen PT code came first. At the time Anthony Liguori and I argued for
> sharing the PT code with KVM going forward but Avi wanted to retain the
> KVM PT code as is in order not to introduce any regressions on KVM.
> 
> Ah.. the good old times :-)
> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html

Right, I remember that there was an idea to first make the code
reusable before merging either Xen or KVM PT, but in the end 
the plan to merge both and then abstract it out, won.
We never got to abstracting it out but we should!

Yet, I do not think we should require abstracting all of Xen PT as
a pre-requisite for this work, but I think we can
avoid adding to the duplication without a lot of effort.
To start sharing with ROM code, I think we should rename
AssignedDevice->KvmAssignedDevice, and move fields that can be shared
with Xen from there to AssignedDevice.

-- 
MST

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 08:34:46PM +0100, Stefano Stabellini wrote:
> On Fri, 27 Jun 2014, Chen, Tiejun wrote:
> > On 2014/6/25 17:58, Chen, Tiejun wrote:
> > > On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
> > > > > On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> > > > > > On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> > > > > > > On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> > > > > > > > On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> > > > > > > > > On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> > > > > > > > > > On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> > > > > > > > > > > > In fact it's exactly what passthrough does.
> > > > > > > > > > > > I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> > > > > > > > > > > > can be reused. How do you poke at the host device? sysfs?
> > > > > > > > > > > 
> > > > > > > > > > > Yes, sysfs.
> > > > > > > > > > > 
> > > > > > > > > > > Thanks
> > > > > > > > > > > Tiejun
> > > > > > > > > > 
> > > > > > > > > > Then you should be able to re-use large chunks of
> > > > > > > > > > ./hw/i386/kvm/pci-assign.c: basically everything
> > > > > > > > > > that deals with emulation.
> > > > > > > > > 
> > > > > > > > > Do you mean those hooks to get info from the real device? Xen
> > > > > > > > > have its own
> > > > > > > > > wrapper, xen_host_pci_get_block(), so we always go there in xen
> > > > > > > > > scenario.
> > > > > > > > > 
> > > > > > > > > Thanks
> > > > > > > > > Tiejun
> > > > > > > > 
> > > > > > > > Yes and that's not good.  We have two pieces of code doing mostly
> > > > > > > > identical things slightly differently.
> > > > > > > > hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> > > > > > > > but these really need to be unified.
> > > > > > > > 
> > > > > > > 
> > > > > > > Sorry, take a look at this again,
> > > > > > > 
> > > > > > > xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> > > > > > > int len)
> > > > > > >     |
> > > > > > >     + xen_host_pci_config_read(d, pos, buf, len)
> > > > > > >         |
> > > > > > >         + pread(d->config_fd, buf, len, pos)
> > > > > > > 
> > > > > > > I thinks this should be same as kvm.
> > > > > > > 
> > > > > > > Thanks
> > > > > > > Tiejun
> > > > > > 
> > > > > > get_block is trivial.
> > > > > > 
> > > > > > I really mean the whole PT infrastructure for
> > > > > > - discovering host devices through sysfs
> > > > > > - virtualizing devices
> > > > > > 
> > > > > > rom, bars, msi ...
> > > > > > the list goes on.
> > > > > > 
> > > > > > logic is mostly the same.
> > > > > > 
> > > > > 
> > > > > Looks you mean we can unify the entire PT infrastructure between kvm
> > > > > and xen
> > > > > inside qemu. But I'm afraid its not easy to do in a short time, so
> > > > > maybe we
> > > > > can queue this as next phase.
> > > > > 
> > > > > Thanks
> > > > > Tiejun
> > > > 
> > > > I'm afraid once we merge your code, you'll lose interest :)
> > > > 
> > > 
> > > Currently we have to push this feature into upstream as our first
> > > priority, so unless something is really needed to address. Of course I
> > > hope this point what we're talking is not such a thing :)
> > > 
> > > But I can promise here I'd like to do this optimization with your guide
> > > next :)
> > > 
> > > > At least, don't add duplicate code for ROM.
> > > > 
> > > 
> > > Let me try this.
> > > 
> > 
> > Its not easy as expected.
> > 
> > kvm always work with this structure, AssignedDevice, and especially this is
> > just activated in kvm_enabled(). And then set all properties to this
> > structure.
> > 
> > In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
> > into the structure, AssignedDevice. So this mean we have to split
> > assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
> > 
> > I really agree we definitely need to unify PT infrastructure between kvm and
> > xen after this try since I can't understand why we originally introduce same
> > way to do same thing :(
> > 
> > Do you have better idea? If not, I prefer we open this completely as next
> > action to follow-up. But this time I'm afraid I can't get in this.
> 
> The Xen PT code came first. At the time Anthony Liguori and I argued for
> sharing the PT code with KVM going forward but Avi wanted to retain the
> KVM PT code as is in order not to introduce any regressions on KVM.
> 
> Ah.. the good old times :-)
> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html

Right, I remember that there was an idea to first make the code
reusable before merging either Xen or KVM PT, but in the end 
the plan to merge both and then abstract it out, won.
We never got to abstracting it out but we should!

Yet, I do not think we should require abstracting all of Xen PT as
a pre-requisite for this work, but I think we can
avoid adding to the duplication without a lot of effort.
To start sharing with ROM code, I think we should rename
AssignedDevice->KvmAssignedDevice, and move fields that can be shared
with Xen from there to AssignedDevice.

-- 
MST

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/7/1 13:47, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 08:34:46PM +0100, Stefano Stabellini wrote:
>> On Fri, 27 Jun 2014, Chen, Tiejun wrote:
>>> On 2014/6/25 17:58, Chen, Tiejun wrote:
>>>> On 2014/6/25 17:44, Michael S. Tsirkin wrote:
>>>>> On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/25 17:21, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
>>>>>>>>> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>>> In fact it's exactly what passthrough does.
>>>>>>>>>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>>>>>>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, sysfs.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Tiejun
>>>>>>>>>>>
>>>>>>>>>>> Then you should be able to re-use large chunks of
>>>>>>>>>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>>>>>>>>>> that deals with emulation.
>>>>>>>>>>
>>>>>>>>>> Do you mean those hooks to get info from the real device? Xen
>>>>>>>>>> have its own
>>>>>>>>>> wrapper, xen_host_pci_get_block(), so we always go there in xen
>>>>>>>>>> scenario.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Tiejun
>>>>>>>>>
>>>>>>>>> Yes and that's not good.  We have two pieces of code doing mostly
>>>>>>>>> identical things slightly differently.
>>>>>>>>> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
>>>>>>>>> but these really need to be unified.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry, take a look at this again,
>>>>>>>>
>>>>>>>> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
>>>>>>>> int len)
>>>>>>>>      |
>>>>>>>>      + xen_host_pci_config_read(d, pos, buf, len)
>>>>>>>>          |
>>>>>>>>          + pread(d->config_fd, buf, len, pos)
>>>>>>>>
>>>>>>>> I thinks this should be same as kvm.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Tiejun
>>>>>>>
>>>>>>> get_block is trivial.
>>>>>>>
>>>>>>> I really mean the whole PT infrastructure for
>>>>>>> - discovering host devices through sysfs
>>>>>>> - virtualizing devices
>>>>>>>
>>>>>>> rom, bars, msi ...
>>>>>>> the list goes on.
>>>>>>>
>>>>>>> logic is mostly the same.
>>>>>>>
>>>>>>
>>>>>> Looks you mean we can unify the entire PT infrastructure between kvm
>>>>>> and xen
>>>>>> inside qemu. But I'm afraid its not easy to do in a short time, so
>>>>>> maybe we
>>>>>> can queue this as next phase.
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>> I'm afraid once we merge your code, you'll lose interest :)
>>>>>
>>>>
>>>> Currently we have to push this feature into upstream as our first
>>>> priority, so unless something is really needed to address. Of course I
>>>> hope this point what we're talking is not such a thing :)
>>>>
>>>> But I can promise here I'd like to do this optimization with your guide
>>>> next :)
>>>>
>>>>> At least, don't add duplicate code for ROM.
>>>>>
>>>>
>>>> Let me try this.
>>>>
>>>
>>> Its not easy as expected.
>>>
>>> kvm always work with this structure, AssignedDevice, and especially this is
>>> just activated in kvm_enabled(). And then set all properties to this
>>> structure.
>>>
>>> In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
>>> into the structure, AssignedDevice. So this mean we have to split
>>> assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
>>>
>>> I really agree we definitely need to unify PT infrastructure between kvm and
>>> xen after this try since I can't understand why we originally introduce same
>>> way to do same thing :(
>>>
>>> Do you have better idea? If not, I prefer we open this completely as next
>>> action to follow-up. But this time I'm afraid I can't get in this.
>>
>> The Xen PT code came first. At the time Anthony Liguori and I argued for
>> sharing the PT code with KVM going forward but Avi wanted to retain the
>> KVM PT code as is in order not to introduce any regressions on KVM.
>>
>> Ah.. the good old times :-)
>>
>> http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html
>
> Right, I remember that there was an idea to first make the code
> reusable before merging either Xen or KVM PT, but in the end
> the plan to merge both and then abstract it out, won.
> We never got to abstracting it out but we should!
>
> Yet, I do not think we should require abstracting all of Xen PT as
> a pre-requisite for this work, but I think we can
> avoid adding to the duplication without a lot of effort.
> To start sharing with ROM code, I think we should rename
> AssignedDevice->KvmAssignedDevice, and move fields that can be shared
> with Xen from there to AssignedDevice.

Its not simple to share something between AssignedDevice and the similar 
structure, XenHostPCIDevice.

As I said previously AssignedDevice is just activated in kvm_enabled(), 
then set all properties to this structure.

But kvm_enabled() is zero since we always disable this in xen scenario. 
So this means we have to invoke pci-assign framework completely if we 
try to force to use this. So actually this would be equal to merge kvm 
and xen.

Or if you already figure out to avoid this happened let me know.

Thanks
Tiejun

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Chen, Tiejun]

On 2014/7/1 13:47, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 08:34:46PM +0100, Stefano Stabellini wrote:
>> On Fri, 27 Jun 2014, Chen, Tiejun wrote:
>>> On 2014/6/25 17:58, Chen, Tiejun wrote:
>>>> On 2014/6/25 17:44, Michael S. Tsirkin wrote:
>>>>> On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/25 17:21, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/25 17:04, Michael S. Tsirkin wrote:
>>>>>>>>> On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/25 16:43, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>>> In fact it's exactly what passthrough does.
>>>>>>>>>>>>> I wonder if more bits from ./hw/i386/kvm/pci-assign.c
>>>>>>>>>>>>> can be reused. How do you poke at the host device? sysfs?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, sysfs.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Tiejun
>>>>>>>>>>>
>>>>>>>>>>> Then you should be able to re-use large chunks of
>>>>>>>>>>> ./hw/i386/kvm/pci-assign.c: basically everything
>>>>>>>>>>> that deals with emulation.
>>>>>>>>>>
>>>>>>>>>> Do you mean those hooks to get info from the real device? Xen
>>>>>>>>>> have its own
>>>>>>>>>> wrapper, xen_host_pci_get_block(), so we always go there in xen
>>>>>>>>>> scenario.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Tiejun
>>>>>>>>>
>>>>>>>>> Yes and that's not good.  We have two pieces of code doing mostly
>>>>>>>>> identical things slightly differently.
>>>>>>>>> hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
>>>>>>>>> but these really need to be unified.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry, take a look at this again,
>>>>>>>>
>>>>>>>> xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
>>>>>>>> int len)
>>>>>>>>      |
>>>>>>>>      + xen_host_pci_config_read(d, pos, buf, len)
>>>>>>>>          |
>>>>>>>>          + pread(d->config_fd, buf, len, pos)
>>>>>>>>
>>>>>>>> I thinks this should be same as kvm.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Tiejun
>>>>>>>
>>>>>>> get_block is trivial.
>>>>>>>
>>>>>>> I really mean the whole PT infrastructure for
>>>>>>> - discovering host devices through sysfs
>>>>>>> - virtualizing devices
>>>>>>>
>>>>>>> rom, bars, msi ...
>>>>>>> the list goes on.
>>>>>>>
>>>>>>> logic is mostly the same.
>>>>>>>
>>>>>>
>>>>>> Looks you mean we can unify the entire PT infrastructure between kvm
>>>>>> and xen
>>>>>> inside qemu. But I'm afraid its not easy to do in a short time, so
>>>>>> maybe we
>>>>>> can queue this as next phase.
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>> I'm afraid once we merge your code, you'll lose interest :)
>>>>>
>>>>
>>>> Currently we have to push this feature into upstream as our first
>>>> priority, so unless something is really needed to address. Of course I
>>>> hope this point what we're talking is not such a thing :)
>>>>
>>>> But I can promise here I'd like to do this optimization with your guide
>>>> next :)
>>>>
>>>>> At least, don't add duplicate code for ROM.
>>>>>
>>>>
>>>> Let me try this.
>>>>
>>>
>>> Its not easy as expected.
>>>
>>> kvm always work with this structure, AssignedDevice, and especially this is
>>> just activated in kvm_enabled(). And then set all properties to this
>>> structure.
>>>
>>> In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
>>> into the structure, AssignedDevice. So this mean we have to split
>>> assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
>>>
>>> I really agree we definitely need to unify PT infrastructure between kvm and
>>> xen after this try since I can't understand why we originally introduce same
>>> way to do same thing :(
>>>
>>> Do you have better idea? If not, I prefer we open this completely as next
>>> action to follow-up. But this time I'm afraid I can't get in this.
>>
>> The Xen PT code came first. At the time Anthony Liguori and I argued for
>> sharing the PT code with KVM going forward but Avi wanted to retain the
>> KVM PT code as is in order not to introduce any regressions on KVM.
>>
>> Ah.. the good old times :-)
>>
>> http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html
>
> Right, I remember that there was an idea to first make the code
> reusable before merging either Xen or KVM PT, but in the end
> the plan to merge both and then abstract it out, won.
> We never got to abstracting it out but we should!
>
> Yet, I do not think we should require abstracting all of Xen PT as
> a pre-requisite for this work, but I think we can
> avoid adding to the duplication without a lot of effort.
> To start sharing with ROM code, I think we should rename
> AssignedDevice->KvmAssignedDevice, and move fields that can be shared
> with Xen from there to AssignedDevice.

Its not simple to share something between AssignedDevice and the similar 
structure, XenHostPCIDevice.

As I said previously AssignedDevice is just activated in kvm_enabled(), 
then set all properties to this structure.

But kvm_enabled() is zero since we always disable this in xen scenario. 
So this means we have to invoke pci-assign framework completely if we 
try to force to use this. So actually this would be equal to merge kvm 
and xen.

Or if you already figure out to avoid this happened let me know.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 05:50:27PM +0800, Chen, Tiejun wrote:
> On 2014/7/1 13:47, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 08:34:46PM +0100, Stefano Stabellini wrote:
> >>On Fri, 27 Jun 2014, Chen, Tiejun wrote:
> >>>On 2014/6/25 17:58, Chen, Tiejun wrote:
> >>>>On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> >>>>>On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> >>>>>>>On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> >>>>>>>>On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> >>>>>>>>>On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> >>>>>>>>>>>On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>>>>In fact it's exactly what passthrough does.
> >>>>>>>>>>>>>I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> >>>>>>>>>>>>>can be reused. How do you poke at the host device? sysfs?
> >>>>>>>>>>>>
> >>>>>>>>>>>>Yes, sysfs.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Thanks
> >>>>>>>>>>>>Tiejun
> >>>>>>>>>>>
> >>>>>>>>>>>Then you should be able to re-use large chunks of
> >>>>>>>>>>>./hw/i386/kvm/pci-assign.c: basically everything
> >>>>>>>>>>>that deals with emulation.
> >>>>>>>>>>
> >>>>>>>>>>Do you mean those hooks to get info from the real device? Xen
> >>>>>>>>>>have its own
> >>>>>>>>>>wrapper, xen_host_pci_get_block(), so we always go there in xen
> >>>>>>>>>>scenario.
> >>>>>>>>>>
> >>>>>>>>>>Thanks
> >>>>>>>>>>Tiejun
> >>>>>>>>>
> >>>>>>>>>Yes and that's not good.  We have two pieces of code doing mostly
> >>>>>>>>>identical things slightly differently.
> >>>>>>>>>hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> >>>>>>>>>but these really need to be unified.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>Sorry, take a look at this again,
> >>>>>>>>
> >>>>>>>>xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> >>>>>>>>int len)
> >>>>>>>>     |
> >>>>>>>>     + xen_host_pci_config_read(d, pos, buf, len)
> >>>>>>>>         |
> >>>>>>>>         + pread(d->config_fd, buf, len, pos)
> >>>>>>>>
> >>>>>>>>I thinks this should be same as kvm.
> >>>>>>>>
> >>>>>>>>Thanks
> >>>>>>>>Tiejun
> >>>>>>>
> >>>>>>>get_block is trivial.
> >>>>>>>
> >>>>>>>I really mean the whole PT infrastructure for
> >>>>>>>- discovering host devices through sysfs
> >>>>>>>- virtualizing devices
> >>>>>>>
> >>>>>>>rom, bars, msi ...
> >>>>>>>the list goes on.
> >>>>>>>
> >>>>>>>logic is mostly the same.
> >>>>>>>
> >>>>>>
> >>>>>>Looks you mean we can unify the entire PT infrastructure between kvm
> >>>>>>and xen
> >>>>>>inside qemu. But I'm afraid its not easy to do in a short time, so
> >>>>>>maybe we
> >>>>>>can queue this as next phase.
> >>>>>>
> >>>>>>Thanks
> >>>>>>Tiejun
> >>>>>
> >>>>>I'm afraid once we merge your code, you'll lose interest :)
> >>>>>
> >>>>
> >>>>Currently we have to push this feature into upstream as our first
> >>>>priority, so unless something is really needed to address. Of course I
> >>>>hope this point what we're talking is not such a thing :)
> >>>>
> >>>>But I can promise here I'd like to do this optimization with your guide
> >>>>next :)
> >>>>
> >>>>>At least, don't add duplicate code for ROM.
> >>>>>
> >>>>
> >>>>Let me try this.
> >>>>
> >>>
> >>>Its not easy as expected.
> >>>
> >>>kvm always work with this structure, AssignedDevice, and especially this is
> >>>just activated in kvm_enabled(). And then set all properties to this
> >>>structure.
> >>>
> >>>In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
> >>>into the structure, AssignedDevice. So this mean we have to split
> >>>assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
> >>>
> >>>I really agree we definitely need to unify PT infrastructure between kvm and
> >>>xen after this try since I can't understand why we originally introduce same
> >>>way to do same thing :(
> >>>
> >>>Do you have better idea? If not, I prefer we open this completely as next
> >>>action to follow-up. But this time I'm afraid I can't get in this.
> >>
> >>The Xen PT code came first. At the time Anthony Liguori and I argued for
> >>sharing the PT code with KVM going forward but Avi wanted to retain the
> >>KVM PT code as is in order not to introduce any regressions on KVM.
> >>
> >>Ah.. the good old times :-)
> >>
> >>http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html
> >
> >Right, I remember that there was an idea to first make the code
> >reusable before merging either Xen or KVM PT, but in the end
> >the plan to merge both and then abstract it out, won.
> >We never got to abstracting it out but we should!
> >
> >Yet, I do not think we should require abstracting all of Xen PT as
> >a pre-requisite for this work, but I think we can
> >avoid adding to the duplication without a lot of effort.
> >To start sharing with ROM code, I think we should rename
> >AssignedDevice->KvmAssignedDevice, and move fields that can be shared
> >with Xen from there to AssignedDevice.
> 
> Its not simple to share something between AssignedDevice and the similar
> structure, XenHostPCIDevice.
> 
> As I said previously AssignedDevice is just activated in kvm_enabled(), then
> set all properties to this structure.
> 
> But kvm_enabled() is zero since we always disable this in xen scenario. So
> this means we have to invoke pci-assign framework completely if we try to
> force to use this. So actually this would be equal to merge kvm and xen.
> 
> Or if you already figure out to avoid this happened let me know.
> 
> Thanks
> Tiejun

For now fill in the structure separately in xen.

-- 
MST

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 05:50:27PM +0800, Chen, Tiejun wrote:
> On 2014/7/1 13:47, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 08:34:46PM +0100, Stefano Stabellini wrote:
> >>On Fri, 27 Jun 2014, Chen, Tiejun wrote:
> >>>On 2014/6/25 17:58, Chen, Tiejun wrote:
> >>>>On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> >>>>>On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> >>>>>>>On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> >>>>>>>>On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> >>>>>>>>>On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> >>>>>>>>>>>On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>>>>In fact it's exactly what passthrough does.
> >>>>>>>>>>>>>I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> >>>>>>>>>>>>>can be reused. How do you poke at the host device? sysfs?
> >>>>>>>>>>>>
> >>>>>>>>>>>>Yes, sysfs.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Thanks
> >>>>>>>>>>>>Tiejun
> >>>>>>>>>>>
> >>>>>>>>>>>Then you should be able to re-use large chunks of
> >>>>>>>>>>>./hw/i386/kvm/pci-assign.c: basically everything
> >>>>>>>>>>>that deals with emulation.
> >>>>>>>>>>
> >>>>>>>>>>Do you mean those hooks to get info from the real device? Xen
> >>>>>>>>>>have its own
> >>>>>>>>>>wrapper, xen_host_pci_get_block(), so we always go there in xen
> >>>>>>>>>>scenario.
> >>>>>>>>>>
> >>>>>>>>>>Thanks
> >>>>>>>>>>Tiejun
> >>>>>>>>>
> >>>>>>>>>Yes and that's not good.  We have two pieces of code doing mostly
> >>>>>>>>>identical things slightly differently.
> >>>>>>>>>hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> >>>>>>>>>but these really need to be unified.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>Sorry, take a look at this again,
> >>>>>>>>
> >>>>>>>>xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> >>>>>>>>int len)
> >>>>>>>>     |
> >>>>>>>>     + xen_host_pci_config_read(d, pos, buf, len)
> >>>>>>>>         |
> >>>>>>>>         + pread(d->config_fd, buf, len, pos)
> >>>>>>>>
> >>>>>>>>I thinks this should be same as kvm.
> >>>>>>>>
> >>>>>>>>Thanks
> >>>>>>>>Tiejun
> >>>>>>>
> >>>>>>>get_block is trivial.
> >>>>>>>
> >>>>>>>I really mean the whole PT infrastructure for
> >>>>>>>- discovering host devices through sysfs
> >>>>>>>- virtualizing devices
> >>>>>>>
> >>>>>>>rom, bars, msi ...
> >>>>>>>the list goes on.
> >>>>>>>
> >>>>>>>logic is mostly the same.
> >>>>>>>
> >>>>>>
> >>>>>>Looks you mean we can unify the entire PT infrastructure between kvm
> >>>>>>and xen
> >>>>>>inside qemu. But I'm afraid its not easy to do in a short time, so
> >>>>>>maybe we
> >>>>>>can queue this as next phase.
> >>>>>>
> >>>>>>Thanks
> >>>>>>Tiejun
> >>>>>
> >>>>>I'm afraid once we merge your code, you'll lose interest :)
> >>>>>
> >>>>
> >>>>Currently we have to push this feature into upstream as our first
> >>>>priority, so unless something is really needed to address. Of course I
> >>>>hope this point what we're talking is not such a thing :)
> >>>>
> >>>>But I can promise here I'd like to do this optimization with your guide
> >>>>next :)
> >>>>
> >>>>>At least, don't add duplicate code for ROM.
> >>>>>
> >>>>
> >>>>Let me try this.
> >>>>
> >>>
> >>>Its not easy as expected.
> >>>
> >>>kvm always work with this structure, AssignedDevice, and especially this is
> >>>just activated in kvm_enabled(). And then set all properties to this
> >>>structure.
> >>>
> >>>In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
> >>>into the structure, AssignedDevice. So this mean we have to split
> >>>assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
> >>>
> >>>I really agree we definitely need to unify PT infrastructure between kvm and
> >>>xen after this try since I can't understand why we originally introduce same
> >>>way to do same thing :(
> >>>
> >>>Do you have better idea? If not, I prefer we open this completely as next
> >>>action to follow-up. But this time I'm afraid I can't get in this.
> >>
> >>The Xen PT code came first. At the time Anthony Liguori and I argued for
> >>sharing the PT code with KVM going forward but Avi wanted to retain the
> >>KVM PT code as is in order not to introduce any regressions on KVM.
> >>
> >>Ah.. the good old times :-)
> >>
> >>http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html
> >
> >Right, I remember that there was an idea to first make the code
> >reusable before merging either Xen or KVM PT, but in the end
> >the plan to merge both and then abstract it out, won.
> >We never got to abstracting it out but we should!
> >
> >Yet, I do not think we should require abstracting all of Xen PT as
> >a pre-requisite for this work, but I think we can
> >avoid adding to the duplication without a lot of effort.
> >To start sharing with ROM code, I think we should rename
> >AssignedDevice->KvmAssignedDevice, and move fields that can be shared
> >with Xen from there to AssignedDevice.
> 
> Its not simple to share something between AssignedDevice and the similar
> structure, XenHostPCIDevice.
> 
> As I said previously AssignedDevice is just activated in kvm_enabled(), then
> set all properties to this structure.
> 
> But kvm_enabled() is zero since we always disable this in xen scenario. So
> this means we have to invoke pci-assign framework completely if we try to
> force to use this. So actually this would be equal to merge kvm and xen.
> 
> Or if you already figure out to avoid this happened let me know.
> 
> Thanks
> Tiejun

For now fill in the structure separately in xen.

-- 
MST

Re: [Qemu-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Stefano Stabellini]

On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 08:34:46PM +0100, Stefano Stabellini wrote:
> > On Fri, 27 Jun 2014, Chen, Tiejun wrote:
> > > On 2014/6/25 17:58, Chen, Tiejun wrote:
> > > > On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> > > > > On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
> > > > > > On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> > > > > > > On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> > > > > > > > On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> > > > > > > > > On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> > > > > > > > > > On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> > > > > > > > > > > On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> > > > > > > > > > > > > In fact it's exactly what passthrough does.
> > > > > > > > > > > > > I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> > > > > > > > > > > > > can be reused. How do you poke at the host device? sysfs?
> > > > > > > > > > > > 
> > > > > > > > > > > > Yes, sysfs.
> > > > > > > > > > > > 
> > > > > > > > > > > > Thanks
> > > > > > > > > > > > Tiejun
> > > > > > > > > > > 
> > > > > > > > > > > Then you should be able to re-use large chunks of
> > > > > > > > > > > ./hw/i386/kvm/pci-assign.c: basically everything
> > > > > > > > > > > that deals with emulation.
> > > > > > > > > > 
> > > > > > > > > > Do you mean those hooks to get info from the real device? Xen
> > > > > > > > > > have its own
> > > > > > > > > > wrapper, xen_host_pci_get_block(), so we always go there in xen
> > > > > > > > > > scenario.
> > > > > > > > > > 
> > > > > > > > > > Thanks
> > > > > > > > > > Tiejun
> > > > > > > > > 
> > > > > > > > > Yes and that's not good.  We have two pieces of code doing mostly
> > > > > > > > > identical things slightly differently.
> > > > > > > > > hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> > > > > > > > > but these really need to be unified.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Sorry, take a look at this again,
> > > > > > > > 
> > > > > > > > xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> > > > > > > > int len)
> > > > > > > >     |
> > > > > > > >     + xen_host_pci_config_read(d, pos, buf, len)
> > > > > > > >         |
> > > > > > > >         + pread(d->config_fd, buf, len, pos)
> > > > > > > > 
> > > > > > > > I thinks this should be same as kvm.
> > > > > > > > 
> > > > > > > > Thanks
> > > > > > > > Tiejun
> > > > > > > 
> > > > > > > get_block is trivial.
> > > > > > > 
> > > > > > > I really mean the whole PT infrastructure for
> > > > > > > - discovering host devices through sysfs
> > > > > > > - virtualizing devices
> > > > > > > 
> > > > > > > rom, bars, msi ...
> > > > > > > the list goes on.
> > > > > > > 
> > > > > > > logic is mostly the same.
> > > > > > > 
> > > > > > 
> > > > > > Looks you mean we can unify the entire PT infrastructure between kvm
> > > > > > and xen
> > > > > > inside qemu. But I'm afraid its not easy to do in a short time, so
> > > > > > maybe we
> > > > > > can queue this as next phase.
> > > > > > 
> > > > > > Thanks
> > > > > > Tiejun
> > > > > 
> > > > > I'm afraid once we merge your code, you'll lose interest :)
> > > > > 
> > > > 
> > > > Currently we have to push this feature into upstream as our first
> > > > priority, so unless something is really needed to address. Of course I
> > > > hope this point what we're talking is not such a thing :)
> > > > 
> > > > But I can promise here I'd like to do this optimization with your guide
> > > > next :)
> > > > 
> > > > > At least, don't add duplicate code for ROM.
> > > > > 
> > > > 
> > > > Let me try this.
> > > > 
> > > 
> > > Its not easy as expected.
> > > 
> > > kvm always work with this structure, AssignedDevice, and especially this is
> > > just activated in kvm_enabled(). And then set all properties to this
> > > structure.
> > > 
> > > In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
> > > into the structure, AssignedDevice. So this mean we have to split
> > > assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
> > > 
> > > I really agree we definitely need to unify PT infrastructure between kvm and
> > > xen after this try since I can't understand why we originally introduce same
> > > way to do same thing :(
> > > 
> > > Do you have better idea? If not, I prefer we open this completely as next
> > > action to follow-up. But this time I'm afraid I can't get in this.
> > 
> > The Xen PT code came first. At the time Anthony Liguori and I argued for
> > sharing the PT code with KVM going forward but Avi wanted to retain the
> > KVM PT code as is in order not to introduce any regressions on KVM.
> > 
> > Ah.. the good old times :-)
> > 
> > http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html
> 
> Right, I remember that there was an idea to first make the code
> reusable before merging either Xen or KVM PT, but in the end 
> the plan to merge both and then abstract it out, won.
> We never got to abstracting it out but we should!

I agree


> Yet, I do not think we should require abstracting all of Xen PT as
> a pre-requisite for this work, but I think we can
> avoid adding to the duplication without a lot of effort.

It seems like a good idea


> To start sharing with ROM code, I think we should rename
> AssignedDevice->KvmAssignedDevice, and move fields that can be shared
> with Xen from there to AssignedDevice.
>
> -- 
> MST
> 

Re: [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge

[Stefano Stabellini]

On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 08:34:46PM +0100, Stefano Stabellini wrote:
> > On Fri, 27 Jun 2014, Chen, Tiejun wrote:
> > > On 2014/6/25 17:58, Chen, Tiejun wrote:
> > > > On 2014/6/25 17:44, Michael S. Tsirkin wrote:
> > > > > On Wed, Jun 25, 2014 at 05:28:48PM +0800, Chen, Tiejun wrote:
> > > > > > On 2014/6/25 17:21, Michael S. Tsirkin wrote:
> > > > > > > On Wed, Jun 25, 2014 at 05:14:30PM +0800, Chen, Tiejun wrote:
> > > > > > > > On 2014/6/25 17:04, Michael S. Tsirkin wrote:
> > > > > > > > > On Wed, Jun 25, 2014 at 04:48:02PM +0800, Chen, Tiejun wrote:
> > > > > > > > > > On 2014/6/25 16:43, Michael S. Tsirkin wrote:
> > > > > > > > > > > On Wed, Jun 25, 2014 at 04:39:07PM +0800, Chen, Tiejun wrote:
> > > > > > > > > > > > > In fact it's exactly what passthrough does.
> > > > > > > > > > > > > I wonder if more bits from ./hw/i386/kvm/pci-assign.c
> > > > > > > > > > > > > can be reused. How do you poke at the host device? sysfs?
> > > > > > > > > > > > 
> > > > > > > > > > > > Yes, sysfs.
> > > > > > > > > > > > 
> > > > > > > > > > > > Thanks
> > > > > > > > > > > > Tiejun
> > > > > > > > > > > 
> > > > > > > > > > > Then you should be able to re-use large chunks of
> > > > > > > > > > > ./hw/i386/kvm/pci-assign.c: basically everything
> > > > > > > > > > > that deals with emulation.
> > > > > > > > > > 
> > > > > > > > > > Do you mean those hooks to get info from the real device? Xen
> > > > > > > > > > have its own
> > > > > > > > > > wrapper, xen_host_pci_get_block(), so we always go there in xen
> > > > > > > > > > scenario.
> > > > > > > > > > 
> > > > > > > > > > Thanks
> > > > > > > > > > Tiejun
> > > > > > > > > 
> > > > > > > > > Yes and that's not good.  We have two pieces of code doing mostly
> > > > > > > > > identical things slightly differently.
> > > > > > > > > hw/i386/kvm/pci-assign.c is a bit younger so it's cleaner,
> > > > > > > > > but these really need to be unified.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Sorry, take a look at this again,
> > > > > > > > 
> > > > > > > > xen_host_pci_get_block(XenHostPCIDevice *d, int pos, uint8_t *buf,
> > > > > > > > int len)
> > > > > > > >     |
> > > > > > > >     + xen_host_pci_config_read(d, pos, buf, len)
> > > > > > > >         |
> > > > > > > >         + pread(d->config_fd, buf, len, pos)
> > > > > > > > 
> > > > > > > > I thinks this should be same as kvm.
> > > > > > > > 
> > > > > > > > Thanks
> > > > > > > > Tiejun
> > > > > > > 
> > > > > > > get_block is trivial.
> > > > > > > 
> > > > > > > I really mean the whole PT infrastructure for
> > > > > > > - discovering host devices through sysfs
> > > > > > > - virtualizing devices
> > > > > > > 
> > > > > > > rom, bars, msi ...
> > > > > > > the list goes on.
> > > > > > > 
> > > > > > > logic is mostly the same.
> > > > > > > 
> > > > > > 
> > > > > > Looks you mean we can unify the entire PT infrastructure between kvm
> > > > > > and xen
> > > > > > inside qemu. But I'm afraid its not easy to do in a short time, so
> > > > > > maybe we
> > > > > > can queue this as next phase.
> > > > > > 
> > > > > > Thanks
> > > > > > Tiejun
> > > > > 
> > > > > I'm afraid once we merge your code, you'll lose interest :)
> > > > > 
> > > > 
> > > > Currently we have to push this feature into upstream as our first
> > > > priority, so unless something is really needed to address. Of course I
> > > > hope this point what we're talking is not such a thing :)
> > > > 
> > > > But I can promise here I'd like to do this optimization with your guide
> > > > next :)
> > > > 
> > > > > At least, don't add duplicate code for ROM.
> > > > > 
> > > > 
> > > > Let me try this.
> > > > 
> > > 
> > > Its not easy as expected.
> > > 
> > > kvm always work with this structure, AssignedDevice, and especially this is
> > > just activated in kvm_enabled(). And then set all properties to this
> > > structure.
> > > 
> > > In xen case, the similar structure, XenHostPCIDevice, is not easy transferred
> > > into the structure, AssignedDevice. So this mean we have to split
> > > assigned_dev_load_option_rom() as line by line for xen and kvm, respectively.
> > > 
> > > I really agree we definitely need to unify PT infrastructure between kvm and
> > > xen after this try since I can't understand why we originally introduce same
> > > way to do same thing :(
> > > 
> > > Do you have better idea? If not, I prefer we open this completely as next
> > > action to follow-up. But this time I'm afraid I can't get in this.
> > 
> > The Xen PT code came first. At the time Anthony Liguori and I argued for
> > sharing the PT code with KVM going forward but Avi wanted to retain the
> > KVM PT code as is in order not to introduce any regressions on KVM.
> > 
> > Ah.. the good old times :-)
> > 
> > http://lists.xen.org/archives/html/xen-devel/2011-10/msg00195.html
> 
> Right, I remember that there was an idea to first make the code
> reusable before merging either Xen or KVM PT, but in the end 
> the plan to merge both and then abstract it out, won.
> We never got to abstracting it out but we should!

I agree


> Yet, I do not think we should require abstracting all of Xen PT as
> a pre-requisite for this work, but I think we can
> avoid adding to the duplication without a lot of effort.

It seems like a good idea


> To start sharing with ROM code, I think we should rename
> AssignedDevice->KvmAssignedDevice, and move fields that can be shared
> with Xen from there to AssignedDevice.
>
> -- 
> MST
> 

[Qemu-devel] [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Tiejun Chen]

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.

The original patch is from Weidong Han <weidong.han@intel.com>

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Cc: Weidong Han <weidong.han@intel.com>
---
v5:

* Don't pass vendor/device ids in igd_pci_read().
* Add to support offset 0x44/0x48.

v4:

* Given that pci_create_pch() is called unconditionally, so we just return 0
  even if its failed to check xen_has_gfx_passthru.
* Remove one spurious change. 

v3:

* Improve comments to make that readable.

v2:

* To introduce is_igd_passthrough() to make sure we touch physical host bridge
  only in IGD case.

 hw/xen/xen_pt.h          |   4 ++
 hw/xen/xen_pt_graphics.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 160 insertions(+)

diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 4d3a18d..507165c 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -302,5 +302,9 @@ extern int xen_has_gfx_passthru;
 int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
 int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
 int xen_pt_setup_vga(XenHostPCIDevice *dev);
+int pci_create_pch(PCIBus *bus);
+void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
+                   uint32_t val, int len);
+uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
 
 #endif /* !XEN_PT_H */
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 974b7e9..f3fbfed 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -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"
 
 static int is_vga_passthrough(XenHostPCIDevice *dev)
 {
@@ -291,3 +292,158 @@ static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
     XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
     return 0;
 }
+
+int pci_create_pch(PCIBus *bus)
+{
+    XenHostPCIDevice hdev;
+    int r = 0;
+
+    if (!xen_has_gfx_passthru) {
+        return r;
+    }
+
+    r = xen_host_pci_device_get(&hdev, 0, 0, 0x1f, 0);
+    if (r) {
+        XEN_PT_ERR(NULL, "Failed to find Intel PCH on host\n");
+        goto err;
+    }
+
+    if (hdev.vendor_id == PCI_VENDOR_ID_INTEL) {
+        r = create_pseudo_pch_isa_bridge(bus, &hdev);
+        if (r) {
+            XEN_PT_ERR(NULL, "Failed to create PCH ISA bridge.\n");
+            goto err;
+        }
+    }
+
+    xen_host_pci_device_put(&hdev);
+
+err:
+    return r;
+}
+
+/*
+ * 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 further confirm.
+ */
+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_vga_passthrough(&s->real_device)
+                    && (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL));
+    } else {
+        return 0;
+    }
+}
+
+void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
+                   uint32_t val, int len)
+{
+    XenHostPCIDevice dev;
+    int r;
+
+    /* IGD read/write is through the host bridge.
+     * ISA bridge is only for detect purpose. In i915 driver it will
+     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
+     * intel_detect_pch().
+     */
+
+    assert(pci_dev->devfn == 0x00);
+
+    if (!is_igd_passthrough(pci_dev)) {
+        goto write_default;
+    }
+
+    /* Just work for the i915 driver. */
+    switch (config_addr) {
+    case 0x58:      /* PAVPC Offset */
+        break;
+    default:
+        /* Just sets the emulated values. */
+        goto write_default;
+    }
+
+    /* Host write */
+    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
+    if (r) {
+        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
+        abort();
+    }
+
+    r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
+    if (r) {
+        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
+        abort();
+    }
+
+    xen_host_pci_device_put(&dev);
+
+    return;
+
+write_default:
+    pci_default_write_config(pci_dev, config_addr, val, len);
+}
+
+uint32_t 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.
+     * ISA bridge is only for detect purpose. In i915 driver it will
+     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
+     * intel_detect_pch().
+     */
+    assert(pci_dev->devfn == 0x00);
+
+    if (!is_igd_passthrough(pci_dev)) {
+        goto read_default;
+    }
+
+    /* Just work for the i915 driver. */
+    switch (config_addr) {
+    case 0x08:        /* revision id */
+    case 0x2c:        /* sybsystem vendor id */
+    case 0x2e:        /* sybsystem id */
+    case 0x44:        /* MCHBAR I915 */
+    case 0x48:        /* MCHBAR I965 */
+    case 0x50:        /* SNB: processor graphics control register */
+    case 0x52:        /* processor graphics control register */
+    case 0xa0:        /* top of memory */
+    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
+    case 0x58:        /* SNB: PAVPC Offset */
+    case 0xa4:        /* SNB: graphics base of stolen memory */
+    case 0xa8:        /* SNB: base of GTT stolen memory */
+        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:
+    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;
+}
-- 
1.9.1

[v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Tiejun Chen]

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.

The original patch is from Weidong Han <weidong.han@intel.com>

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Cc: Weidong Han <weidong.han@intel.com>
---
v5:

* Don't pass vendor/device ids in igd_pci_read().
* Add to support offset 0x44/0x48.

v4:

* Given that pci_create_pch() is called unconditionally, so we just return 0
  even if its failed to check xen_has_gfx_passthru.
* Remove one spurious change. 

v3:

* Improve comments to make that readable.

v2:

* To introduce is_igd_passthrough() to make sure we touch physical host bridge
  only in IGD case.

 hw/xen/xen_pt.h          |   4 ++
 hw/xen/xen_pt_graphics.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 160 insertions(+)

diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 4d3a18d..507165c 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -302,5 +302,9 @@ extern int xen_has_gfx_passthru;
 int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
 int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
 int xen_pt_setup_vga(XenHostPCIDevice *dev);
+int pci_create_pch(PCIBus *bus);
+void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
+                   uint32_t val, int len);
+uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
 
 #endif /* !XEN_PT_H */
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 974b7e9..f3fbfed 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -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"
 
 static int is_vga_passthrough(XenHostPCIDevice *dev)
 {
@@ -291,3 +292,158 @@ static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
     XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
     return 0;
 }
+
+int pci_create_pch(PCIBus *bus)
+{
+    XenHostPCIDevice hdev;
+    int r = 0;
+
+    if (!xen_has_gfx_passthru) {
+        return r;
+    }
+
+    r = xen_host_pci_device_get(&hdev, 0, 0, 0x1f, 0);
+    if (r) {
+        XEN_PT_ERR(NULL, "Failed to find Intel PCH on host\n");
+        goto err;
+    }
+
+    if (hdev.vendor_id == PCI_VENDOR_ID_INTEL) {
+        r = create_pseudo_pch_isa_bridge(bus, &hdev);
+        if (r) {
+            XEN_PT_ERR(NULL, "Failed to create PCH ISA bridge.\n");
+            goto err;
+        }
+    }
+
+    xen_host_pci_device_put(&hdev);
+
+err:
+    return r;
+}
+
+/*
+ * 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 further confirm.
+ */
+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_vga_passthrough(&s->real_device)
+                    && (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL));
+    } else {
+        return 0;
+    }
+}
+
+void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
+                   uint32_t val, int len)
+{
+    XenHostPCIDevice dev;
+    int r;
+
+    /* IGD read/write is through the host bridge.
+     * ISA bridge is only for detect purpose. In i915 driver it will
+     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
+     * intel_detect_pch().
+     */
+
+    assert(pci_dev->devfn == 0x00);
+
+    if (!is_igd_passthrough(pci_dev)) {
+        goto write_default;
+    }
+
+    /* Just work for the i915 driver. */
+    switch (config_addr) {
+    case 0x58:      /* PAVPC Offset */
+        break;
+    default:
+        /* Just sets the emulated values. */
+        goto write_default;
+    }
+
+    /* Host write */
+    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
+    if (r) {
+        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
+        abort();
+    }
+
+    r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
+    if (r) {
+        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
+        abort();
+    }
+
+    xen_host_pci_device_put(&dev);
+
+    return;
+
+write_default:
+    pci_default_write_config(pci_dev, config_addr, val, len);
+}
+
+uint32_t 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.
+     * ISA bridge is only for detect purpose. In i915 driver it will
+     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
+     * intel_detect_pch().
+     */
+    assert(pci_dev->devfn == 0x00);
+
+    if (!is_igd_passthrough(pci_dev)) {
+        goto read_default;
+    }
+
+    /* Just work for the i915 driver. */
+    switch (config_addr) {
+    case 0x08:        /* revision id */
+    case 0x2c:        /* sybsystem vendor id */
+    case 0x2e:        /* sybsystem id */
+    case 0x44:        /* MCHBAR I915 */
+    case 0x48:        /* MCHBAR I965 */
+    case 0x50:        /* SNB: processor graphics control register */
+    case 0x52:        /* processor graphics control register */
+    case 0xa0:        /* top of memory */
+    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
+    case 0x58:        /* SNB: PAVPC Offset */
+    case 0xa4:        /* SNB: graphics base of stolen memory */
+    case 0xa8:        /* SNB: base of GTT stolen memory */
+        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:
+    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;
+}
-- 
1.9.1

Re: [Qemu-devel] [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Paolo Bonzini]

Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> +int pci_create_pch(PCIBus *bus)
> +{
> +    XenHostPCIDevice hdev;
> +    int r = 0;
> +
> +    if (!xen_has_gfx_passthru) {
> +        return r;
> +    }
> +

You could make this an assertion, since the function is never called 
with xen_has_gfx_passthru == 0.  Or just drop the check completely, so 
the function can be moved in patch 2.

Paolo

Re: [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Paolo Bonzini]

Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> +int pci_create_pch(PCIBus *bus)
> +{
> +    XenHostPCIDevice hdev;
> +    int r = 0;
> +
> +    if (!xen_has_gfx_passthru) {
> +        return r;
> +    }
> +

You could make this an assertion, since the function is never called 
with xen_has_gfx_passthru == 0.  Or just drop the check completely, so 
the function can be moved in patch 2.

Paolo

Re: [Qemu-devel] [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Chen, Tiejun]

On 2014/6/25 14:25, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> +int pci_create_pch(PCIBus *bus)
>> +{
>> +    XenHostPCIDevice hdev;
>> +    int r = 0;
>> +
>> +    if (!xen_has_gfx_passthru) {
>> +        return r;
>> +    }
>> +
>
> You could make this an assertion, since the function is never called
> with xen_has_gfx_passthru == 0.  Or just drop the check completely, so

I will drop this completely.

Thanks
Tiejun

> the function can be moved in patch 2.
>
> Paolo
>
>

Re: [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Chen, Tiejun]

On 2014/6/25 14:25, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> +int pci_create_pch(PCIBus *bus)
>> +{
>> +    XenHostPCIDevice hdev;
>> +    int r = 0;
>> +
>> +    if (!xen_has_gfx_passthru) {
>> +        return r;
>> +    }
>> +
>
> You could make this an assertion, since the function is never called
> with xen_has_gfx_passthru == 0.  Or just drop the check completely, so

I will drop this completely.

Thanks
Tiejun

> the function can be moved in patch 2.
>
> Paolo
>
>

Re: [Qemu-devel] [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
> 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.
> 
> The original patch is from Weidong Han <weidong.han@intel.com>
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> Cc: Weidong Han <weidong.han@intel.com>
> ---
> v5:
> 
> * Don't pass vendor/device ids in igd_pci_read().
> * Add to support offset 0x44/0x48.
> 
> v4:
> 
> * Given that pci_create_pch() is called unconditionally, so we just return 0
>   even if its failed to check xen_has_gfx_passthru.
> * Remove one spurious change. 
> 
> v3:
> 
> * Improve comments to make that readable.
> 
> v2:
> 
> * To introduce is_igd_passthrough() to make sure we touch physical host bridge
>   only in IGD case.
> 
>  hw/xen/xen_pt.h          |   4 ++
>  hw/xen/xen_pt_graphics.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 160 insertions(+)
> 
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 4d3a18d..507165c 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -302,5 +302,9 @@ extern int xen_has_gfx_passthru;
>  int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
>  int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
>  int xen_pt_setup_vga(XenHostPCIDevice *dev);
> +int pci_create_pch(PCIBus *bus);
> +void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
> +                   uint32_t val, int len);
> +uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
>  
>  #endif /* !XEN_PT_H */
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> index 974b7e9..f3fbfed 100644
> --- a/hw/xen/xen_pt_graphics.c
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -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"
>  
>  static int is_vga_passthrough(XenHostPCIDevice *dev)
>  {
> @@ -291,3 +292,158 @@ static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
>      XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>      return 0;
>  }
> +
> +int pci_create_pch(PCIBus *bus)


Please prefix all xen specific non static functions
with xen_ or something like this.
pci_ is for pci core.

In fact it's a good idea to do this for static functions
as well, in case we add a conflicting function in
some header.

> +{
> +    XenHostPCIDevice hdev;
> +    int r = 0;
> +
> +    if (!xen_has_gfx_passthru) {
> +        return r;
> +    }
> +
> +    r = xen_host_pci_device_get(&hdev, 0, 0, 0x1f, 0);
> +    if (r) {
> +        XEN_PT_ERR(NULL, "Failed to find Intel PCH on host\n");
> +        goto err;
> +    }
> +
> +    if (hdev.vendor_id == PCI_VENDOR_ID_INTEL) {
> +        r = create_pseudo_pch_isa_bridge(bus, &hdev);
> +        if (r) {
> +            XEN_PT_ERR(NULL, "Failed to create PCH ISA bridge.\n");
> +            goto err;
> +        }
> +    }

Does it work on non intel?
It seems to return success.
Maybe you should just verify that vendor and device
ID have the expected values on the host, and
fail otherwise.

> +
> +    xen_host_pci_device_put(&hdev);
> +
> +err:
> +    return r;
> +}
> +
> +/*
> + * 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 further confirm.
> + */


confirm what?
Comments like this need to document what function does.

Maybe

/* Can we support IGD passthrough for this device?
 * We require ... <XYZ - fill in here>
 */

> +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_vga_passthrough(&s->real_device)
> +                    && (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL));
> +    } else {
> +        return 0;
> +    }
> +}
> +
> +void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
> +                   uint32_t val, int len)

Same here, xen_ everywhere please.

> +{
> +    XenHostPCIDevice dev;
> +    int r;
> +
> +    /* IGD read/write is through the host bridge.
> +     * ISA bridge is only for detect purpose. In i915 driver it will
> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
> +     * intel_detect_pch().

You mean in linux kernel I guess?

> +     */
> +
> +    assert(pci_dev->devfn == 0x00);
> +
> +    if (!is_igd_passthrough(pci_dev)) {
> +        goto write_default;
> +    }
> +
> +    /* Just work for the i915 driver. */
> +    switch (config_addr) {
> +    case 0x58:      /* PAVPC Offset */
> +        break;
> +    default:
> +        /* Just sets the emulated values. */
> +        goto write_default;
> +    }
> +
> +    /* Host write */
> +    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
> +    if (r) {
> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
> +    r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
> +    if (r) {
> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }


Cleaner:

	if (config_addr == 0x58) {
	     /* Host write */
	     r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
	     if (r) {
	         XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
	         abort();
	     }
	 
	     r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
	     if (r) {
	         XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
	         abort();
	     }
	}

Note this does not work on e.g. BE.
The best way is really to make the register writeable in wmask.
Then
    pci_default_write_config(pci_dev, config_addr, val, len);
    if (range_covers_byte(addr, len, 0x58)) {
		....

	     r = xen_host_pci_set_block(&dev, config_addr,
		 pci_dev->config + config_addr, len);
    }





> +
> +    xen_host_pci_device_put(&dev);
> +
> +    return;
> +
> +write_default:
> +    pci_default_write_config(pci_dev, config_addr, val, len);
> +}
> +
> +uint32_t 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.
> +     * ISA bridge is only for detect purpose. In i915 driver it will
> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
> +     * intel_detect_pch().
> +     */
> +    assert(pci_dev->devfn == 0x00);
> +
> +    if (!is_igd_passthrough(pci_dev)) {
> +        goto read_default;
> +    }
> +
> +    /* Just work for the i915 driver. */
> +    switch (config_addr) {
> +    case 0x08:        /* revision id */
> +    case 0x2c:        /* sybsystem vendor id */
> +    case 0x2e:        /* sybsystem id */

Since you set them to match host previously,
should be no need to override now.

> +    case 0x44:        /* MCHBAR I915 */
> +    case 0x48:        /* MCHBAR I965 */
> +    case 0x50:        /* SNB: processor graphics control register */
> +    case 0x52:        /* processor graphics control register */
> +    case 0xa0:        /* top of memory */
> +    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
> +    case 0x58:        /* SNB: PAVPC Offset */
> +    case 0xa4:        /* SNB: graphics base of stolen memory */
> +    case 0xa8:        /* SNB: base of GTT stolen memory */

Move the actual code here.

> +        break;
> +    default:
> +        /* Just gets the emulated values. */

and here.

> +        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:
> +    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;
> +}
> -- 
> 1.9.1

Re: [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
> 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.
> 
> The original patch is from Weidong Han <weidong.han@intel.com>
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> Cc: Weidong Han <weidong.han@intel.com>
> ---
> v5:
> 
> * Don't pass vendor/device ids in igd_pci_read().
> * Add to support offset 0x44/0x48.
> 
> v4:
> 
> * Given that pci_create_pch() is called unconditionally, so we just return 0
>   even if its failed to check xen_has_gfx_passthru.
> * Remove one spurious change. 
> 
> v3:
> 
> * Improve comments to make that readable.
> 
> v2:
> 
> * To introduce is_igd_passthrough() to make sure we touch physical host bridge
>   only in IGD case.
> 
>  hw/xen/xen_pt.h          |   4 ++
>  hw/xen/xen_pt_graphics.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 160 insertions(+)
> 
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 4d3a18d..507165c 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -302,5 +302,9 @@ extern int xen_has_gfx_passthru;
>  int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
>  int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
>  int xen_pt_setup_vga(XenHostPCIDevice *dev);
> +int pci_create_pch(PCIBus *bus);
> +void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
> +                   uint32_t val, int len);
> +uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
>  
>  #endif /* !XEN_PT_H */
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> index 974b7e9..f3fbfed 100644
> --- a/hw/xen/xen_pt_graphics.c
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -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"
>  
>  static int is_vga_passthrough(XenHostPCIDevice *dev)
>  {
> @@ -291,3 +292,158 @@ static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
>      XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>      return 0;
>  }
> +
> +int pci_create_pch(PCIBus *bus)


Please prefix all xen specific non static functions
with xen_ or something like this.
pci_ is for pci core.

In fact it's a good idea to do this for static functions
as well, in case we add a conflicting function in
some header.

> +{
> +    XenHostPCIDevice hdev;
> +    int r = 0;
> +
> +    if (!xen_has_gfx_passthru) {
> +        return r;
> +    }
> +
> +    r = xen_host_pci_device_get(&hdev, 0, 0, 0x1f, 0);
> +    if (r) {
> +        XEN_PT_ERR(NULL, "Failed to find Intel PCH on host\n");
> +        goto err;
> +    }
> +
> +    if (hdev.vendor_id == PCI_VENDOR_ID_INTEL) {
> +        r = create_pseudo_pch_isa_bridge(bus, &hdev);
> +        if (r) {
> +            XEN_PT_ERR(NULL, "Failed to create PCH ISA bridge.\n");
> +            goto err;
> +        }
> +    }

Does it work on non intel?
It seems to return success.
Maybe you should just verify that vendor and device
ID have the expected values on the host, and
fail otherwise.

> +
> +    xen_host_pci_device_put(&hdev);
> +
> +err:
> +    return r;
> +}
> +
> +/*
> + * 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 further confirm.
> + */


confirm what?
Comments like this need to document what function does.

Maybe

/* Can we support IGD passthrough for this device?
 * We require ... <XYZ - fill in here>
 */

> +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_vga_passthrough(&s->real_device)
> +                    && (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL));
> +    } else {
> +        return 0;
> +    }
> +}
> +
> +void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
> +                   uint32_t val, int len)

Same here, xen_ everywhere please.

> +{
> +    XenHostPCIDevice dev;
> +    int r;
> +
> +    /* IGD read/write is through the host bridge.
> +     * ISA bridge is only for detect purpose. In i915 driver it will
> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
> +     * intel_detect_pch().

You mean in linux kernel I guess?

> +     */
> +
> +    assert(pci_dev->devfn == 0x00);
> +
> +    if (!is_igd_passthrough(pci_dev)) {
> +        goto write_default;
> +    }
> +
> +    /* Just work for the i915 driver. */
> +    switch (config_addr) {
> +    case 0x58:      /* PAVPC Offset */
> +        break;
> +    default:
> +        /* Just sets the emulated values. */
> +        goto write_default;
> +    }
> +
> +    /* Host write */
> +    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
> +    if (r) {
> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
> +    r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
> +    if (r) {
> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }


Cleaner:

	if (config_addr == 0x58) {
	     /* Host write */
	     r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
	     if (r) {
	         XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
	         abort();
	     }
	 
	     r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
	     if (r) {
	         XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
	         abort();
	     }
	}

Note this does not work on e.g. BE.
The best way is really to make the register writeable in wmask.
Then
    pci_default_write_config(pci_dev, config_addr, val, len);
    if (range_covers_byte(addr, len, 0x58)) {
		....

	     r = xen_host_pci_set_block(&dev, config_addr,
		 pci_dev->config + config_addr, len);
    }





> +
> +    xen_host_pci_device_put(&dev);
> +
> +    return;
> +
> +write_default:
> +    pci_default_write_config(pci_dev, config_addr, val, len);
> +}
> +
> +uint32_t 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.
> +     * ISA bridge is only for detect purpose. In i915 driver it will
> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
> +     * intel_detect_pch().
> +     */
> +    assert(pci_dev->devfn == 0x00);
> +
> +    if (!is_igd_passthrough(pci_dev)) {
> +        goto read_default;
> +    }
> +
> +    /* Just work for the i915 driver. */
> +    switch (config_addr) {
> +    case 0x08:        /* revision id */
> +    case 0x2c:        /* sybsystem vendor id */
> +    case 0x2e:        /* sybsystem id */

Since you set them to match host previously,
should be no need to override now.

> +    case 0x44:        /* MCHBAR I915 */
> +    case 0x48:        /* MCHBAR I965 */
> +    case 0x50:        /* SNB: processor graphics control register */
> +    case 0x52:        /* processor graphics control register */
> +    case 0xa0:        /* top of memory */
> +    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
> +    case 0x58:        /* SNB: PAVPC Offset */
> +    case 0xa4:        /* SNB: graphics base of stolen memory */
> +    case 0xa8:        /* SNB: base of GTT stolen memory */

Move the actual code here.

> +        break;
> +    default:
> +        /* Just gets the emulated values. */

and here.

> +        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:
> +    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;
> +}
> -- 
> 1.9.1

Re: [Qemu-devel] [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Chen, Tiejun]

On 2014/6/25 15:04, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
>> Some registers of Intel IGD are mapped in host bridge, so it needs to

[snip]

>>   static int is_vga_passthrough(XenHostPCIDevice *dev)
>>   {
>> @@ -291,3 +292,158 @@ static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
>>       XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>       return 0;
>>   }
>> +
>> +int pci_create_pch(PCIBus *bus)
>
>
> Please prefix all xen specific non static functions
> with xen_ or something like this.

Okay.

> pci_ is for pci core.
>
> In fact it's a good idea to do this for static functions
> as well, in case we add a conflicting function in
> some header.
>
>> +{
>> +    XenHostPCIDevice hdev;
>> +    int r = 0;
>> +
>> +    if (!xen_has_gfx_passthru) {
>> +        return r;
>> +    }
>> +
>> +    r = xen_host_pci_device_get(&hdev, 0, 0, 0x1f, 0);
>> +    if (r) {
>> +        XEN_PT_ERR(NULL, "Failed to find Intel PCH on host\n");
>> +        goto err;
>> +    }
>> +
>> +    if (hdev.vendor_id == PCI_VENDOR_ID_INTEL) {
>> +        r = create_pseudo_pch_isa_bridge(bus, &hdev);
>> +        if (r) {
>> +            XEN_PT_ERR(NULL, "Failed to create PCH ISA bridge.\n");
>> +            goto err;
>> +        }
>> +    }
>
> Does it work on non intel?

IGD means this should work on Intel platform.

> It seems to return success.

Okay, I'd like to change this a void.

> Maybe you should just verify that vendor and device
> ID have the expected values on the host, and

Vendor id is enough.

> fail otherwise.
>
>> +
>> +    xen_host_pci_device_put(&hdev);
>> +
>> +err:
>> +    return r;
>> +}
>> +
>> +/*
>> + * 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 further confirm.
>> + */
>
>
> confirm what?

So change like:

* passthrough device by that given devfn to avoid other devices access.

> Comments like this need to document what function does.
>
> Maybe
>
> /* Can we support IGD passthrough for this device?
>   * We require ... <XYZ - fill in here>
>   */
>
>> +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_vga_passthrough(&s->real_device)
>> +                    && (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL));
>> +    } else {
>> +        return 0;
>> +    }
>> +}
>> +
>> +void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
>> +                   uint32_t val, int len)
>
> Same here, xen_ everywhere please.

Okay.

>
>> +{
>> +    XenHostPCIDevice dev;
>> +    int r;
>> +
>> +    /* IGD read/write is through the host bridge.
>> +     * ISA bridge is only for detect purpose. In i915 driver it will
>> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
>> +     * intel_detect_pch().
>
> You mean in linux kernel I guess?

So change like,

* probe ISA bridge to discover the IGD, see comment in Linux:i915_drv.c:

>
>> +     */
>> +
>> +    assert(pci_dev->devfn == 0x00);
>> +
>> +    if (!is_igd_passthrough(pci_dev)) {
>> +        goto write_default;
>> +    }
>> +
>> +    /* Just work for the i915 driver. */
>> +    switch (config_addr) {
>> +    case 0x58:      /* PAVPC Offset */
>> +        break;
>> +    default:
>> +        /* Just sets the emulated values. */
>> +        goto write_default;
>> +    }
>> +
>> +    /* Host write */
>> +    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
>> +    if (r) {
>> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
>> +        abort();
>> +    }
>> +
>> +    r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
>> +    if (r) {
>> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
>> +        abort();
>> +    }
>
>
> Cleaner:
>
> 	if (config_addr == 0x58) {

Maybe we add other offset in the future, so we'd better keep in them in 
switch().

> 	     /* Host write */
> 	     r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
> 	     if (r) {
> 	         XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> 	         abort();
> 	     }
> 	
> 	     r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
> 	     if (r) {
> 	         XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> 	         abort();
> 	     }
> 	}
>
> Note this does not work on e.g. BE.

Why do we need take BE into consideration here? Shouldn't PCI already be LE?

> The best way is really to make the register writeable in wmask.
> Then
>      pci_default_write_config(pci_dev, config_addr, val, len);
>      if (range_covers_byte(addr, len, 0x58)) {
> 		....
>
> 	     r = xen_host_pci_set_block(&dev, config_addr,
> 		 pci_dev->config + config_addr, len);
>      }
>
>
>
>
>
>> +
>> +    xen_host_pci_device_put(&dev);
>> +
>> +    return;
>> +
>> +write_default:
>> +    pci_default_write_config(pci_dev, config_addr, val, len);
>> +}
>> +
>> +uint32_t 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.
>> +     * ISA bridge is only for detect purpose. In i915 driver it will
>> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
>> +     * intel_detect_pch().
>> +     */
>> +    assert(pci_dev->devfn == 0x00);
>> +
>> +    if (!is_igd_passthrough(pci_dev)) {
>> +        goto read_default;
>> +    }
>> +
>> +    /* Just work for the i915 driver. */
>> +    switch (config_addr) {
>> +    case 0x08:        /* revision id */
>> +    case 0x2c:        /* sybsystem vendor id */
>> +    case 0x2e:        /* sybsystem id */
>
> Since you set them to match host previously,
> should be no need to override now.

Just *read* the host bridge, no *write* here.

>
>> +    case 0x44:        /* MCHBAR I915 */
>> +    case 0x48:        /* MCHBAR I965 */
>> +    case 0x50:        /* SNB: processor graphics control register */
>> +    case 0x52:        /* processor graphics control register */
>> +    case 0xa0:        /* top of memory */
>> +    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
>> +    case 0x58:        /* SNB: PAVPC Offset */
>> +    case 0xa4:        /* SNB: graphics base of stolen memory */
>> +    case 0xa8:        /* SNB: base of GTT stolen memory */
>
> Move the actual code here.
>

Sorry, whats the actual code? Are you saying we can read all values from 
the host bridge in advance then restore them here?

Thanks
Tiejun

>> +        break;
>> +    default:
>> +        /* Just gets the emulated values. */
>
> and here.
>
>> +        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:
>> +    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;
>> +}
>> --
>> 1.9.1
>
>

Re: [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Chen, Tiejun]

On 2014/6/25 15:04, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
>> Some registers of Intel IGD are mapped in host bridge, so it needs to

[snip]

>>   static int is_vga_passthrough(XenHostPCIDevice *dev)
>>   {
>> @@ -291,3 +292,158 @@ static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
>>       XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>       return 0;
>>   }
>> +
>> +int pci_create_pch(PCIBus *bus)
>
>
> Please prefix all xen specific non static functions
> with xen_ or something like this.

Okay.

> pci_ is for pci core.
>
> In fact it's a good idea to do this for static functions
> as well, in case we add a conflicting function in
> some header.
>
>> +{
>> +    XenHostPCIDevice hdev;
>> +    int r = 0;
>> +
>> +    if (!xen_has_gfx_passthru) {
>> +        return r;
>> +    }
>> +
>> +    r = xen_host_pci_device_get(&hdev, 0, 0, 0x1f, 0);
>> +    if (r) {
>> +        XEN_PT_ERR(NULL, "Failed to find Intel PCH on host\n");
>> +        goto err;
>> +    }
>> +
>> +    if (hdev.vendor_id == PCI_VENDOR_ID_INTEL) {
>> +        r = create_pseudo_pch_isa_bridge(bus, &hdev);
>> +        if (r) {
>> +            XEN_PT_ERR(NULL, "Failed to create PCH ISA bridge.\n");
>> +            goto err;
>> +        }
>> +    }
>
> Does it work on non intel?

IGD means this should work on Intel platform.

> It seems to return success.

Okay, I'd like to change this a void.

> Maybe you should just verify that vendor and device
> ID have the expected values on the host, and

Vendor id is enough.

> fail otherwise.
>
>> +
>> +    xen_host_pci_device_put(&hdev);
>> +
>> +err:
>> +    return r;
>> +}
>> +
>> +/*
>> + * 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 further confirm.
>> + */
>
>
> confirm what?

So change like:

* passthrough device by that given devfn to avoid other devices access.

> Comments like this need to document what function does.
>
> Maybe
>
> /* Can we support IGD passthrough for this device?
>   * We require ... <XYZ - fill in here>
>   */
>
>> +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_vga_passthrough(&s->real_device)
>> +                    && (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL));
>> +    } else {
>> +        return 0;
>> +    }
>> +}
>> +
>> +void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
>> +                   uint32_t val, int len)
>
> Same here, xen_ everywhere please.

Okay.

>
>> +{
>> +    XenHostPCIDevice dev;
>> +    int r;
>> +
>> +    /* IGD read/write is through the host bridge.
>> +     * ISA bridge is only for detect purpose. In i915 driver it will
>> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
>> +     * intel_detect_pch().
>
> You mean in linux kernel I guess?

So change like,

* probe ISA bridge to discover the IGD, see comment in Linux:i915_drv.c:

>
>> +     */
>> +
>> +    assert(pci_dev->devfn == 0x00);
>> +
>> +    if (!is_igd_passthrough(pci_dev)) {
>> +        goto write_default;
>> +    }
>> +
>> +    /* Just work for the i915 driver. */
>> +    switch (config_addr) {
>> +    case 0x58:      /* PAVPC Offset */
>> +        break;
>> +    default:
>> +        /* Just sets the emulated values. */
>> +        goto write_default;
>> +    }
>> +
>> +    /* Host write */
>> +    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
>> +    if (r) {
>> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
>> +        abort();
>> +    }
>> +
>> +    r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
>> +    if (r) {
>> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
>> +        abort();
>> +    }
>
>
> Cleaner:
>
> 	if (config_addr == 0x58) {

Maybe we add other offset in the future, so we'd better keep in them in 
switch().

> 	     /* Host write */
> 	     r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
> 	     if (r) {
> 	         XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> 	         abort();
> 	     }
> 	
> 	     r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
> 	     if (r) {
> 	         XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> 	         abort();
> 	     }
> 	}
>
> Note this does not work on e.g. BE.

Why do we need take BE into consideration here? Shouldn't PCI already be LE?

> The best way is really to make the register writeable in wmask.
> Then
>      pci_default_write_config(pci_dev, config_addr, val, len);
>      if (range_covers_byte(addr, len, 0x58)) {
> 		....
>
> 	     r = xen_host_pci_set_block(&dev, config_addr,
> 		 pci_dev->config + config_addr, len);
>      }
>
>
>
>
>
>> +
>> +    xen_host_pci_device_put(&dev);
>> +
>> +    return;
>> +
>> +write_default:
>> +    pci_default_write_config(pci_dev, config_addr, val, len);
>> +}
>> +
>> +uint32_t 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.
>> +     * ISA bridge is only for detect purpose. In i915 driver it will
>> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
>> +     * intel_detect_pch().
>> +     */
>> +    assert(pci_dev->devfn == 0x00);
>> +
>> +    if (!is_igd_passthrough(pci_dev)) {
>> +        goto read_default;
>> +    }
>> +
>> +    /* Just work for the i915 driver. */
>> +    switch (config_addr) {
>> +    case 0x08:        /* revision id */
>> +    case 0x2c:        /* sybsystem vendor id */
>> +    case 0x2e:        /* sybsystem id */
>
> Since you set them to match host previously,
> should be no need to override now.

Just *read* the host bridge, no *write* here.

>
>> +    case 0x44:        /* MCHBAR I915 */
>> +    case 0x48:        /* MCHBAR I965 */
>> +    case 0x50:        /* SNB: processor graphics control register */
>> +    case 0x52:        /* processor graphics control register */
>> +    case 0xa0:        /* top of memory */
>> +    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
>> +    case 0x58:        /* SNB: PAVPC Offset */
>> +    case 0xa4:        /* SNB: graphics base of stolen memory */
>> +    case 0xa8:        /* SNB: base of GTT stolen memory */
>
> Move the actual code here.
>

Sorry, whats the actual code? Are you saying we can read all values from 
the host bridge in advance then restore them here?

Thanks
Tiejun

>> +        break;
>> +    default:
>> +        /* Just gets the emulated values. */
>
> and here.
>
>> +        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:
>> +    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;
>> +}
>> --
>> 1.9.1
>
>

Re: [Qemu-devel] [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
> 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.
> 
> The original patch is from Weidong Han <weidong.han@intel.com>
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> Cc: Weidong Han <weidong.han@intel.com>
> ---
> v5:
> 
> * Don't pass vendor/device ids in igd_pci_read().
> * Add to support offset 0x44/0x48.
> 
> v4:
> 
> * Given that pci_create_pch() is called unconditionally, so we just return 0
>   even if its failed to check xen_has_gfx_passthru.
> * Remove one spurious change. 
> 
> v3:
> 
> * Improve comments to make that readable.
> 
> v2:
> 
> * To introduce is_igd_passthrough() to make sure we touch physical host bridge
>   only in IGD case.
> 
>  hw/xen/xen_pt.h          |   4 ++
>  hw/xen/xen_pt_graphics.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 160 insertions(+)
> 
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 4d3a18d..507165c 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -302,5 +302,9 @@ extern int xen_has_gfx_passthru;
>  int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
>  int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
>  int xen_pt_setup_vga(XenHostPCIDevice *dev);
> +int pci_create_pch(PCIBus *bus);
> +void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
> +                   uint32_t val, int len);
> +uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
>  
>  #endif /* !XEN_PT_H */
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> index 974b7e9..f3fbfed 100644
> --- a/hw/xen/xen_pt_graphics.c
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -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"
>  
>  static int is_vga_passthrough(XenHostPCIDevice *dev)
>  {
> @@ -291,3 +292,158 @@ static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
>      XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>      return 0;
>  }
> +
> +int pci_create_pch(PCIBus *bus)
> +{
> +    XenHostPCIDevice hdev;
> +    int r = 0;
> +
> +    if (!xen_has_gfx_passthru) {
> +        return r;
> +    }
> +
> +    r = xen_host_pci_device_get(&hdev, 0, 0, 0x1f, 0);
> +    if (r) {
> +        XEN_PT_ERR(NULL, "Failed to find Intel PCH on host\n");
> +        goto err;
> +    }
> +
> +    if (hdev.vendor_id == PCI_VENDOR_ID_INTEL) {
> +        r = create_pseudo_pch_isa_bridge(bus, &hdev);
> +        if (r) {
> +            XEN_PT_ERR(NULL, "Failed to create PCH ISA bridge.\n");
> +            goto err;
> +        }
> +    }
> +
> +    xen_host_pci_device_put(&hdev);
> +
> +err:
> +    return r;
> +}
> +
> +/*
> + * 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 further confirm.
> + */
> +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_vga_passthrough(&s->real_device)
> +                    && (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL));
> +    } else {
> +        return 0;
> +    }
> +}
> +
> +void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
> +                   uint32_t val, int len)
> +{
> +    XenHostPCIDevice dev;
> +    int r;
> +
> +    /* IGD read/write is through the host bridge.
> +     * ISA bridge is only for detect purpose. In i915 driver it will
> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
> +     * intel_detect_pch().
> +     */
> +
> +    assert(pci_dev->devfn == 0x00);
> +
> +    if (!is_igd_passthrough(pci_dev)) {
> +        goto write_default;
> +    }
> +
> +    /* Just work for the i915 driver. */
> +    switch (config_addr) {
> +    case 0x58:      /* PAVPC Offset */
> +        break;
> +    default:
> +        /* Just sets the emulated values. */
> +        goto write_default;
> +    }
> +
> +    /* Host write */
> +    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
> +    if (r) {
> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
> +    r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
> +    if (r) {
> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
> +    xen_host_pci_device_put(&dev);
> +
> +    return;
> +
> +write_default:
> +    pci_default_write_config(pci_dev, config_addr, val, len);
> +}
> +
> +uint32_t 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.
> +     * ISA bridge is only for detect purpose. In i915 driver it will
> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
> +     * intel_detect_pch().
> +     */
> +    assert(pci_dev->devfn == 0x00);
> +
> +    if (!is_igd_passthrough(pci_dev)) {
> +        goto read_default;
> +    }
> +
> +    /* Just work for the i915 driver. */
> +    switch (config_addr) {
> +    case 0x08:        /* revision id */
> +    case 0x2c:        /* sybsystem vendor id */
> +    case 0x2e:        /* sybsystem id */
> +    case 0x44:        /* MCHBAR I915 */
> +    case 0x48:        /* MCHBAR I965 */

In fact, this is returning host addresses to guest, right?
Don't see how this can work except by luck.

> +    case 0x50:        /* SNB: processor graphics control register */
> +    case 0x52:        /* processor graphics control register */
> +    case 0xa0:        /* top of memory */

which memory? Could be similar.

> +    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
> +    case 0x58:        /* SNB: PAVPC Offset */
> +    case 0xa4:        /* SNB: graphics base of stolen memory */

Same thing.

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

Here too.

> +        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:
> +    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;
> +}
> -- 
> 1.9.1

Re: [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
> 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.
> 
> The original patch is from Weidong Han <weidong.han@intel.com>
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> Cc: Weidong Han <weidong.han@intel.com>
> ---
> v5:
> 
> * Don't pass vendor/device ids in igd_pci_read().
> * Add to support offset 0x44/0x48.
> 
> v4:
> 
> * Given that pci_create_pch() is called unconditionally, so we just return 0
>   even if its failed to check xen_has_gfx_passthru.
> * Remove one spurious change. 
> 
> v3:
> 
> * Improve comments to make that readable.
> 
> v2:
> 
> * To introduce is_igd_passthrough() to make sure we touch physical host bridge
>   only in IGD case.
> 
>  hw/xen/xen_pt.h          |   4 ++
>  hw/xen/xen_pt_graphics.c | 156 +++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 160 insertions(+)
> 
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 4d3a18d..507165c 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -302,5 +302,9 @@ extern int xen_has_gfx_passthru;
>  int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
>  int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev);
>  int xen_pt_setup_vga(XenHostPCIDevice *dev);
> +int pci_create_pch(PCIBus *bus);
> +void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
> +                   uint32_t val, int len);
> +uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
>  
>  #endif /* !XEN_PT_H */
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> index 974b7e9..f3fbfed 100644
> --- a/hw/xen/xen_pt_graphics.c
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -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"
>  
>  static int is_vga_passthrough(XenHostPCIDevice *dev)
>  {
> @@ -291,3 +292,158 @@ static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice *hdev)
>      XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>      return 0;
>  }
> +
> +int pci_create_pch(PCIBus *bus)
> +{
> +    XenHostPCIDevice hdev;
> +    int r = 0;
> +
> +    if (!xen_has_gfx_passthru) {
> +        return r;
> +    }
> +
> +    r = xen_host_pci_device_get(&hdev, 0, 0, 0x1f, 0);
> +    if (r) {
> +        XEN_PT_ERR(NULL, "Failed to find Intel PCH on host\n");
> +        goto err;
> +    }
> +
> +    if (hdev.vendor_id == PCI_VENDOR_ID_INTEL) {
> +        r = create_pseudo_pch_isa_bridge(bus, &hdev);
> +        if (r) {
> +            XEN_PT_ERR(NULL, "Failed to create PCH ISA bridge.\n");
> +            goto err;
> +        }
> +    }
> +
> +    xen_host_pci_device_put(&hdev);
> +
> +err:
> +    return r;
> +}
> +
> +/*
> + * 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 further confirm.
> + */
> +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_vga_passthrough(&s->real_device)
> +                    && (s->real_device.vendor_id == PCI_VENDOR_ID_INTEL));
> +    } else {
> +        return 0;
> +    }
> +}
> +
> +void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
> +                   uint32_t val, int len)
> +{
> +    XenHostPCIDevice dev;
> +    int r;
> +
> +    /* IGD read/write is through the host bridge.
> +     * ISA bridge is only for detect purpose. In i915 driver it will
> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
> +     * intel_detect_pch().
> +     */
> +
> +    assert(pci_dev->devfn == 0x00);
> +
> +    if (!is_igd_passthrough(pci_dev)) {
> +        goto write_default;
> +    }
> +
> +    /* Just work for the i915 driver. */
> +    switch (config_addr) {
> +    case 0x58:      /* PAVPC Offset */
> +        break;
> +    default:
> +        /* Just sets the emulated values. */
> +        goto write_default;
> +    }
> +
> +    /* Host write */
> +    r = xen_host_pci_device_get(&dev, 0, 0, 0, 0);
> +    if (r) {
> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
> +    r = xen_host_pci_set_block(&dev, config_addr, (uint8_t *)&val, len);
> +    if (r) {
> +        XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> +        abort();
> +    }
> +
> +    xen_host_pci_device_put(&dev);
> +
> +    return;
> +
> +write_default:
> +    pci_default_write_config(pci_dev, config_addr, val, len);
> +}
> +
> +uint32_t 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.
> +     * ISA bridge is only for detect purpose. In i915 driver it will
> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
> +     * intel_detect_pch().
> +     */
> +    assert(pci_dev->devfn == 0x00);
> +
> +    if (!is_igd_passthrough(pci_dev)) {
> +        goto read_default;
> +    }
> +
> +    /* Just work for the i915 driver. */
> +    switch (config_addr) {
> +    case 0x08:        /* revision id */
> +    case 0x2c:        /* sybsystem vendor id */
> +    case 0x2e:        /* sybsystem id */
> +    case 0x44:        /* MCHBAR I915 */
> +    case 0x48:        /* MCHBAR I965 */

In fact, this is returning host addresses to guest, right?
Don't see how this can work except by luck.

> +    case 0x50:        /* SNB: processor graphics control register */
> +    case 0x52:        /* processor graphics control register */
> +    case 0xa0:        /* top of memory */

which memory? Could be similar.

> +    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
> +    case 0x58:        /* SNB: PAVPC Offset */
> +    case 0xa4:        /* SNB: graphics base of stolen memory */

Same thing.

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

Here too.

> +        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:
> +    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;
> +}
> -- 
> 1.9.1

Re: [Qemu-devel] [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Chen, Tiejun]

On 2014/6/25 22:05, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
>> 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.
>>
>> The original patch is from Weidong Han <weidong.han@intel.com>
>>
>> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> Cc: Weidong Han <weidong.han@intel.com>
>> ---

[snip]

>> +
>> +uint32_t 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.
>> +     * ISA bridge is only for detect purpose. In i915 driver it will
>> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
>> +     * intel_detect_pch().
>> +     */
>> +    assert(pci_dev->devfn == 0x00);
>> +
>> +    if (!is_igd_passthrough(pci_dev)) {
>> +        goto read_default;
>> +    }
>> +
>> +    /* Just work for the i915 driver. */
>> +    switch (config_addr) {
>> +    case 0x08:        /* revision id */
>> +    case 0x2c:        /* sybsystem vendor id */
>> +    case 0x2e:        /* sybsystem id */
>> +    case 0x44:        /* MCHBAR I915 */
>> +    case 0x48:        /* MCHBAR I965 */
>
> In fact, this is returning host addresses to guest, right?

Yes. These two registers includes the address and some bits to control 
something. And the i915 driver just need to *read* address to reserve 
for PHP, but actually we don't support PHP now. So these address space 
are just be reserved.

And then it will *write* them with the PCI resources allocated in guest. 
And update those bits to enable or disable something in different occasions.

Actually we didn't introduce 0x44/0x48 originally but when Paolo saw the 
i915 driver will access them, so ask me what will be occurred. So I just 
add them simply to test again. But now looks they should be emulated, so 
I think we can get them out now. Then this should be enough to make sense.

> Don't see how this can work except by luck.
>
>> +    case 0x50:        /* SNB: processor graphics control register */
>> +    case 0x52:        /* processor graphics control register */
>> +    case 0xa0:        /* top of memory */
>
> which memory? Could be similar.

This is just a total memory used to the video device so we call top of 
memory. And this is used to limit that range, but as you know we never 
go over this so we can always live here.

>
>> +    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
>> +    case 0x58:        /* SNB: PAVPC Offset */
>> +    case 0xa4:        /* SNB: graphics base of stolen memory */
>
> Same thing.
>
>> +    case 0xa8:        /* SNB: base of GTT stolen memory */
>
> Here too.
>

We have 1:1 mapping for these two ranges so its fine.

These info are known to Linux. For Windows, it is opaque to us so we 
can't know what will be happened to Windows exactly, but I think this 
should be similar with Linux i915 driver mostly. And especially we also 
validate this on Windows 7 to confirm everything can work under Windows.

Thanks
Tiejun

Re: [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Chen, Tiejun]

On 2014/6/25 22:05, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
>> 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.
>>
>> The original patch is from Weidong Han <weidong.han@intel.com>
>>
>> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>> Cc: Weidong Han <weidong.han@intel.com>
>> ---

[snip]

>> +
>> +uint32_t 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.
>> +     * ISA bridge is only for detect purpose. In i915 driver it will
>> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
>> +     * intel_detect_pch().
>> +     */
>> +    assert(pci_dev->devfn == 0x00);
>> +
>> +    if (!is_igd_passthrough(pci_dev)) {
>> +        goto read_default;
>> +    }
>> +
>> +    /* Just work for the i915 driver. */
>> +    switch (config_addr) {
>> +    case 0x08:        /* revision id */
>> +    case 0x2c:        /* sybsystem vendor id */
>> +    case 0x2e:        /* sybsystem id */
>> +    case 0x44:        /* MCHBAR I915 */
>> +    case 0x48:        /* MCHBAR I965 */
>
> In fact, this is returning host addresses to guest, right?

Yes. These two registers includes the address and some bits to control 
something. And the i915 driver just need to *read* address to reserve 
for PHP, but actually we don't support PHP now. So these address space 
are just be reserved.

And then it will *write* them with the PCI resources allocated in guest. 
And update those bits to enable or disable something in different occasions.

Actually we didn't introduce 0x44/0x48 originally but when Paolo saw the 
i915 driver will access them, so ask me what will be occurred. So I just 
add them simply to test again. But now looks they should be emulated, so 
I think we can get them out now. Then this should be enough to make sense.

> Don't see how this can work except by luck.
>
>> +    case 0x50:        /* SNB: processor graphics control register */
>> +    case 0x52:        /* processor graphics control register */
>> +    case 0xa0:        /* top of memory */
>
> which memory? Could be similar.

This is just a total memory used to the video device so we call top of 
memory. And this is used to limit that range, but as you know we never 
go over this so we can always live here.

>
>> +    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
>> +    case 0x58:        /* SNB: PAVPC Offset */
>> +    case 0xa4:        /* SNB: graphics base of stolen memory */
>
> Same thing.
>
>> +    case 0xa8:        /* SNB: base of GTT stolen memory */
>
> Here too.
>

We have 1:1 mapping for these two ranges so its fine.

These info are known to Linux. For Windows, it is opaque to us so we 
can't know what will be happened to Windows exactly, but I think this 
should be similar with Linux i915 driver mostly. And especially we also 
validate this on Windows 7 to confirm everything can work under Windows.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Michael S. Tsirkin]

On Thu, Jun 26, 2014 at 01:34:14PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 22:05, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
> >>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.
> >>
> >>The original patch is from Weidong Han <weidong.han@intel.com>
> >>
> >>Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>Cc: Weidong Han <weidong.han@intel.com>
> >>---
> 
> [snip]
> 
> >>+
> >>+uint32_t 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.
> >>+     * ISA bridge is only for detect purpose. In i915 driver it will
> >>+     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
> >>+     * intel_detect_pch().
> >>+     */
> >>+    assert(pci_dev->devfn == 0x00);
> >>+
> >>+    if (!is_igd_passthrough(pci_dev)) {
> >>+        goto read_default;
> >>+    }
> >>+
> >>+    /* Just work for the i915 driver. */
> >>+    switch (config_addr) {
> >>+    case 0x08:        /* revision id */
> >>+    case 0x2c:        /* sybsystem vendor id */
> >>+    case 0x2e:        /* sybsystem id */
> >>+    case 0x44:        /* MCHBAR I915 */
> >>+    case 0x48:        /* MCHBAR I965 */
> >
> >In fact, this is returning host addresses to guest, right?
> 
> Yes. These two registers includes the address and some bits to control
> something. And the i915 driver just need to *read* address to reserve for
> PHP, but actually we don't support PHP now. So these address space are just
> be reserved.
> 
> And then it will *write* them with the PCI resources allocated in guest. And
> update those bits to enable or disable something in different occasions.
> 
> Actually we didn't introduce 0x44/0x48 originally but when Paolo saw the
> i915 driver will access them, so ask me what will be occurred. So I just add
> them simply to test again. But now looks they should be emulated, so I think
> we can get them out now. Then this should be enough to make sense.

Yes.

> >Don't see how this can work except by luck.
> >
> >>+    case 0x50:        /* SNB: processor graphics control register */
> >>+    case 0x52:        /* processor graphics control register */
> >>+    case 0xa0:        /* top of memory */
> >
> >which memory? Could be similar.
> 
> This is just a total memory used to the video device so we call top of
> memory. And this is used to limit that range, but as you know we never go
> over this so we can always live here.

Sorry I don't understand what you are saying here.

> >
> >>+    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
> >>+    case 0x58:        /* SNB: PAVPC Offset */
> >>+    case 0xa4:        /* SNB: graphics base of stolen memory */
> >
> >Same thing.
> >
> >>+    case 0xa8:        /* SNB: base of GTT stolen memory */
> >
> >Here too.
> >
> 
> We have 1:1 mapping for these two ranges so its fine.

Could you clarify? My question, again, is whether this is
returning host addresses to guest.

> These info are known to Linux. For Windows, it is opaque to us so we can't
> know what will be happened to Windows exactly, but I think this should be
> similar with Linux i915 driver mostly. And especially we also validate this
> on Windows 7 to confirm everything can work under Windows.
> 
> Thanks
> Tiejun

Re: [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Michael S. Tsirkin]

On Thu, Jun 26, 2014 at 01:34:14PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 22:05, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
> >>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.
> >>
> >>The original patch is from Weidong Han <weidong.han@intel.com>
> >>
> >>Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> >>Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> >>Cc: Weidong Han <weidong.han@intel.com>
> >>---
> 
> [snip]
> 
> >>+
> >>+uint32_t 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.
> >>+     * ISA bridge is only for detect purpose. In i915 driver it will
> >>+     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
> >>+     * intel_detect_pch().
> >>+     */
> >>+    assert(pci_dev->devfn == 0x00);
> >>+
> >>+    if (!is_igd_passthrough(pci_dev)) {
> >>+        goto read_default;
> >>+    }
> >>+
> >>+    /* Just work for the i915 driver. */
> >>+    switch (config_addr) {
> >>+    case 0x08:        /* revision id */
> >>+    case 0x2c:        /* sybsystem vendor id */
> >>+    case 0x2e:        /* sybsystem id */
> >>+    case 0x44:        /* MCHBAR I915 */
> >>+    case 0x48:        /* MCHBAR I965 */
> >
> >In fact, this is returning host addresses to guest, right?
> 
> Yes. These two registers includes the address and some bits to control
> something. And the i915 driver just need to *read* address to reserve for
> PHP, but actually we don't support PHP now. So these address space are just
> be reserved.
> 
> And then it will *write* them with the PCI resources allocated in guest. And
> update those bits to enable or disable something in different occasions.
> 
> Actually we didn't introduce 0x44/0x48 originally but when Paolo saw the
> i915 driver will access them, so ask me what will be occurred. So I just add
> them simply to test again. But now looks they should be emulated, so I think
> we can get them out now. Then this should be enough to make sense.

Yes.

> >Don't see how this can work except by luck.
> >
> >>+    case 0x50:        /* SNB: processor graphics control register */
> >>+    case 0x52:        /* processor graphics control register */
> >>+    case 0xa0:        /* top of memory */
> >
> >which memory? Could be similar.
> 
> This is just a total memory used to the video device so we call top of
> memory. And this is used to limit that range, but as you know we never go
> over this so we can always live here.

Sorry I don't understand what you are saying here.

> >
> >>+    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
> >>+    case 0x58:        /* SNB: PAVPC Offset */
> >>+    case 0xa4:        /* SNB: graphics base of stolen memory */
> >
> >Same thing.
> >
> >>+    case 0xa8:        /* SNB: base of GTT stolen memory */
> >
> >Here too.
> >
> 
> We have 1:1 mapping for these two ranges so its fine.

Could you clarify? My question, again, is whether this is
returning host addresses to guest.

> These info are known to Linux. For Windows, it is opaque to us so we can't
> know what will be happened to Windows exactly, but I think this should be
> similar with Linux i915 driver mostly. And especially we also validate this
> on Windows 7 to confirm everything can work under Windows.
> 
> Thanks
> Tiejun

Re: [Qemu-devel] [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Chen, Tiejun]

On 2014/6/26 14:04, Michael S. Tsirkin wrote:
> On Thu, Jun 26, 2014 at 01:34:14PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 22:05, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
>>>> 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.
>>>>
>>>> The original patch is from Weidong Han <weidong.han@intel.com>
>>>>
>>>> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>> Cc: Weidong Han <weidong.han@intel.com>
>>>> ---
>>
>> [snip]
>>
>>>> +
>>>> +uint32_t 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.
>>>> +     * ISA bridge is only for detect purpose. In i915 driver it will
>>>> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
>>>> +     * intel_detect_pch().
>>>> +     */
>>>> +    assert(pci_dev->devfn == 0x00);
>>>> +
>>>> +    if (!is_igd_passthrough(pci_dev)) {
>>>> +        goto read_default;
>>>> +    }
>>>> +
>>>> +    /* Just work for the i915 driver. */
>>>> +    switch (config_addr) {
>>>> +    case 0x08:        /* revision id */
>>>> +    case 0x2c:        /* sybsystem vendor id */
>>>> +    case 0x2e:        /* sybsystem id */
>>>> +    case 0x44:        /* MCHBAR I915 */
>>>> +    case 0x48:        /* MCHBAR I965 */
>>>
>>> In fact, this is returning host addresses to guest, right?
>>
>> Yes. These two registers includes the address and some bits to control
>> something. And the i915 driver just need to *read* address to reserve for
>> PHP, but actually we don't support PHP now. So these address space are just
>> be reserved.
>>
>> And then it will *write* them with the PCI resources allocated in guest. And
>> update those bits to enable or disable something in different occasions.
>>
>> Actually we didn't introduce 0x44/0x48 originally but when Paolo saw the
>> i915 driver will access them, so ask me what will be occurred. So I just add
>> them simply to test again. But now looks they should be emulated, so I think
>> we can get them out now. Then this should be enough to make sense.
>
> Yes.
>
>>> Don't see how this can work except by luck.
>>>
>>>> +    case 0x50:        /* SNB: processor graphics control register */
>>>> +    case 0x52:        /* processor graphics control register */
>>>> +    case 0xa0:        /* top of memory */
>>>
>>> which memory? Could be similar.
>>
>> This is just a total memory used to the video device so we call top of
>> memory. And this is used to limit that range, but as you know we never go
>> over this so we can always live here.
>
> Sorry I don't understand what you are saying here.

Gfx guy told me the memory here is indicating the total amount of 
populated physical memory that can be allocated to VGA, so this is fine 
to guest as a amount.

>
>>>
>>>> +    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
>>>> +    case 0x58:        /* SNB: PAVPC Offset */
>>>> +    case 0xa4:        /* SNB: graphics base of stolen memory */
>>>
>>> Same thing.
>>>
>>>> +    case 0xa8:        /* SNB: base of GTT stolen memory */
>>>
>>> Here too.
>>>
>>
>> We have 1:1 mapping for these two ranges so its fine.
>
> Could you clarify? My question, again, is whether this is
> returning host addresses to guest.

I means the host address is equal to the guest address and then 1:1 map 
between them.

Thanks
Tiejun

>
>> These info are known to Linux. For Windows, it is opaque to us so we can't
>> know what will be happened to Windows exactly, but I think this should be
>> similar with Linux i915 driver mostly. And especially we also validate this
>> on Windows 7 to confirm everything can work under Windows.
>>
>> Thanks
>> Tiejun
>
>

Re: [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D

[Chen, Tiejun]

On 2014/6/26 14:04, Michael S. Tsirkin wrote:
> On Thu, Jun 26, 2014 at 01:34:14PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 22:05, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 10:17:19AM +0800, Tiejun Chen wrote:
>>>> 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.
>>>>
>>>> The original patch is from Weidong Han <weidong.han@intel.com>
>>>>
>>>> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>> Cc: Weidong Han <weidong.han@intel.com>
>>>> ---
>>
>> [snip]
>>
>>>> +
>>>> +uint32_t 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.
>>>> +     * ISA bridge is only for detect purpose. In i915 driver it will
>>>> +     * probe ISA bridge to discover the IGD, see comment in i915_drv.c:
>>>> +     * intel_detect_pch().
>>>> +     */
>>>> +    assert(pci_dev->devfn == 0x00);
>>>> +
>>>> +    if (!is_igd_passthrough(pci_dev)) {
>>>> +        goto read_default;
>>>> +    }
>>>> +
>>>> +    /* Just work for the i915 driver. */
>>>> +    switch (config_addr) {
>>>> +    case 0x08:        /* revision id */
>>>> +    case 0x2c:        /* sybsystem vendor id */
>>>> +    case 0x2e:        /* sybsystem id */
>>>> +    case 0x44:        /* MCHBAR I915 */
>>>> +    case 0x48:        /* MCHBAR I965 */
>>>
>>> In fact, this is returning host addresses to guest, right?
>>
>> Yes. These two registers includes the address and some bits to control
>> something. And the i915 driver just need to *read* address to reserve for
>> PHP, but actually we don't support PHP now. So these address space are just
>> be reserved.
>>
>> And then it will *write* them with the PCI resources allocated in guest. And
>> update those bits to enable or disable something in different occasions.
>>
>> Actually we didn't introduce 0x44/0x48 originally but when Paolo saw the
>> i915 driver will access them, so ask me what will be occurred. So I just add
>> them simply to test again. But now looks they should be emulated, so I think
>> we can get them out now. Then this should be enough to make sense.
>
> Yes.
>
>>> Don't see how this can work except by luck.
>>>
>>>> +    case 0x50:        /* SNB: processor graphics control register */
>>>> +    case 0x52:        /* processor graphics control register */
>>>> +    case 0xa0:        /* top of memory */
>>>
>>> which memory? Could be similar.
>>
>> This is just a total memory used to the video device so we call top of
>> memory. And this is used to limit that range, but as you know we never go
>> over this so we can always live here.
>
> Sorry I don't understand what you are saying here.

Gfx guy told me the memory here is indicating the total amount of 
populated physical memory that can be allocated to VGA, so this is fine 
to guest as a amount.

>
>>>
>>>> +    case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
>>>> +    case 0x58:        /* SNB: PAVPC Offset */
>>>> +    case 0xa4:        /* SNB: graphics base of stolen memory */
>>>
>>> Same thing.
>>>
>>>> +    case 0xa8:        /* SNB: base of GTT stolen memory */
>>>
>>> Here too.
>>>
>>
>> We have 1:1 mapping for these two ranges so its fine.
>
> Could you clarify? My question, again, is whether this is
> returning host addresses to guest.

I means the host address is equal to the guest address and then 1:1 map 
between them.

Thanks
Tiejun

>
>> These info are known to Linux. For Windows, it is opaque to us so we can't
>> know what will be happened to Windows exactly, but I think this should be
>> similar with Linux i915 driver mostly. And especially we also validate this
>> on Windows 7 to confirm everything can work under Windows.
>>
>> Thanks
>> Tiejun
>
>

[Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Tiejun Chen]

Implement that pci host bridge to specific to passthrough. Actually
this just inherit the standard one.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
v5:

* Nothing is changed.

v4:

* Fix one typo in the patch head description.
* Use (xen_enabled() && xen_has_gfx_passthru) to make sure we only work
  in this scenario.

v3:

* Just fix this patch head description typo.

v2:

* New patch.

 hw/pci-host/piix.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 54 insertions(+), 2 deletions(-)

diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index e0e0946..9acf901 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -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.
@@ -95,6 +96,10 @@ typedef struct PIIX3State {
 #define I440FX_PCI_DEVICE(obj) \
     OBJECT_CHECK(PCII440FXState, (obj), TYPE_I440FX_PCI_DEVICE)
 
+#define TYPE_I440FX_XEN_PCI_DEVICE "i440FX-xen"
+#define I440FX_XEN_PCI_DEVICE(obj) \
+    OBJECT_CHECK(PCII440FXState, (obj), TYPE_I440FX_XEN_PCI_DEVICE)
+
 struct PCII440FXState {
     /*< private >*/
     PCIDevice parent_obj;
@@ -305,6 +310,16 @@ static int i440fx_initfn(PCIDevice *dev)
     return 0;
 }
 
+static int i440fx_xen_initfn(PCIDevice *dev)
+{
+    PCII440FXState *d = I440FX_XEN_PCI_DEVICE(dev);
+
+    dev->config[I440FX_SMRAM] = 0x02;
+
+    cpu_smm_register(&i440fx_set_smm, d);
+    return 0;
+}
+
 PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
                     int *piix3_devfn,
                     ISABus **isa_bus, qemu_irq *pic,
@@ -333,8 +348,15 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
     object_property_add_child(qdev_get_machine(), "i440fx", OBJECT(dev), NULL);
     qdev_init_nofail(dev);
 
-    d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
-    *pi440fx_state = I440FX_PCI_DEVICE(d);
+    if (xen_enabled() && xen_has_gfx_passthru) {
+        d = pci_create_simple(b, 0, TYPE_I440FX_XEN_PCI_DEVICE);
+        *pi440fx_state = I440FX_XEN_PCI_DEVICE(d);
+        pci_create_pch(b);
+    } else {
+        d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
+        *pi440fx_state = I440FX_PCI_DEVICE(d);
+    }
+
     f = *pi440fx_state;
     f->system_memory = address_space_mem;
     f->pci_address_space = pci_address_space;
@@ -704,6 +726,35 @@ static const TypeInfo i440fx_info = {
     .class_init    = i440fx_class_init,
 };
 
+static void i440fx_xen_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = i440fx_xen_initfn;
+    k->config_write = igd_pci_write;
+    k->config_read = igd_pci_read;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82441;
+    k->revision = 0x02;
+    k->class_id = PCI_CLASS_BRIDGE_ISA;
+    dc->desc = "XEN Host bridge";
+    dc->vmsd = &vmstate_i440fx;
+    /*
+     * PCI-facing part of the host bridge, not usable without the
+     * host-facing part, which can't be device_add'ed, yet.
+     */
+    dc->cannot_instantiate_with_device_add_yet = true;
+    dc->hotpluggable   = false;
+}
+
+static const TypeInfo i440fx_xen_info = {
+    .name          = TYPE_I440FX_XEN_PCI_DEVICE,
+    .parent        = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(PCII440FXState),
+    .class_init    = i440fx_xen_class_init,
+};
+
 static const char *i440fx_pcihost_root_bus_path(PCIHostState *host_bridge,
                                                 PCIBus *rootbus)
 {
@@ -745,6 +796,7 @@ static const TypeInfo i440fx_pcihost_info = {
 static void i440fx_register_types(void)
 {
     type_register_static(&i440fx_info);
+    type_register_static(&i440fx_xen_info);
     type_register_static(&piix3_info);
     type_register_static(&piix3_xen_info);
     type_register_static(&i440fx_pcihost_info);
-- 
1.9.1

[v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Tiejun Chen]

Implement that pci host bridge to specific to passthrough. Actually
this just inherit the standard one.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
v5:

* Nothing is changed.

v4:

* Fix one typo in the patch head description.
* Use (xen_enabled() && xen_has_gfx_passthru) to make sure we only work
  in this scenario.

v3:

* Just fix this patch head description typo.

v2:

* New patch.

 hw/pci-host/piix.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 54 insertions(+), 2 deletions(-)

diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index e0e0946..9acf901 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -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.
@@ -95,6 +96,10 @@ typedef struct PIIX3State {
 #define I440FX_PCI_DEVICE(obj) \
     OBJECT_CHECK(PCII440FXState, (obj), TYPE_I440FX_PCI_DEVICE)
 
+#define TYPE_I440FX_XEN_PCI_DEVICE "i440FX-xen"
+#define I440FX_XEN_PCI_DEVICE(obj) \
+    OBJECT_CHECK(PCII440FXState, (obj), TYPE_I440FX_XEN_PCI_DEVICE)
+
 struct PCII440FXState {
     /*< private >*/
     PCIDevice parent_obj;
@@ -305,6 +310,16 @@ static int i440fx_initfn(PCIDevice *dev)
     return 0;
 }
 
+static int i440fx_xen_initfn(PCIDevice *dev)
+{
+    PCII440FXState *d = I440FX_XEN_PCI_DEVICE(dev);
+
+    dev->config[I440FX_SMRAM] = 0x02;
+
+    cpu_smm_register(&i440fx_set_smm, d);
+    return 0;
+}
+
 PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
                     int *piix3_devfn,
                     ISABus **isa_bus, qemu_irq *pic,
@@ -333,8 +348,15 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
     object_property_add_child(qdev_get_machine(), "i440fx", OBJECT(dev), NULL);
     qdev_init_nofail(dev);
 
-    d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
-    *pi440fx_state = I440FX_PCI_DEVICE(d);
+    if (xen_enabled() && xen_has_gfx_passthru) {
+        d = pci_create_simple(b, 0, TYPE_I440FX_XEN_PCI_DEVICE);
+        *pi440fx_state = I440FX_XEN_PCI_DEVICE(d);
+        pci_create_pch(b);
+    } else {
+        d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
+        *pi440fx_state = I440FX_PCI_DEVICE(d);
+    }
+
     f = *pi440fx_state;
     f->system_memory = address_space_mem;
     f->pci_address_space = pci_address_space;
@@ -704,6 +726,35 @@ static const TypeInfo i440fx_info = {
     .class_init    = i440fx_class_init,
 };
 
+static void i440fx_xen_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = i440fx_xen_initfn;
+    k->config_write = igd_pci_write;
+    k->config_read = igd_pci_read;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82441;
+    k->revision = 0x02;
+    k->class_id = PCI_CLASS_BRIDGE_ISA;
+    dc->desc = "XEN Host bridge";
+    dc->vmsd = &vmstate_i440fx;
+    /*
+     * PCI-facing part of the host bridge, not usable without the
+     * host-facing part, which can't be device_add'ed, yet.
+     */
+    dc->cannot_instantiate_with_device_add_yet = true;
+    dc->hotpluggable   = false;
+}
+
+static const TypeInfo i440fx_xen_info = {
+    .name          = TYPE_I440FX_XEN_PCI_DEVICE,
+    .parent        = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(PCII440FXState),
+    .class_init    = i440fx_xen_class_init,
+};
+
 static const char *i440fx_pcihost_root_bus_path(PCIHostState *host_bridge,
                                                 PCIBus *rootbus)
 {
@@ -745,6 +796,7 @@ static const TypeInfo i440fx_pcihost_info = {
 static void i440fx_register_types(void)
 {
     type_register_static(&i440fx_info);
+    type_register_static(&i440fx_xen_info);
     type_register_static(&piix3_info);
     type_register_static(&piix3_xen_info);
     type_register_static(&i440fx_pcihost_info);
-- 
1.9.1

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Paolo Bonzini]

Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> +    if (xen_enabled() && xen_has_gfx_passthru) {
> +        d = pci_create_simple(b, 0, TYPE_I440FX_XEN_PCI_DEVICE);
> +        *pi440fx_state = I440FX_XEN_PCI_DEVICE(d);
> +        pci_create_pch(b);
> +    } else {
> +        d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
> +        *pi440fx_state = I440FX_PCI_DEVICE(d);
> +    }

As mentioned in the review of v4, this should be a separate, 
Xen-specific machine.  pci_create_pch should not be called in generic PC 
code.

Paolo

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Paolo Bonzini]

Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> +    if (xen_enabled() && xen_has_gfx_passthru) {
> +        d = pci_create_simple(b, 0, TYPE_I440FX_XEN_PCI_DEVICE);
> +        *pi440fx_state = I440FX_XEN_PCI_DEVICE(d);
> +        pci_create_pch(b);
> +    } else {
> +        d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
> +        *pi440fx_state = I440FX_PCI_DEVICE(d);
> +    }

As mentioned in the review of v4, this should be a separate, 
Xen-specific machine.  pci_create_pch should not be called in generic PC 
code.

Paolo

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Chen, Tiejun]

On 2014/6/25 14:24, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> +    if (xen_enabled() && xen_has_gfx_passthru) {
>> +        d = pci_create_simple(b, 0, TYPE_I440FX_XEN_PCI_DEVICE);
>> +        *pi440fx_state = I440FX_XEN_PCI_DEVICE(d);
>> +        pci_create_pch(b);
>> +    } else {
>> +        d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
>> +        *pi440fx_state = I440FX_PCI_DEVICE(d);
>> +    }
>
> As mentioned in the review of v4, this should be a separate,
> Xen-specific machine.  pci_create_pch should not be called in generic PC
> code.
>

I track this path:

qemu_register_pc_machine(&xenfv_machine);
	|
	+ .init = pc_xen_hvm_init,
		|
		+ pc_init_pci(machine);
			|
			+ pc_init1(machine, 1, 1);
				|
				+ i440fx_init()

So how to separate this to specific to xen? Or you mean we need to 
create an new machine to address this scenario? But actually this is 
same as xenfv_machine except for these little codes.

If you don't like this involve other cases, we may drop this chunk of 
codes as a function to tweak with CONFIG_XEN. But this is not good as 
well since this is device feature, so kvm may need this one day.


Thanks
Tiejun

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Chen, Tiejun]

On 2014/6/25 14:24, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> +    if (xen_enabled() && xen_has_gfx_passthru) {
>> +        d = pci_create_simple(b, 0, TYPE_I440FX_XEN_PCI_DEVICE);
>> +        *pi440fx_state = I440FX_XEN_PCI_DEVICE(d);
>> +        pci_create_pch(b);
>> +    } else {
>> +        d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
>> +        *pi440fx_state = I440FX_PCI_DEVICE(d);
>> +    }
>
> As mentioned in the review of v4, this should be a separate,
> Xen-specific machine.  pci_create_pch should not be called in generic PC
> code.
>

I track this path:

qemu_register_pc_machine(&xenfv_machine);
	|
	+ .init = pc_xen_hvm_init,
		|
		+ pc_init_pci(machine);
			|
			+ pc_init1(machine, 1, 1);
				|
				+ i440fx_init()

So how to separate this to specific to xen? Or you mean we need to 
create an new machine to address this scenario? But actually this is 
same as xenfv_machine except for these little codes.

If you don't like this involve other cases, we may drop this chunk of 
codes as a function to tweak with CONFIG_XEN. But this is not good as 
well since this is device feature, so kvm may need this one day.


Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Paolo Bonzini]

Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>
>
> So how to separate this to specific to xen? Or you mean we need to
> create an new machine to address this scenario? But actually this is
> same as xenfv_machine except for these little codes.

Yes, please create a new machine so that "-M pc" doesn't have any of 
these hacks.

Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the 
default).

Paolo

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Paolo Bonzini]

Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>
>
> So how to separate this to specific to xen? Or you mean we need to
> create an new machine to address this scenario? But actually this is
> same as xenfv_machine except for these little codes.

Yes, please create a new machine so that "-M pc" doesn't have any of 
these hacks.

Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the 
default).

Paolo

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Chen, Tiejun]

On 2014/6/27 19:26, Paolo Bonzini wrote:
> Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>>
>>
>> So how to separate this to specific to xen? Or you mean we need to
>> create an new machine to address this scenario? But actually this is
>> same as xenfv_machine except for these little codes.
>
> Yes, please create a new machine so that "-M pc" doesn't have any of
> these hacks.

But regardless of the machine is 'xenfv' or 'pc', we always call 
pc_init_pci(), then inside, i440fx_init() is always performed. So I 
think even we create a new machine, shouldn't we still call pc_init_pci()?

>
> Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> default).
>

Yes, Xen can use 'pc'.

Thanks
Tiejun

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Chen, Tiejun]

On 2014/6/27 19:26, Paolo Bonzini wrote:
> Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>>
>>
>> So how to separate this to specific to xen? Or you mean we need to
>> create an new machine to address this scenario? But actually this is
>> same as xenfv_machine except for these little codes.
>
> Yes, please create a new machine so that "-M pc" doesn't have any of
> these hacks.

But regardless of the machine is 'xenfv' or 'pc', we always call 
pc_init_pci(), then inside, i440fx_init() is always performed. So I 
think even we create a new machine, shouldn't we still call pc_init_pci()?

>
> Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> default).
>

Yes, Xen can use 'pc'.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Michael S. Tsirkin]

On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> On 2014/6/27 19:26, Paolo Bonzini wrote:
> >Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> >>
> >>
> >>So how to separate this to specific to xen? Or you mean we need to
> >>create an new machine to address this scenario? But actually this is
> >>same as xenfv_machine except for these little codes.
> >
> >Yes, please create a new machine so that "-M pc" doesn't have any of
> >these hacks.
> 
> But regardless of the machine is 'xenfv' or 'pc', we always call
> pc_init_pci(), then inside, i440fx_init() is always performed. So I think
> even we create a new machine, shouldn't we still call pc_init_pci()?
> 
> >
> >Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> >default).
> >
> 
> Yes, Xen can use 'pc'.
> 
> Thanks
> Tiejun

You are creating a new machine type where the pci host
looks like MCH but a bunch of other things are from i440fx.

I have some doubts about this combination being worth supporting - it
does not seem useful for anything except xen from the code you posted,
but maybe you can whittle down the number of places where you poke at
the host to make it reasonable: I can imagine that, if you are lucky and
the registers that i915 wants to poke to make it work on real hardware
happen to fall on top of reserved registers in the i440FX/PIIX3 pci
bridge.  OTOH it would be much more likely if you just start with
something that does have MCH, like Q35, or emulate a newer
machine type.  This is the path that people who wanted
to boot iOS on QEMU took, and the result is pretty good.

But regardless, this is clearly not a i440fx nor a q35 pc
so it needs a separate name.

-- 
MST

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Michael S. Tsirkin]

On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> On 2014/6/27 19:26, Paolo Bonzini wrote:
> >Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> >>
> >>
> >>So how to separate this to specific to xen? Or you mean we need to
> >>create an new machine to address this scenario? But actually this is
> >>same as xenfv_machine except for these little codes.
> >
> >Yes, please create a new machine so that "-M pc" doesn't have any of
> >these hacks.
> 
> But regardless of the machine is 'xenfv' or 'pc', we always call
> pc_init_pci(), then inside, i440fx_init() is always performed. So I think
> even we create a new machine, shouldn't we still call pc_init_pci()?
> 
> >
> >Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> >default).
> >
> 
> Yes, Xen can use 'pc'.
> 
> Thanks
> Tiejun

You are creating a new machine type where the pci host
looks like MCH but a bunch of other things are from i440fx.

I have some doubts about this combination being worth supporting - it
does not seem useful for anything except xen from the code you posted,
but maybe you can whittle down the number of places where you poke at
the host to make it reasonable: I can imagine that, if you are lucky and
the registers that i915 wants to poke to make it work on real hardware
happen to fall on top of reserved registers in the i440FX/PIIX3 pci
bridge.  OTOH it would be much more likely if you just start with
something that does have MCH, like Q35, or emulate a newer
machine type.  This is the path that people who wanted
to boot iOS on QEMU took, and the result is pretty good.

But regardless, this is clearly not a i440fx nor a q35 pc
so it needs a separate name.

-- 
MST

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Chen, Tiejun]

On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
>> On 2014/6/27 19:26, Paolo Bonzini wrote:
>>> Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>>>>
>>>>
>>>> So how to separate this to specific to xen? Or you mean we need to
>>>> create an new machine to address this scenario? But actually this is
>>>> same as xenfv_machine except for these little codes.
>>>
>>> Yes, please create a new machine so that "-M pc" doesn't have any of
>>> these hacks.
>>
>> But regardless of the machine is 'xenfv' or 'pc', we always call
>> pc_init_pci(), then inside, i440fx_init() is always performed. So I think
>> even we create a new machine, shouldn't we still call pc_init_pci()?
>>
>>>
>>> Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
>>> default).
>>>
>>
>> Yes, Xen can use 'pc'.
>>
>> Thanks
>> Tiejun
>
> You are creating a new machine type where the pci host
> looks like MCH but a bunch of other things are from i440fx.

Anthony,

Any comments to address this in xen case?

Thanks
Tiejun

>
> I have some doubts about this combination being worth supporting - it
> does not seem useful for anything except xen from the code you posted,
> but maybe you can whittle down the number of places where you poke at
> the host to make it reasonable: I can imagine that, if you are lucky and
> the registers that i915 wants to poke to make it work on real hardware
> happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> bridge.  OTOH it would be much more likely if you just start with
> something that does have MCH, like Q35, or emulate a newer
> machine type.  This is the path that people who wanted
> to boot iOS on QEMU took, and the result is pretty good.
>
> But regardless, this is clearly not a i440fx nor a q35 pc
> so it needs a separate name.
>

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Chen, Tiejun]

On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
>> On 2014/6/27 19:26, Paolo Bonzini wrote:
>>> Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>>>>
>>>>
>>>> So how to separate this to specific to xen? Or you mean we need to
>>>> create an new machine to address this scenario? But actually this is
>>>> same as xenfv_machine except for these little codes.
>>>
>>> Yes, please create a new machine so that "-M pc" doesn't have any of
>>> these hacks.
>>
>> But regardless of the machine is 'xenfv' or 'pc', we always call
>> pc_init_pci(), then inside, i440fx_init() is always performed. So I think
>> even we create a new machine, shouldn't we still call pc_init_pci()?
>>
>>>
>>> Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
>>> default).
>>>
>>
>> Yes, Xen can use 'pc'.
>>
>> Thanks
>> Tiejun
>
> You are creating a new machine type where the pci host
> looks like MCH but a bunch of other things are from i440fx.

Anthony,

Any comments to address this in xen case?

Thanks
Tiejun

>
> I have some doubts about this combination being worth supporting - it
> does not seem useful for anything except xen from the code you posted,
> but maybe you can whittle down the number of places where you poke at
> the host to make it reasonable: I can imagine that, if you are lucky and
> the registers that i915 wants to poke to make it work on real hardware
> happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> bridge.  OTOH it would be much more likely if you just start with
> something that does have MCH, like Q35, or emulate a newer
> machine type.  This is the path that people who wanted
> to boot iOS on QEMU took, and the result is pretty good.
>
> But regardless, this is clearly not a i440fx nor a q35 pc
> so it needs a separate name.
>

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Stefano Stabellini]

On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > 
> > > > > 
> > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > create an new machine to address this scenario? But actually this is
> > > > > same as xenfv_machine except for these little codes.
> > > > 
> > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > these hacks.
> > > 
> > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > pc_init_pci(), then inside, i440fx_init() is always performed. So I think
> > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > 
> > > > 
> > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > default).
> > > > 
> > > 
> > > Yes, Xen can use 'pc'.
> > > 
> > > Thanks
> > > Tiejun
> > 
> > You are creating a new machine type where the pci host
> > looks like MCH but a bunch of other things are from i440fx.
> 
> Anthony,
> 
> Any comments to address this in xen case?

Having a separate machine for this is reasonable. You can select the
right one from libxl anyway. From the name point of view I would go with
"xenigd".
Just take a look at xenfv and introduce something similar but specific
to your IGD PT use case.


> Thanks
> Tiejun
> 
> > 
> > I have some doubts about this combination being worth supporting - it
> > does not seem useful for anything except xen from the code you posted,
> > but maybe you can whittle down the number of places where you poke at
> > the host to make it reasonable: I can imagine that, if you are lucky and
> > the registers that i915 wants to poke to make it work on real hardware
> > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > bridge.  OTOH it would be much more likely if you just start with
> > something that does have MCH, like Q35, or emulate a newer
> > machine type.  This is the path that people who wanted
> > to boot iOS on QEMU took, and the result is pretty good.
> > 
> > But regardless, this is clearly not a i440fx nor a q35 pc
> > so it needs a separate name.
> > 
> 

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Stefano Stabellini]

On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > 
> > > > > 
> > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > create an new machine to address this scenario? But actually this is
> > > > > same as xenfv_machine except for these little codes.
> > > > 
> > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > these hacks.
> > > 
> > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > pc_init_pci(), then inside, i440fx_init() is always performed. So I think
> > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > 
> > > > 
> > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > default).
> > > > 
> > > 
> > > Yes, Xen can use 'pc'.
> > > 
> > > Thanks
> > > Tiejun
> > 
> > You are creating a new machine type where the pci host
> > looks like MCH but a bunch of other things are from i440fx.
> 
> Anthony,
> 
> Any comments to address this in xen case?

Having a separate machine for this is reasonable. You can select the
right one from libxl anyway. From the name point of view I would go with
"xenigd".
Just take a look at xenfv and introduce something similar but specific
to your IGD PT use case.


> Thanks
> Tiejun
> 
> > 
> > I have some doubts about this combination being worth supporting - it
> > does not seem useful for anything except xen from the code you posted,
> > but maybe you can whittle down the number of places where you poke at
> > the host to make it reasonable: I can imagine that, if you are lucky and
> > the registers that i915 wants to poke to make it work on real hardware
> > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > bridge.  OTOH it would be much more likely if you just start with
> > something that does have MCH, like Q35, or emulate a newer
> > machine type.  This is the path that people who wanted
> > to boot iOS on QEMU took, and the result is pretty good.
> > 
> > But regardless, this is clearly not a i440fx nor a q35 pc
> > so it needs a separate name.
> > 
> 

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Chen, Tiejun]

On 2014/7/1 3:42, Stefano Stabellini wrote:
> On Mon, 30 Jun 2014, Chen, Tiejun wrote:
>> On 2014/6/29 20:14, Michael S. Tsirkin wrote:
>>> On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/27 19:26, Paolo Bonzini wrote:
>>>>> Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>>>>>>
>>>>>>
>>>>>> So how to separate this to specific to xen? Or you mean we need to
>>>>>> create an new machine to address this scenario? But actually this is
>>>>>> same as xenfv_machine except for these little codes.
>>>>>
>>>>> Yes, please create a new machine so that "-M pc" doesn't have any of
>>>>> these hacks.
>>>>
>>>> But regardless of the machine is 'xenfv' or 'pc', we always call
>>>> pc_init_pci(), then inside, i440fx_init() is always performed. So I think
>>>> even we create a new machine, shouldn't we still call pc_init_pci()?
>>>>
>>>>>
>>>>> Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
>>>>> default).
>>>>>
>>>>
>>>> Yes, Xen can use 'pc'.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> You are creating a new machine type where the pci host
>>> looks like MCH but a bunch of other things are from i440fx.
>>
>> Anthony,
>>
>> Any comments to address this in xen case?
>
> Having a separate machine for this is reasonable. You can select the
> right one from libxl anyway. From the name point of view I would go with
> "xenigd".

Do this mean we need to change something libxl?

> Just take a look at xenfv and introduce something similar but specific
> to your IGD PT use case.
>

Which PCIe machine should I refer? i440fx or q35?

Thanks
Tiejun

>
>> Thanks
>> Tiejun
>>
>>>
>>> I have some doubts about this combination being worth supporting - it
>>> does not seem useful for anything except xen from the code you posted,
>>> but maybe you can whittle down the number of places where you poke at
>>> the host to make it reasonable: I can imagine that, if you are lucky and
>>> the registers that i915 wants to poke to make it work on real hardware
>>> happen to fall on top of reserved registers in the i440FX/PIIX3 pci
>>> bridge.  OTOH it would be much more likely if you just start with
>>> something that does have MCH, like Q35, or emulate a newer
>>> machine type.  This is the path that people who wanted
>>> to boot iOS on QEMU took, and the result is pretty good.
>>>
>>> But regardless, this is clearly not a i440fx nor a q35 pc
>>> so it needs a separate name.
>>>
>>
>

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Chen, Tiejun]

On 2014/7/1 3:42, Stefano Stabellini wrote:
> On Mon, 30 Jun 2014, Chen, Tiejun wrote:
>> On 2014/6/29 20:14, Michael S. Tsirkin wrote:
>>> On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/27 19:26, Paolo Bonzini wrote:
>>>>> Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>>>>>>
>>>>>>
>>>>>> So how to separate this to specific to xen? Or you mean we need to
>>>>>> create an new machine to address this scenario? But actually this is
>>>>>> same as xenfv_machine except for these little codes.
>>>>>
>>>>> Yes, please create a new machine so that "-M pc" doesn't have any of
>>>>> these hacks.
>>>>
>>>> But regardless of the machine is 'xenfv' or 'pc', we always call
>>>> pc_init_pci(), then inside, i440fx_init() is always performed. So I think
>>>> even we create a new machine, shouldn't we still call pc_init_pci()?
>>>>
>>>>>
>>>>> Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
>>>>> default).
>>>>>
>>>>
>>>> Yes, Xen can use 'pc'.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> You are creating a new machine type where the pci host
>>> looks like MCH but a bunch of other things are from i440fx.
>>
>> Anthony,
>>
>> Any comments to address this in xen case?
>
> Having a separate machine for this is reasonable. You can select the
> right one from libxl anyway. From the name point of view I would go with
> "xenigd".

Do this mean we need to change something libxl?

> Just take a look at xenfv and introduce something similar but specific
> to your IGD PT use case.
>

Which PCIe machine should I refer? i440fx or q35?

Thanks
Tiejun

>
>> Thanks
>> Tiejun
>>
>>>
>>> I have some doubts about this combination being worth supporting - it
>>> does not seem useful for anything except xen from the code you posted,
>>> but maybe you can whittle down the number of places where you poke at
>>> the host to make it reasonable: I can imagine that, if you are lucky and
>>> the registers that i915 wants to poke to make it work on real hardware
>>> happen to fall on top of reserved registers in the i440FX/PIIX3 pci
>>> bridge.  OTOH it would be much more likely if you just start with
>>> something that does have MCH, like Q35, or emulate a newer
>>> machine type.  This is the path that people who wanted
>>> to boot iOS on QEMU took, and the result is pretty good.
>>>
>>> But regardless, this is clearly not a i440fx nor a q35 pc
>>> so it needs a separate name.
>>>
>>
>

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Stefano Stabellini]

On Tue, 1 Jul 2014, Chen, Tiejun wrote:
> On 2014/7/1 3:42, Stefano Stabellini wrote:
> > On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> > > On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > > > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > > > 
> > > > > > > 
> > > > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > > > create an new machine to address this scenario? But actually this
> > > > > > > is
> > > > > > > same as xenfv_machine except for these little codes.
> > > > > > 
> > > > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > > > these hacks.
> > > > > 
> > > > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > > > pc_init_pci(), then inside, i440fx_init() is always performed. So I
> > > > > think
> > > > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > > > 
> > > > > > 
> > > > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > > > default).
> > > > > > 
> > > > > 
> > > > > Yes, Xen can use 'pc'.
> > > > > 
> > > > > Thanks
> > > > > Tiejun
> > > > 
> > > > You are creating a new machine type where the pci host
> > > > looks like MCH but a bunch of other things are from i440fx.
> > > 
> > > Anthony,
> > > 
> > > Any comments to address this in xen case?
> > 
> > Having a separate machine for this is reasonable. You can select the
> > right one from libxl anyway. From the name point of view I would go with
> > "xenigd".
> 
> Do this mean we need to change something libxl?

Yes: you would need to pass a different -machine option, see
tools/libxl/libxl_dm.c:libxl__build_device_model_args_new.
It would be a pretty small change.

> > Just take a look at xenfv and introduce something similar but specific
> > to your IGD PT use case.
> > 
> 
> Which PCIe machine should I refer? i440fx or q35?

I'd say i440fx.


> Thanks
> Tiejun
> 
> > 
> > > Thanks
> > > Tiejun
> > > 
> > > > 
> > > > I have some doubts about this combination being worth supporting - it
> > > > does not seem useful for anything except xen from the code you posted,
> > > > but maybe you can whittle down the number of places where you poke at
> > > > the host to make it reasonable: I can imagine that, if you are lucky and
> > > > the registers that i915 wants to poke to make it work on real hardware
> > > > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > > > bridge.  OTOH it would be much more likely if you just start with
> > > > something that does have MCH, like Q35, or emulate a newer
> > > > machine type.  This is the path that people who wanted
> > > > to boot iOS on QEMU took, and the result is pretty good.
> > > > 
> > > > But regardless, this is clearly not a i440fx nor a q35 pc
> > > > so it needs a separate name.
> > > > 
> > > 
> > 
> 

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Stefano Stabellini]

On Tue, 1 Jul 2014, Chen, Tiejun wrote:
> On 2014/7/1 3:42, Stefano Stabellini wrote:
> > On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> > > On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > > > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > > > 
> > > > > > > 
> > > > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > > > create an new machine to address this scenario? But actually this
> > > > > > > is
> > > > > > > same as xenfv_machine except for these little codes.
> > > > > > 
> > > > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > > > these hacks.
> > > > > 
> > > > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > > > pc_init_pci(), then inside, i440fx_init() is always performed. So I
> > > > > think
> > > > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > > > 
> > > > > > 
> > > > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > > > default).
> > > > > > 
> > > > > 
> > > > > Yes, Xen can use 'pc'.
> > > > > 
> > > > > Thanks
> > > > > Tiejun
> > > > 
> > > > You are creating a new machine type where the pci host
> > > > looks like MCH but a bunch of other things are from i440fx.
> > > 
> > > Anthony,
> > > 
> > > Any comments to address this in xen case?
> > 
> > Having a separate machine for this is reasonable. You can select the
> > right one from libxl anyway. From the name point of view I would go with
> > "xenigd".
> 
> Do this mean we need to change something libxl?

Yes: you would need to pass a different -machine option, see
tools/libxl/libxl_dm.c:libxl__build_device_model_args_new.
It would be a pretty small change.

> > Just take a look at xenfv and introduce something similar but specific
> > to your IGD PT use case.
> > 
> 
> Which PCIe machine should I refer? i440fx or q35?

I'd say i440fx.


> Thanks
> Tiejun
> 
> > 
> > > Thanks
> > > Tiejun
> > > 
> > > > 
> > > > I have some doubts about this combination being worth supporting - it
> > > > does not seem useful for anything except xen from the code you posted,
> > > > but maybe you can whittle down the number of places where you poke at
> > > > the host to make it reasonable: I can imagine that, if you are lucky and
> > > > the registers that i915 wants to poke to make it work on real hardware
> > > > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > > > bridge.  OTOH it would be much more likely if you just start with
> > > > something that does have MCH, like Q35, or emulate a newer
> > > > machine type.  This is the path that people who wanted
> > > > to boot iOS on QEMU took, and the result is pretty good.
> > > > 
> > > > But regardless, this is clearly not a i440fx nor a q35 pc
> > > > so it needs a separate name.
> > > > 
> > > 
> > 
> 

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 05:49:50PM +0100, Stefano Stabellini wrote:
> On Tue, 1 Jul 2014, Chen, Tiejun wrote:
> > On 2014/7/1 3:42, Stefano Stabellini wrote:
> > > On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> > > > On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > > > > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > > > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > > > > create an new machine to address this scenario? But actually this
> > > > > > > > is
> > > > > > > > same as xenfv_machine except for these little codes.
> > > > > > > 
> > > > > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > > > > these hacks.
> > > > > > 
> > > > > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > > > > pc_init_pci(), then inside, i440fx_init() is always performed. So I
> > > > > > think
> > > > > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > > > > 
> > > > > > > 
> > > > > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > > > > default).
> > > > > > > 
> > > > > > 
> > > > > > Yes, Xen can use 'pc'.
> > > > > > 
> > > > > > Thanks
> > > > > > Tiejun
> > > > > 
> > > > > You are creating a new machine type where the pci host
> > > > > looks like MCH but a bunch of other things are from i440fx.
> > > > 
> > > > Anthony,
> > > > 
> > > > Any comments to address this in xen case?
> > > 
> > > Having a separate machine for this is reasonable. You can select the
> > > right one from libxl anyway. From the name point of view I would go with
> > > "xenigd".
> > 
> > Do this mean we need to change something libxl?
> 
> Yes: you would need to pass a different -machine option, see
> tools/libxl/libxl_dm.c:libxl__build_device_model_args_new.
> It would be a pretty small change.
> 
> > > Just take a look at xenfv and introduce something similar but specific
> > > to your IGD PT use case.
> > > 
> > 
> > Which PCIe machine should I refer? i440fx or q35?
> 
> I'd say i440fx.

I have some doubts this can work cleanly, but if you want to attempt
this, be my guest.

So what you want is really franken-i440fx which has this fake isa bridge
and a mixed config from piix and mch.
The idea seems to be to make existing guests work, in light of this I
really don't see the point of pushing any guest changes.

So first step is just to implement these two, they should have nothing
to do with xen specifically, should work fine on all hosts, with tcg,kvm
etc. ISA bridge would just appearing as dummy device there.
Get flags as features for now.
Optionally, as an extra user-friendly feature, you can add a flag
that lets you poke at host and get device IDs etc from sysfs there.
Pls make this a separate patch though, and we'll discuss this
separately.

Same requirement would apply to q35 really - it's not
specific to i440fx.

Also please don't push more guest code upstream until qemu has something
merged or close to being merged.  You are just creating more messy
configurations that have to be supported.


> 
> > Thanks
> > Tiejun
> > 
> > > 
> > > > Thanks
> > > > Tiejun
> > > > 
> > > > > 
> > > > > I have some doubts about this combination being worth supporting - it
> > > > > does not seem useful for anything except xen from the code you posted,
> > > > > but maybe you can whittle down the number of places where you poke at
> > > > > the host to make it reasonable: I can imagine that, if you are lucky and
> > > > > the registers that i915 wants to poke to make it work on real hardware
> > > > > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > > > > bridge.  OTOH it would be much more likely if you just start with
> > > > > something that does have MCH, like Q35, or emulate a newer
> > > > > machine type.  This is the path that people who wanted
> > > > > to boot iOS on QEMU took, and the result is pretty good.
> > > > > 
> > > > > But regardless, this is clearly not a i440fx nor a q35 pc
> > > > > so it needs a separate name.
> > > > > 
> > > > 
> > > 
> > 

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 05:49:50PM +0100, Stefano Stabellini wrote:
> On Tue, 1 Jul 2014, Chen, Tiejun wrote:
> > On 2014/7/1 3:42, Stefano Stabellini wrote:
> > > On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> > > > On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > > > > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > > > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > > > > create an new machine to address this scenario? But actually this
> > > > > > > > is
> > > > > > > > same as xenfv_machine except for these little codes.
> > > > > > > 
> > > > > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > > > > these hacks.
> > > > > > 
> > > > > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > > > > pc_init_pci(), then inside, i440fx_init() is always performed. So I
> > > > > > think
> > > > > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > > > > 
> > > > > > > 
> > > > > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > > > > default).
> > > > > > > 
> > > > > > 
> > > > > > Yes, Xen can use 'pc'.
> > > > > > 
> > > > > > Thanks
> > > > > > Tiejun
> > > > > 
> > > > > You are creating a new machine type where the pci host
> > > > > looks like MCH but a bunch of other things are from i440fx.
> > > > 
> > > > Anthony,
> > > > 
> > > > Any comments to address this in xen case?
> > > 
> > > Having a separate machine for this is reasonable. You can select the
> > > right one from libxl anyway. From the name point of view I would go with
> > > "xenigd".
> > 
> > Do this mean we need to change something libxl?
> 
> Yes: you would need to pass a different -machine option, see
> tools/libxl/libxl_dm.c:libxl__build_device_model_args_new.
> It would be a pretty small change.
> 
> > > Just take a look at xenfv and introduce something similar but specific
> > > to your IGD PT use case.
> > > 
> > 
> > Which PCIe machine should I refer? i440fx or q35?
> 
> I'd say i440fx.

I have some doubts this can work cleanly, but if you want to attempt
this, be my guest.

So what you want is really franken-i440fx which has this fake isa bridge
and a mixed config from piix and mch.
The idea seems to be to make existing guests work, in light of this I
really don't see the point of pushing any guest changes.

So first step is just to implement these two, they should have nothing
to do with xen specifically, should work fine on all hosts, with tcg,kvm
etc. ISA bridge would just appearing as dummy device there.
Get flags as features for now.
Optionally, as an extra user-friendly feature, you can add a flag
that lets you poke at host and get device IDs etc from sysfs there.
Pls make this a separate patch though, and we'll discuss this
separately.

Same requirement would apply to q35 really - it's not
specific to i440fx.

Also please don't push more guest code upstream until qemu has something
merged or close to being merged.  You are just creating more messy
configurations that have to be supported.


> 
> > Thanks
> > Tiejun
> > 
> > > 
> > > > Thanks
> > > > Tiejun
> > > > 
> > > > > 
> > > > > I have some doubts about this combination being worth supporting - it
> > > > > does not seem useful for anything except xen from the code you posted,
> > > > > but maybe you can whittle down the number of places where you poke at
> > > > > the host to make it reasonable: I can imagine that, if you are lucky and
> > > > > the registers that i915 wants to poke to make it work on real hardware
> > > > > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > > > > bridge.  OTOH it would be much more likely if you just start with
> > > > > something that does have MCH, like Q35, or emulate a newer
> > > > > machine type.  This is the path that people who wanted
> > > > > to boot iOS on QEMU took, and the result is pretty good.
> > > > > 
> > > > > But regardless, this is clearly not a i440fx nor a q35 pc
> > > > > so it needs a separate name.
> > > > > 
> > > > 
> > > 
> > 

Re: [Qemu-devel] [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 09:34:14PM +0300, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 05:49:50PM +0100, Stefano Stabellini wrote:
> > On Tue, 1 Jul 2014, Chen, Tiejun wrote:
> > > On 2014/7/1 3:42, Stefano Stabellini wrote:
> > > > On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> > > > > On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > > > > > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > > > > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > > > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > > > > > create an new machine to address this scenario? But actually this
> > > > > > > > > is
> > > > > > > > > same as xenfv_machine except for these little codes.
> > > > > > > > 
> > > > > > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > > > > > these hacks.
> > > > > > > 
> > > > > > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > > > > > pc_init_pci(), then inside, i440fx_init() is always performed. So I
> > > > > > > think
> > > > > > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > > > > > 
> > > > > > > > 
> > > > > > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > > > > > default).
> > > > > > > > 
> > > > > > > 
> > > > > > > Yes, Xen can use 'pc'.
> > > > > > > 
> > > > > > > Thanks
> > > > > > > Tiejun
> > > > > > 
> > > > > > You are creating a new machine type where the pci host
> > > > > > looks like MCH but a bunch of other things are from i440fx.
> > > > > 
> > > > > Anthony,
> > > > > 
> > > > > Any comments to address this in xen case?
> > > > 
> > > > Having a separate machine for this is reasonable. You can select the
> > > > right one from libxl anyway. From the name point of view I would go with
> > > > "xenigd".
> > > 
> > > Do this mean we need to change something libxl?
> > 
> > Yes: you would need to pass a different -machine option, see
> > tools/libxl/libxl_dm.c:libxl__build_device_model_args_new.
> > It would be a pretty small change.
> > 
> > > > Just take a look at xenfv and introduce something similar but specific
> > > > to your IGD PT use case.
> > > > 
> > > 
> > > Which PCIe machine should I refer? i440fx or q35?
> > 
> > I'd say i440fx.
> 
> I have some doubts this can work cleanly, but if you want to attempt
> this, be my guest.
> 
> So what you want is really franken-i440fx which has this fake isa bridge
> and a mixed config from piix and mch.
> The idea seems to be to make existing guests work, in light of this I
> really don't see the point of pushing any guest changes.
> 
> So first step is just to implement these two, they should have nothing
> to do with xen specifically, should work fine on all hosts, with tcg,kvm
> etc. ISA bridge would just appearing as dummy device there.
> Get flags as features for now.
> Optionally, as an extra user-friendly feature, you can add a flag
> that lets you poke at host and get device IDs etc from sysfs there.
> Pls make this a separate patch though, and we'll discuss this
> separately.

Clarification: that's not a promise that it's mergeable if done that
way, we'll have to evaluate the registers that franken-piix overrides
and weight the chances that
1. guest will start poking at more registers in the future
	or
2. piix will want to use them in the future
leading to maintainance problems.

What I saw so far seems too fragile, I hope most of it isn't
actually required.

And this is why I was saying start with an MCH based chipset
instead.


> Same requirement would apply to q35 really - it's not
> specific to i440fx.
> 
> Also please don't push more guest code upstream until qemu has something
> merged or close to being merged.  You are just creating more messy
> configurations that have to be supported.
> 
> 
> > 
> > > Thanks
> > > Tiejun
> > > 
> > > > 
> > > > > Thanks
> > > > > Tiejun
> > > > > 
> > > > > > 
> > > > > > I have some doubts about this combination being worth supporting - it
> > > > > > does not seem useful for anything except xen from the code you posted,
> > > > > > but maybe you can whittle down the number of places where you poke at
> > > > > > the host to make it reasonable: I can imagine that, if you are lucky and
> > > > > > the registers that i915 wants to poke to make it work on real hardware
> > > > > > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > > > > > bridge.  OTOH it would be much more likely if you just start with
> > > > > > something that does have MCH, like Q35, or emulate a newer
> > > > > > machine type.  This is the path that people who wanted
> > > > > > to boot iOS on QEMU took, and the result is pretty good.
> > > > > > 
> > > > > > But regardless, this is clearly not a i440fx nor a q35 pc
> > > > > > so it needs a separate name.
> > > > > > 
> > > > > 
> > > > 
> > > 

Re: [v5][PATCH 4/5] xen, gfx passthrough: create host bridge to passthrough

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 09:34:14PM +0300, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 05:49:50PM +0100, Stefano Stabellini wrote:
> > On Tue, 1 Jul 2014, Chen, Tiejun wrote:
> > > On 2014/7/1 3:42, Stefano Stabellini wrote:
> > > > On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> > > > > On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > > > > > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > > > > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > > > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > > > > > create an new machine to address this scenario? But actually this
> > > > > > > > > is
> > > > > > > > > same as xenfv_machine except for these little codes.
> > > > > > > > 
> > > > > > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > > > > > these hacks.
> > > > > > > 
> > > > > > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > > > > > pc_init_pci(), then inside, i440fx_init() is always performed. So I
> > > > > > > think
> > > > > > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > > > > > 
> > > > > > > > 
> > > > > > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > > > > > default).
> > > > > > > > 
> > > > > > > 
> > > > > > > Yes, Xen can use 'pc'.
> > > > > > > 
> > > > > > > Thanks
> > > > > > > Tiejun
> > > > > > 
> > > > > > You are creating a new machine type where the pci host
> > > > > > looks like MCH but a bunch of other things are from i440fx.
> > > > > 
> > > > > Anthony,
> > > > > 
> > > > > Any comments to address this in xen case?
> > > > 
> > > > Having a separate machine for this is reasonable. You can select the
> > > > right one from libxl anyway. From the name point of view I would go with
> > > > "xenigd".
> > > 
> > > Do this mean we need to change something libxl?
> > 
> > Yes: you would need to pass a different -machine option, see
> > tools/libxl/libxl_dm.c:libxl__build_device_model_args_new.
> > It would be a pretty small change.
> > 
> > > > Just take a look at xenfv and introduce something similar but specific
> > > > to your IGD PT use case.
> > > > 
> > > 
> > > Which PCIe machine should I refer? i440fx or q35?
> > 
> > I'd say i440fx.
> 
> I have some doubts this can work cleanly, but if you want to attempt
> this, be my guest.
> 
> So what you want is really franken-i440fx which has this fake isa bridge
> and a mixed config from piix and mch.
> The idea seems to be to make existing guests work, in light of this I
> really don't see the point of pushing any guest changes.
> 
> So first step is just to implement these two, they should have nothing
> to do with xen specifically, should work fine on all hosts, with tcg,kvm
> etc. ISA bridge would just appearing as dummy device there.
> Get flags as features for now.
> Optionally, as an extra user-friendly feature, you can add a flag
> that lets you poke at host and get device IDs etc from sysfs there.
> Pls make this a separate patch though, and we'll discuss this
> separately.

Clarification: that's not a promise that it's mergeable if done that
way, we'll have to evaluate the registers that franken-piix overrides
and weight the chances that
1. guest will start poking at more registers in the future
	or
2. piix will want to use them in the future
leading to maintainance problems.

What I saw so far seems too fragile, I hope most of it isn't
actually required.

And this is why I was saying start with an MCH based chipset
instead.


> Same requirement would apply to q35 really - it's not
> specific to i440fx.
> 
> Also please don't push more guest code upstream until qemu has something
> merged or close to being merged.  You are just creating more messy
> configurations that have to be supported.
> 
> 
> > 
> > > Thanks
> > > Tiejun
> > > 
> > > > 
> > > > > Thanks
> > > > > Tiejun
> > > > > 
> > > > > > 
> > > > > > I have some doubts about this combination being worth supporting - it
> > > > > > does not seem useful for anything except xen from the code you posted,
> > > > > > but maybe you can whittle down the number of places where you poke at
> > > > > > the host to make it reasonable: I can imagine that, if you are lucky and
> > > > > > the registers that i915 wants to poke to make it work on real hardware
> > > > > > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > > > > > bridge.  OTOH it would be much more likely if you just start with
> > > > > > something that does have MCH, like Q35, or emulate a newer
> > > > > > machine type.  This is the path that people who wanted
> > > > > > to boot iOS on QEMU took, and the result is pretty good.
> > > > > > 
> > > > > > But regardless, this is clearly not a i440fx nor a q35 pc
> > > > > > so it needs a separate name.
> > > > > > 
> > > > > 
> > > > 
> > > 

[Qemu-devel] [v5][PATCH 5/5] xen, gfx passthrough: add opregion mapping

[Tiejun Chen]

The OpRegion shouldn't be mapped 1:1 because the address in the host
can't be used in the guest directly.

This patch traps read and write access to the opregion of the Intel
GPU config space (offset 0xfc).

The original patch is from Jean Guyader <jean.guyader@eu.citrix.com>

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Cc: Jean Guyader <jean.guyader@eu.citrix.com>
---
v5:

* Nothing is changed.

v4:

* Nothing is changed.

v3:

* Fix some typos.
* Add more comments to make that readable.
* To unmap igd_opregion when call xen_pt_unregister_vga_regions().
* Improve some return paths.
* We need to map 3 pages for opregion as hvmloader set. 
* Force to convert igd_guest/host_opoegion as an unsigned long type
  while calling xc_domain_memory_mapping().

v2:

* We should return zero as an invalid address value while calling
  igd_read_opregion().

 hw/xen/xen_pt.h             |  4 ++-
 hw/xen/xen_pt_config_init.c | 50 ++++++++++++++++++++++++++++++++++-
 hw/xen/xen_pt_graphics.c    | 64 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 116 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 507165c..25147cf 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read)
 #define XEN_PT_BAR_UNMAPPED (-1)
 
 #define PCI_CAP_MAX 48
-
+#define PCI_INTEL_OPREGION 0xfc
 
 typedef enum {
     XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
@@ -306,5 +306,7 @@ int pci_create_pch(PCIBus *bus);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
                    uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
+uint32_t igd_read_opregion(XenPCIPassthroughState *s);
+void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val);
 
 #endif /* !XEN_PT_H */
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index de9a20f..6eaaa9a 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -575,6 +575,22 @@ static int xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
     return 0;
 }
 
+static int xen_pt_intel_opregion_read(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry,
+                                      uint32_t *value, uint32_t valid_mask)
+{
+    *value = igd_read_opregion(s);
+    return 0;
+}
+
+static int xen_pt_intel_opregion_write(XenPCIPassthroughState *s,
+                                       XenPTReg *cfg_entry, uint32_t *value,
+                                       uint32_t dev_value, uint32_t valid_mask)
+{
+    igd_write_opregion(s, *value);
+    return 0;
+}
+
 /* Header Type0 reg static information table */
 static XenPTRegInfo xen_pt_emu_reg_header0[] = {
     /* Vendor ID reg */
@@ -1440,6 +1456,20 @@ static XenPTRegInfo xen_pt_emu_reg_msix[] = {
     },
 };
 
+static XenPTRegInfo xen_pt_emu_reg_igd_opregion[] = {
+    /* Intel IGFX OpRegion reg */
+    {
+        .offset     = 0x0,
+        .size       = 4,
+        .init_val   = 0,
+        .no_wb      = 1,
+        .u.dw.read   = xen_pt_intel_opregion_read,
+        .u.dw.write  = xen_pt_intel_opregion_write,
+    },
+    {
+        .size = 0,
+    },
+};
 
 /****************************
  * Capabilities
@@ -1677,6 +1707,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .size_init   = xen_pt_msix_size_init,
         .emu_regs = xen_pt_emu_reg_msix,
     },
+    /* Intel IGD Opregion group */
+    {
+        .grp_id      = PCI_INTEL_OPREGION,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x4,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs    = xen_pt_emu_reg_igd_opregion,
+    },
     {
         .grp_size = 0,
     },
@@ -1806,7 +1844,8 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
         uint32_t reg_grp_offset = 0;
         XenPTRegGroup *reg_grp_entry = NULL;
 
-        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) {
+        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF
+            && xen_pt_emu_reg_grps[i].grp_id != PCI_INTEL_OPREGION) {
             if (xen_pt_hide_dev_cap(&s->real_device,
                                     xen_pt_emu_reg_grps[i].grp_id)) {
                 continue;
@@ -1819,6 +1858,15 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
             }
         }
 
+        /*
+         * By default we will trap up to 0x40 in the cfg space.
+         * If an intel device is pass through we need to trap 0xfc,
+         * therefore the size should be 0xff.
+         */
+        if (xen_pt_emu_reg_grps[i].grp_id == PCI_INTEL_OPREGION) {
+            reg_grp_offset = PCI_INTEL_OPREGION;
+        }
+
         reg_grp_entry = g_new0(XenPTRegGroup, 1);
         QLIST_INIT(&reg_grp_entry->reg_tbl_list);
         QLIST_INSERT_HEAD(&s->reg_grps, reg_grp_entry, entries);
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index f3fbfed..fa341ad 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -6,6 +6,9 @@
 #include "hw/xen/xen_backend.h"
 #include "hw/pci/pci_bus.h"
 
+static unsigned long igd_guest_opregion;
+static unsigned long igd_host_opregion;
+
 static int is_vga_passthrough(XenHostPCIDevice *dev)
 {
     return (xen_has_gfx_passthru
@@ -88,6 +91,7 @@ int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
 int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
 {
     int i = 0;
+    int ret = 0;
 
     if (!is_vga_passthrough(dev)) {
         return 0;
@@ -114,6 +118,17 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
         }
     }
 
+    if (igd_guest_opregion) {
+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
+                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
+                3,
+                DPCI_REMOVE_MAPPING);
+        if (ret) {
+            return ret;
+        }
+    }
+
     return 0;
 }
 
@@ -447,3 +462,52 @@ err_out:
     XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
     return -1;
 }
+
+uint32_t igd_read_opregion(XenPCIPassthroughState *s)
+{
+    uint32_t val = 0;
+
+    if (igd_guest_opregion == 0) {
+        return val;
+    }
+
+    val = igd_guest_opregion;
+
+    XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
+    return val;
+}
+
+void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
+{
+    int ret;
+
+    if (igd_guest_opregion) {
+        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
+                   val);
+        return;
+    }
+
+    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
+            (uint8_t *)&igd_host_opregion, 4);
+    igd_guest_opregion = (unsigned long)(val & ~0xfff)
+                            | (igd_host_opregion & 0xfff);
+
+    ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+            (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
+            (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
+            3,
+            DPCI_ADD_MAPPING);
+
+    if (ret) {
+        XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host opregion:0x%lx to"
+                    " guest opregion:0x%lx.\n", ret,
+                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
+                    (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
+        igd_guest_opregion = 0;
+        return;
+    }
+
+    XEN_PT_LOG(&s->dev, "Map OpRegion: 0x%lx -> 0x%lx\n",
+                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
+                    (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
+}
-- 
1.9.1

[v5][PATCH 5/5] xen, gfx passthrough: add opregion mapping

[Tiejun Chen]

The OpRegion shouldn't be mapped 1:1 because the address in the host
can't be used in the guest directly.

This patch traps read and write access to the opregion of the Intel
GPU config space (offset 0xfc).

The original patch is from Jean Guyader <jean.guyader@eu.citrix.com>

Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
Cc: Jean Guyader <jean.guyader@eu.citrix.com>
---
v5:

* Nothing is changed.

v4:

* Nothing is changed.

v3:

* Fix some typos.
* Add more comments to make that readable.
* To unmap igd_opregion when call xen_pt_unregister_vga_regions().
* Improve some return paths.
* We need to map 3 pages for opregion as hvmloader set. 
* Force to convert igd_guest/host_opoegion as an unsigned long type
  while calling xc_domain_memory_mapping().

v2:

* We should return zero as an invalid address value while calling
  igd_read_opregion().

 hw/xen/xen_pt.h             |  4 ++-
 hw/xen/xen_pt_config_init.c | 50 ++++++++++++++++++++++++++++++++++-
 hw/xen/xen_pt_graphics.c    | 64 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 116 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 507165c..25147cf 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read)
 #define XEN_PT_BAR_UNMAPPED (-1)
 
 #define PCI_CAP_MAX 48
-
+#define PCI_INTEL_OPREGION 0xfc
 
 typedef enum {
     XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
@@ -306,5 +306,7 @@ int pci_create_pch(PCIBus *bus);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
                    uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
+uint32_t igd_read_opregion(XenPCIPassthroughState *s);
+void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val);
 
 #endif /* !XEN_PT_H */
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index de9a20f..6eaaa9a 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -575,6 +575,22 @@ static int xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
     return 0;
 }
 
+static int xen_pt_intel_opregion_read(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry,
+                                      uint32_t *value, uint32_t valid_mask)
+{
+    *value = igd_read_opregion(s);
+    return 0;
+}
+
+static int xen_pt_intel_opregion_write(XenPCIPassthroughState *s,
+                                       XenPTReg *cfg_entry, uint32_t *value,
+                                       uint32_t dev_value, uint32_t valid_mask)
+{
+    igd_write_opregion(s, *value);
+    return 0;
+}
+
 /* Header Type0 reg static information table */
 static XenPTRegInfo xen_pt_emu_reg_header0[] = {
     /* Vendor ID reg */
@@ -1440,6 +1456,20 @@ static XenPTRegInfo xen_pt_emu_reg_msix[] = {
     },
 };
 
+static XenPTRegInfo xen_pt_emu_reg_igd_opregion[] = {
+    /* Intel IGFX OpRegion reg */
+    {
+        .offset     = 0x0,
+        .size       = 4,
+        .init_val   = 0,
+        .no_wb      = 1,
+        .u.dw.read   = xen_pt_intel_opregion_read,
+        .u.dw.write  = xen_pt_intel_opregion_write,
+    },
+    {
+        .size = 0,
+    },
+};
 
 /****************************
  * Capabilities
@@ -1677,6 +1707,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
         .size_init   = xen_pt_msix_size_init,
         .emu_regs = xen_pt_emu_reg_msix,
     },
+    /* Intel IGD Opregion group */
+    {
+        .grp_id      = PCI_INTEL_OPREGION,
+        .grp_type    = XEN_PT_GRP_TYPE_EMU,
+        .grp_size    = 0x4,
+        .size_init   = xen_pt_reg_grp_size_init,
+        .emu_regs    = xen_pt_emu_reg_igd_opregion,
+    },
     {
         .grp_size = 0,
     },
@@ -1806,7 +1844,8 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
         uint32_t reg_grp_offset = 0;
         XenPTRegGroup *reg_grp_entry = NULL;
 
-        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) {
+        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF
+            && xen_pt_emu_reg_grps[i].grp_id != PCI_INTEL_OPREGION) {
             if (xen_pt_hide_dev_cap(&s->real_device,
                                     xen_pt_emu_reg_grps[i].grp_id)) {
                 continue;
@@ -1819,6 +1858,15 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
             }
         }
 
+        /*
+         * By default we will trap up to 0x40 in the cfg space.
+         * If an intel device is pass through we need to trap 0xfc,
+         * therefore the size should be 0xff.
+         */
+        if (xen_pt_emu_reg_grps[i].grp_id == PCI_INTEL_OPREGION) {
+            reg_grp_offset = PCI_INTEL_OPREGION;
+        }
+
         reg_grp_entry = g_new0(XenPTRegGroup, 1);
         QLIST_INIT(&reg_grp_entry->reg_tbl_list);
         QLIST_INSERT_HEAD(&s->reg_grps, reg_grp_entry, entries);
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index f3fbfed..fa341ad 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -6,6 +6,9 @@
 #include "hw/xen/xen_backend.h"
 #include "hw/pci/pci_bus.h"
 
+static unsigned long igd_guest_opregion;
+static unsigned long igd_host_opregion;
+
 static int is_vga_passthrough(XenHostPCIDevice *dev)
 {
     return (xen_has_gfx_passthru
@@ -88,6 +91,7 @@ int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
 int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
 {
     int i = 0;
+    int ret = 0;
 
     if (!is_vga_passthrough(dev)) {
         return 0;
@@ -114,6 +118,17 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
         }
     }
 
+    if (igd_guest_opregion) {
+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
+                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
+                3,
+                DPCI_REMOVE_MAPPING);
+        if (ret) {
+            return ret;
+        }
+    }
+
     return 0;
 }
 
@@ -447,3 +462,52 @@ err_out:
     XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
     return -1;
 }
+
+uint32_t igd_read_opregion(XenPCIPassthroughState *s)
+{
+    uint32_t val = 0;
+
+    if (igd_guest_opregion == 0) {
+        return val;
+    }
+
+    val = igd_guest_opregion;
+
+    XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
+    return val;
+}
+
+void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
+{
+    int ret;
+
+    if (igd_guest_opregion) {
+        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
+                   val);
+        return;
+    }
+
+    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
+            (uint8_t *)&igd_host_opregion, 4);
+    igd_guest_opregion = (unsigned long)(val & ~0xfff)
+                            | (igd_host_opregion & 0xfff);
+
+    ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+            (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
+            (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
+            3,
+            DPCI_ADD_MAPPING);
+
+    if (ret) {
+        XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host opregion:0x%lx to"
+                    " guest opregion:0x%lx.\n", ret,
+                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
+                    (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
+        igd_guest_opregion = 0;
+        return;
+    }
+
+    XEN_PT_LOG(&s->dev, "Map OpRegion: 0x%lx -> 0x%lx\n",
+                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
+                    (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
+}
-- 
1.9.1

Re: [Qemu-devel] [v5][PATCH 5/5] xen, gfx passthrough: add opregion mapping

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:17:21AM +0800, Tiejun Chen wrote:
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).
> 
> The original patch is from Jean Guyader <jean.guyader@eu.citrix.com>
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> Cc: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
> v5:
> 
> * Nothing is changed.
> 
> v4:
> 
> * Nothing is changed.
> 
> v3:
> 
> * Fix some typos.
> * Add more comments to make that readable.
> * To unmap igd_opregion when call xen_pt_unregister_vga_regions().
> * Improve some return paths.
> * We need to map 3 pages for opregion as hvmloader set. 
> * Force to convert igd_guest/host_opoegion as an unsigned long type
>   while calling xc_domain_memory_mapping().
> 
> v2:
> 
> * We should return zero as an invalid address value while calling
>   igd_read_opregion().
> 
>  hw/xen/xen_pt.h             |  4 ++-
>  hw/xen/xen_pt_config_init.c | 50 ++++++++++++++++++++++++++++++++++-
>  hw/xen/xen_pt_graphics.c    | 64 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 116 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 507165c..25147cf 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read)
>  #define XEN_PT_BAR_UNMAPPED (-1)
>  
>  #define PCI_CAP_MAX 48
> -
> +#define PCI_INTEL_OPREGION 0xfc
>  

XEN_.... please

PCI_CAP_MAX should be fixed too.


>  typedef enum {
>      XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
> @@ -306,5 +306,7 @@ int pci_create_pch(PCIBus *bus);
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
>                     uint32_t val, int len);
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +uint32_t igd_read_opregion(XenPCIPassthroughState *s);
> +void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val);
>  
>  #endif /* !XEN_PT_H */
> diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
> index de9a20f..6eaaa9a 100644
> --- a/hw/xen/xen_pt_config_init.c
> +++ b/hw/xen/xen_pt_config_init.c
> @@ -575,6 +575,22 @@ static int xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
>      return 0;
>  }
>  
> +static int xen_pt_intel_opregion_read(XenPCIPassthroughState *s,
> +                                      XenPTReg *cfg_entry,
> +                                      uint32_t *value, uint32_t valid_mask)
> +{
> +    *value = igd_read_opregion(s);
> +    return 0;
> +}
> +
> +static int xen_pt_intel_opregion_write(XenPCIPassthroughState *s,
> +                                       XenPTReg *cfg_entry, uint32_t *value,
> +                                       uint32_t dev_value, uint32_t valid_mask)
> +{
> +    igd_write_opregion(s, *value);
> +    return 0;
> +}
> +
>  /* Header Type0 reg static information table */
>  static XenPTRegInfo xen_pt_emu_reg_header0[] = {
>      /* Vendor ID reg */
> @@ -1440,6 +1456,20 @@ static XenPTRegInfo xen_pt_emu_reg_msix[] = {
>      },
>  };
>  
> +static XenPTRegInfo xen_pt_emu_reg_igd_opregion[] = {
> +    /* Intel IGFX OpRegion reg */
> +    {
> +        .offset     = 0x0,
> +        .size       = 4,
> +        .init_val   = 0,
> +        .no_wb      = 1,
> +        .u.dw.read   = xen_pt_intel_opregion_read,
> +        .u.dw.write  = xen_pt_intel_opregion_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
>  
>  /****************************
>   * Capabilities
> @@ -1677,6 +1707,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
>          .size_init   = xen_pt_msix_size_init,
>          .emu_regs = xen_pt_emu_reg_msix,
>      },
> +    /* Intel IGD Opregion group */
> +    {
> +        .grp_id      = PCI_INTEL_OPREGION,
> +        .grp_type    = XEN_PT_GRP_TYPE_EMU,
> +        .grp_size    = 0x4,
> +        .size_init   = xen_pt_reg_grp_size_init,
> +        .emu_regs    = xen_pt_emu_reg_igd_opregion,
> +    },
>      {
>          .grp_size = 0,
>      },
> @@ -1806,7 +1844,8 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
>          uint32_t reg_grp_offset = 0;
>          XenPTRegGroup *reg_grp_entry = NULL;
>  
> -        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) {
> +        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF
> +            && xen_pt_emu_reg_grps[i].grp_id != PCI_INTEL_OPREGION) {
>              if (xen_pt_hide_dev_cap(&s->real_device,
>                                      xen_pt_emu_reg_grps[i].grp_id)) {
>                  continue;
> @@ -1819,6 +1858,15 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
>              }
>          }
>  
> +        /*
> +         * By default we will trap up to 0x40 in the cfg space.
> +         * If an intel device is pass through we need to trap 0xfc,
> +         * therefore the size should be 0xff.
> +         */
> +        if (xen_pt_emu_reg_grps[i].grp_id == PCI_INTEL_OPREGION) {
> +            reg_grp_offset = PCI_INTEL_OPREGION;
> +        }
> +
>          reg_grp_entry = g_new0(XenPTRegGroup, 1);
>          QLIST_INIT(&reg_grp_entry->reg_tbl_list);
>          QLIST_INSERT_HEAD(&s->reg_grps, reg_grp_entry, entries);
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> index f3fbfed..fa341ad 100644
> --- a/hw/xen/xen_pt_graphics.c
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -6,6 +6,9 @@
>  #include "hw/xen/xen_backend.h"
>  #include "hw/pci/pci_bus.h"
>  
> +static unsigned long igd_guest_opregion;
> +static unsigned long igd_host_opregion;
> +
>  static int is_vga_passthrough(XenHostPCIDevice *dev)
>  {
>      return (xen_has_gfx_passthru
> @@ -88,6 +91,7 @@ int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
>  int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
>  {
>      int i = 0;
> +    int ret = 0;
>  
>      if (!is_vga_passthrough(dev)) {
>          return 0;
> @@ -114,6 +118,17 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
>          }
>      }
>  
> +    if (igd_guest_opregion) {
> +        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
> +                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),

don't spread casts all around.
Should be a last resort.

> +                3,
> +                DPCI_REMOVE_MAPPING);
> +        if (ret) {
> +            return ret;
> +        }
> +    }
> +
>      return 0;
>  }
>  
> @@ -447,3 +462,52 @@ err_out:
>      XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
>      return -1;
>  }
> +
> +uint32_t igd_read_opregion(XenPCIPassthroughState *s)
> +{
> +    uint32_t val = 0;
> +
> +    if (igd_guest_opregion == 0) {

!igd_guest_opregion is shorter and does the same,

> +        return val;
> +    }
> +
> +    val = igd_guest_opregion;
> +
> +    XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
> +    return val;
> +}
> +
> +void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
> +{
> +    int ret;
> +
> +    if (igd_guest_opregion) {
> +        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
> +                   val);
> +        return;
> +    }
> +
> +    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
> +            (uint8_t *)&igd_host_opregion, 4);
> +    igd_guest_opregion = (unsigned long)(val & ~0xfff)
> +                            | (igd_host_opregion & 0xfff);
> +

Clearly broken on BE.
Maybe not important here but writing clean code is
just as easy.
uint8_t igd_host_opregion[4];

...

    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
			   igd_host_opregion, sizeof igd_host_opregion);

    igd_guest_opregion = (val & ~0xfff) |
	    (pci_get_word(igd_host_opregion) & 0xfff);

0xfff should be a macro too to avoid duplication.


> +    ret = xc_domain_memory_mapping(xen_xc, xen_domid,
> +            (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
> +            (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
> +            3,
> +            DPCI_ADD_MAPPING);
> +
> +    if (ret) {
> +        XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host opregion:0x%lx to"
> +                    " guest opregion:0x%lx.\n", ret,
> +                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
> +                    (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
> +        igd_guest_opregion = 0;
> +        return;
> +    }
> +
> +    XEN_PT_LOG(&s->dev, "Map OpRegion: 0x%lx -> 0x%lx\n",
> +                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
> +                    (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
> +}
> -- 
> 1.9.1

Re: [v5][PATCH 5/5] xen, gfx passthrough: add opregion mapping

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:17:21AM +0800, Tiejun Chen wrote:
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).
> 
> The original patch is from Jean Guyader <jean.guyader@eu.citrix.com>
> 
> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> Cc: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
> v5:
> 
> * Nothing is changed.
> 
> v4:
> 
> * Nothing is changed.
> 
> v3:
> 
> * Fix some typos.
> * Add more comments to make that readable.
> * To unmap igd_opregion when call xen_pt_unregister_vga_regions().
> * Improve some return paths.
> * We need to map 3 pages for opregion as hvmloader set. 
> * Force to convert igd_guest/host_opoegion as an unsigned long type
>   while calling xc_domain_memory_mapping().
> 
> v2:
> 
> * We should return zero as an invalid address value while calling
>   igd_read_opregion().
> 
>  hw/xen/xen_pt.h             |  4 ++-
>  hw/xen/xen_pt_config_init.c | 50 ++++++++++++++++++++++++++++++++++-
>  hw/xen/xen_pt_graphics.c    | 64 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 116 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 507165c..25147cf 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read)
>  #define XEN_PT_BAR_UNMAPPED (-1)
>  
>  #define PCI_CAP_MAX 48
> -
> +#define PCI_INTEL_OPREGION 0xfc
>  

XEN_.... please

PCI_CAP_MAX should be fixed too.


>  typedef enum {
>      XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
> @@ -306,5 +306,7 @@ int pci_create_pch(PCIBus *bus);
>  void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr,
>                     uint32_t val, int len);
>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
> +uint32_t igd_read_opregion(XenPCIPassthroughState *s);
> +void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val);
>  
>  #endif /* !XEN_PT_H */
> diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
> index de9a20f..6eaaa9a 100644
> --- a/hw/xen/xen_pt_config_init.c
> +++ b/hw/xen/xen_pt_config_init.c
> @@ -575,6 +575,22 @@ static int xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
>      return 0;
>  }
>  
> +static int xen_pt_intel_opregion_read(XenPCIPassthroughState *s,
> +                                      XenPTReg *cfg_entry,
> +                                      uint32_t *value, uint32_t valid_mask)
> +{
> +    *value = igd_read_opregion(s);
> +    return 0;
> +}
> +
> +static int xen_pt_intel_opregion_write(XenPCIPassthroughState *s,
> +                                       XenPTReg *cfg_entry, uint32_t *value,
> +                                       uint32_t dev_value, uint32_t valid_mask)
> +{
> +    igd_write_opregion(s, *value);
> +    return 0;
> +}
> +
>  /* Header Type0 reg static information table */
>  static XenPTRegInfo xen_pt_emu_reg_header0[] = {
>      /* Vendor ID reg */
> @@ -1440,6 +1456,20 @@ static XenPTRegInfo xen_pt_emu_reg_msix[] = {
>      },
>  };
>  
> +static XenPTRegInfo xen_pt_emu_reg_igd_opregion[] = {
> +    /* Intel IGFX OpRegion reg */
> +    {
> +        .offset     = 0x0,
> +        .size       = 4,
> +        .init_val   = 0,
> +        .no_wb      = 1,
> +        .u.dw.read   = xen_pt_intel_opregion_read,
> +        .u.dw.write  = xen_pt_intel_opregion_write,
> +    },
> +    {
> +        .size = 0,
> +    },
> +};
>  
>  /****************************
>   * Capabilities
> @@ -1677,6 +1707,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
>          .size_init   = xen_pt_msix_size_init,
>          .emu_regs = xen_pt_emu_reg_msix,
>      },
> +    /* Intel IGD Opregion group */
> +    {
> +        .grp_id      = PCI_INTEL_OPREGION,
> +        .grp_type    = XEN_PT_GRP_TYPE_EMU,
> +        .grp_size    = 0x4,
> +        .size_init   = xen_pt_reg_grp_size_init,
> +        .emu_regs    = xen_pt_emu_reg_igd_opregion,
> +    },
>      {
>          .grp_size = 0,
>      },
> @@ -1806,7 +1844,8 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
>          uint32_t reg_grp_offset = 0;
>          XenPTRegGroup *reg_grp_entry = NULL;
>  
> -        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) {
> +        if (xen_pt_emu_reg_grps[i].grp_id != 0xFF
> +            && xen_pt_emu_reg_grps[i].grp_id != PCI_INTEL_OPREGION) {
>              if (xen_pt_hide_dev_cap(&s->real_device,
>                                      xen_pt_emu_reg_grps[i].grp_id)) {
>                  continue;
> @@ -1819,6 +1858,15 @@ int xen_pt_config_init(XenPCIPassthroughState *s)
>              }
>          }
>  
> +        /*
> +         * By default we will trap up to 0x40 in the cfg space.
> +         * If an intel device is pass through we need to trap 0xfc,
> +         * therefore the size should be 0xff.
> +         */
> +        if (xen_pt_emu_reg_grps[i].grp_id == PCI_INTEL_OPREGION) {
> +            reg_grp_offset = PCI_INTEL_OPREGION;
> +        }
> +
>          reg_grp_entry = g_new0(XenPTRegGroup, 1);
>          QLIST_INIT(&reg_grp_entry->reg_tbl_list);
>          QLIST_INSERT_HEAD(&s->reg_grps, reg_grp_entry, entries);
> diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
> index f3fbfed..fa341ad 100644
> --- a/hw/xen/xen_pt_graphics.c
> +++ b/hw/xen/xen_pt_graphics.c
> @@ -6,6 +6,9 @@
>  #include "hw/xen/xen_backend.h"
>  #include "hw/pci/pci_bus.h"
>  
> +static unsigned long igd_guest_opregion;
> +static unsigned long igd_host_opregion;
> +
>  static int is_vga_passthrough(XenHostPCIDevice *dev)
>  {
>      return (xen_has_gfx_passthru
> @@ -88,6 +91,7 @@ int xen_pt_register_vga_regions(XenHostPCIDevice *dev)
>  int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
>  {
>      int i = 0;
> +    int ret = 0;
>  
>      if (!is_vga_passthrough(dev)) {
>          return 0;
> @@ -114,6 +118,17 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
>          }
>      }
>  
> +    if (igd_guest_opregion) {
> +        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
> +                (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
> +                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),

don't spread casts all around.
Should be a last resort.

> +                3,
> +                DPCI_REMOVE_MAPPING);
> +        if (ret) {
> +            return ret;
> +        }
> +    }
> +
>      return 0;
>  }
>  
> @@ -447,3 +462,52 @@ err_out:
>      XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
>      return -1;
>  }
> +
> +uint32_t igd_read_opregion(XenPCIPassthroughState *s)
> +{
> +    uint32_t val = 0;
> +
> +    if (igd_guest_opregion == 0) {

!igd_guest_opregion is shorter and does the same,

> +        return val;
> +    }
> +
> +    val = igd_guest_opregion;
> +
> +    XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
> +    return val;
> +}
> +
> +void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
> +{
> +    int ret;
> +
> +    if (igd_guest_opregion) {
> +        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
> +                   val);
> +        return;
> +    }
> +
> +    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
> +            (uint8_t *)&igd_host_opregion, 4);
> +    igd_guest_opregion = (unsigned long)(val & ~0xfff)
> +                            | (igd_host_opregion & 0xfff);
> +

Clearly broken on BE.
Maybe not important here but writing clean code is
just as easy.
uint8_t igd_host_opregion[4];

...

    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
			   igd_host_opregion, sizeof igd_host_opregion);

    igd_guest_opregion = (val & ~0xfff) |
	    (pci_get_word(igd_host_opregion) & 0xfff);

0xfff should be a macro too to avoid duplication.


> +    ret = xc_domain_memory_mapping(xen_xc, xen_domid,
> +            (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
> +            (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
> +            3,
> +            DPCI_ADD_MAPPING);
> +
> +    if (ret) {
> +        XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host opregion:0x%lx to"
> +                    " guest opregion:0x%lx.\n", ret,
> +                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
> +                    (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
> +        igd_guest_opregion = 0;
> +        return;
> +    }
> +
> +    XEN_PT_LOG(&s->dev, "Map OpRegion: 0x%lx -> 0x%lx\n",
> +                    (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
> +                    (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
> +}
> -- 
> 1.9.1

Re: [Qemu-devel] [v5][PATCH 5/5] xen, gfx passthrough: add opregion mapping

[Chen, Tiejun]

On 2014/6/25 15:13, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:17:21AM +0800, Tiejun Chen wrote:

[snip]

>> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
>> index 507165c..25147cf 100644
>> --- a/hw/xen/xen_pt.h
>> +++ b/hw/xen/xen_pt.h
>> @@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read)
>>   #define XEN_PT_BAR_UNMAPPED (-1)
>>
>>   #define PCI_CAP_MAX 48
>> -
>> +#define PCI_INTEL_OPREGION 0xfc
>>
>
> XEN_.... please
>
> PCI_CAP_MAX should be fixed too.

They are specific to PCI, not XEN. Why should we add such a prefix?

>
>

[snip]

>>
>> +    if (igd_guest_opregion) {
>> +        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>> +                (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>> +                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>
> don't spread casts all around.
> Should be a last resort.

Okay.

>
>> +                3,
>> +                DPCI_REMOVE_MAPPING);
>> +        if (ret) {
>> +            return ret;
>> +        }
>> +    }
>> +
>>       return 0;
>>   }
>>
>> @@ -447,3 +462,52 @@ err_out:
>>       XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
>>       return -1;
>>   }
>> +
>> +uint32_t igd_read_opregion(XenPCIPassthroughState *s)
>> +{
>> +    uint32_t val = 0;
>> +
>> +    if (igd_guest_opregion == 0) {
>
> !igd_guest_opregion is shorter and does the same,

Okay.

>
>> +        return val;
>> +    }
>> +
>> +    val = igd_guest_opregion;
>> +
>> +    XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
>> +    return val;
>> +}
>> +
>> +void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
>> +{
>> +    int ret;
>> +
>> +    if (igd_guest_opregion) {
>> +        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
>> +                   val);
>> +        return;
>> +    }
>> +
>> +    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
>> +            (uint8_t *)&igd_host_opregion, 4);
>> +    igd_guest_opregion = (unsigned long)(val & ~0xfff)
>> +                            | (igd_host_opregion & 0xfff);
>> +
>
> Clearly broken on BE.

I still can't understand why we need to address this in BE case.

> Maybe not important here but writing clean code is
> just as easy.
> uint8_t igd_host_opregion[4];
>
> ...
>
>      xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
> 			   igd_host_opregion, sizeof igd_host_opregion);
>
>      igd_guest_opregion = (val & ~0xfff) |
> 	    (pci_get_word(igd_host_opregion) & 0xfff);
>
> 0xfff should be a macro too to avoid duplication.
>

Okay.

Thanks
Tiejun

Re: [v5][PATCH 5/5] xen, gfx passthrough: add opregion mapping

[Chen, Tiejun]

On 2014/6/25 15:13, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:17:21AM +0800, Tiejun Chen wrote:

[snip]

>> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
>> index 507165c..25147cf 100644
>> --- a/hw/xen/xen_pt.h
>> +++ b/hw/xen/xen_pt.h
>> @@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read)
>>   #define XEN_PT_BAR_UNMAPPED (-1)
>>
>>   #define PCI_CAP_MAX 48
>> -
>> +#define PCI_INTEL_OPREGION 0xfc
>>
>
> XEN_.... please
>
> PCI_CAP_MAX should be fixed too.

They are specific to PCI, not XEN. Why should we add such a prefix?

>
>

[snip]

>>
>> +    if (igd_guest_opregion) {
>> +        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>> +                (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>> +                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>
> don't spread casts all around.
> Should be a last resort.

Okay.

>
>> +                3,
>> +                DPCI_REMOVE_MAPPING);
>> +        if (ret) {
>> +            return ret;
>> +        }
>> +    }
>> +
>>       return 0;
>>   }
>>
>> @@ -447,3 +462,52 @@ err_out:
>>       XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
>>       return -1;
>>   }
>> +
>> +uint32_t igd_read_opregion(XenPCIPassthroughState *s)
>> +{
>> +    uint32_t val = 0;
>> +
>> +    if (igd_guest_opregion == 0) {
>
> !igd_guest_opregion is shorter and does the same,

Okay.

>
>> +        return val;
>> +    }
>> +
>> +    val = igd_guest_opregion;
>> +
>> +    XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
>> +    return val;
>> +}
>> +
>> +void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
>> +{
>> +    int ret;
>> +
>> +    if (igd_guest_opregion) {
>> +        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
>> +                   val);
>> +        return;
>> +    }
>> +
>> +    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
>> +            (uint8_t *)&igd_host_opregion, 4);
>> +    igd_guest_opregion = (unsigned long)(val & ~0xfff)
>> +                            | (igd_host_opregion & 0xfff);
>> +
>
> Clearly broken on BE.

I still can't understand why we need to address this in BE case.

> Maybe not important here but writing clean code is
> just as easy.
> uint8_t igd_host_opregion[4];
>
> ...
>
>      xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
> 			   igd_host_opregion, sizeof igd_host_opregion);
>
>      igd_guest_opregion = (val & ~0xfff) |
> 	    (pci_get_word(igd_host_opregion) & 0xfff);
>
> 0xfff should be a macro too to avoid duplication.
>

Okay.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 5/5] xen, gfx passthrough: add opregion mapping

[Michael S. Tsirkin]

On Fri, Jun 27, 2014 at 05:22:18PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 15:13, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:17:21AM +0800, Tiejun Chen wrote:
> 
> [snip]
> 
> >>diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> >>index 507165c..25147cf 100644
> >>--- a/hw/xen/xen_pt.h
> >>+++ b/hw/xen/xen_pt.h
> >>@@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read)
> >>  #define XEN_PT_BAR_UNMAPPED (-1)
> >>
> >>  #define PCI_CAP_MAX 48
> >>-
> >>+#define PCI_INTEL_OPREGION 0xfc
> >>
> >
> >XEN_.... please
> >
> >PCI_CAP_MAX should be fixed too.
> 
> They are specific to PCI, not XEN.

They are?  Where in the PCI spec does it say 48?
Same for PCI_INTEL_OPREGION.

> Why should we add such a prefix?

So that people working on core pci do not have to worry about breaking
your devices by adding a symbol in the global header.


> >
> >
> 
> [snip]
> 
> >>
> >>+    if (igd_guest_opregion) {
> >>+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
> >>+                (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
> >>+                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
> >
> >don't spread casts all around.
> >Should be a last resort.
> 
> Okay.
> 
> >
> >>+                3,
> >>+                DPCI_REMOVE_MAPPING);
> >>+        if (ret) {
> >>+            return ret;
> >>+        }
> >>+    }
> >>+
> >>      return 0;
> >>  }
> >>
> >>@@ -447,3 +462,52 @@ err_out:
> >>      XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> >>      return -1;
> >>  }
> >>+
> >>+uint32_t igd_read_opregion(XenPCIPassthroughState *s)
> >>+{
> >>+    uint32_t val = 0;
> >>+
> >>+    if (igd_guest_opregion == 0) {
> >
> >!igd_guest_opregion is shorter and does the same,
> 
> Okay.
> 
> >
> >>+        return val;
> >>+    }
> >>+
> >>+    val = igd_guest_opregion;
> >>+
> >>+    XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
> >>+    return val;
> >>+}
> >>+
> >>+void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
> >>+{
> >>+    int ret;
> >>+
> >>+    if (igd_guest_opregion) {
> >>+        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
> >>+                   val);
> >>+        return;
> >>+    }
> >>+
> >>+    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
> >>+            (uint8_t *)&igd_host_opregion, 4);
> >>+    igd_guest_opregion = (unsigned long)(val & ~0xfff)
> >>+                            | (igd_host_opregion & 0xfff);
> >>+
> >
> >Clearly broken on BE.
> 
> I still can't understand why we need to address this in BE case.

So code is clean and reusable. Copy and paste is a fact of life,
you don't want people to inherit bugs.
If some code absolutely must be LE specific,
it needs a comment that explains this and cautions
people against trying to use it elsewhere in QEMU.


> >Maybe not important here but writing clean code is
> >just as easy.
> >uint8_t igd_host_opregion[4];
> >
> >...
> >
> >     xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
> >			   igd_host_opregion, sizeof igd_host_opregion);
> >
> >     igd_guest_opregion = (val & ~0xfff) |
> >	    (pci_get_word(igd_host_opregion) & 0xfff);
> >
> >0xfff should be a macro too to avoid duplication.
> >
> 
> Okay.
> 
> Thanks
> Tiejun

Re: [v5][PATCH 5/5] xen, gfx passthrough: add opregion mapping

[Michael S. Tsirkin]

On Fri, Jun 27, 2014 at 05:22:18PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 15:13, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:17:21AM +0800, Tiejun Chen wrote:
> 
> [snip]
> 
> >>diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> >>index 507165c..25147cf 100644
> >>--- a/hw/xen/xen_pt.h
> >>+++ b/hw/xen/xen_pt.h
> >>@@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read)
> >>  #define XEN_PT_BAR_UNMAPPED (-1)
> >>
> >>  #define PCI_CAP_MAX 48
> >>-
> >>+#define PCI_INTEL_OPREGION 0xfc
> >>
> >
> >XEN_.... please
> >
> >PCI_CAP_MAX should be fixed too.
> 
> They are specific to PCI, not XEN.

They are?  Where in the PCI spec does it say 48?
Same for PCI_INTEL_OPREGION.

> Why should we add such a prefix?

So that people working on core pci do not have to worry about breaking
your devices by adding a symbol in the global header.


> >
> >
> 
> [snip]
> 
> >>
> >>+    if (igd_guest_opregion) {
> >>+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
> >>+                (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
> >>+                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
> >
> >don't spread casts all around.
> >Should be a last resort.
> 
> Okay.
> 
> >
> >>+                3,
> >>+                DPCI_REMOVE_MAPPING);
> >>+        if (ret) {
> >>+            return ret;
> >>+        }
> >>+    }
> >>+
> >>      return 0;
> >>  }
> >>
> >>@@ -447,3 +462,52 @@ err_out:
> >>      XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
> >>      return -1;
> >>  }
> >>+
> >>+uint32_t igd_read_opregion(XenPCIPassthroughState *s)
> >>+{
> >>+    uint32_t val = 0;
> >>+
> >>+    if (igd_guest_opregion == 0) {
> >
> >!igd_guest_opregion is shorter and does the same,
> 
> Okay.
> 
> >
> >>+        return val;
> >>+    }
> >>+
> >>+    val = igd_guest_opregion;
> >>+
> >>+    XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
> >>+    return val;
> >>+}
> >>+
> >>+void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
> >>+{
> >>+    int ret;
> >>+
> >>+    if (igd_guest_opregion) {
> >>+        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
> >>+                   val);
> >>+        return;
> >>+    }
> >>+
> >>+    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
> >>+            (uint8_t *)&igd_host_opregion, 4);
> >>+    igd_guest_opregion = (unsigned long)(val & ~0xfff)
> >>+                            | (igd_host_opregion & 0xfff);
> >>+
> >
> >Clearly broken on BE.
> 
> I still can't understand why we need to address this in BE case.

So code is clean and reusable. Copy and paste is a fact of life,
you don't want people to inherit bugs.
If some code absolutely must be LE specific,
it needs a comment that explains this and cautions
people against trying to use it elsewhere in QEMU.


> >Maybe not important here but writing clean code is
> >just as easy.
> >uint8_t igd_host_opregion[4];
> >
> >...
> >
> >     xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
> >			   igd_host_opregion, sizeof igd_host_opregion);
> >
> >     igd_guest_opregion = (val & ~0xfff) |
> >	    (pci_get_word(igd_host_opregion) & 0xfff);
> >
> >0xfff should be a macro too to avoid duplication.
> >
> 
> Okay.
> 
> Thanks
> Tiejun

Re: [Qemu-devel] [v5][PATCH 5/5] xen, gfx passthrough: add opregion mapping

[Chen, Tiejun]

On 2014/6/29 19:43, Michael S. Tsirkin wrote:
> On Fri, Jun 27, 2014 at 05:22:18PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 15:13, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 10:17:21AM +0800, Tiejun Chen wrote:
>>
>> [snip]
>>
>>>> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
>>>> index 507165c..25147cf 100644
>>>> --- a/hw/xen/xen_pt.h
>>>> +++ b/hw/xen/xen_pt.h
>>>> @@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read)
>>>>   #define XEN_PT_BAR_UNMAPPED (-1)
>>>>
>>>>   #define PCI_CAP_MAX 48
>>>> -
>>>> +#define PCI_INTEL_OPREGION 0xfc
>>>>
>>>
>>> XEN_.... please
>>>
>>> PCI_CAP_MAX should be fixed too.
>>
>> They are specific to PCI, not XEN.
>
> They are?  Where in the PCI spec does it say 48?
> Same for PCI_INTEL_OPREGION.
>
>> Why should we add such a prefix?
>
> So that people working on core pci do not have to worry about breaking
> your devices by adding a symbol in the global header.

Okay.

>
>
>>>
>>>
>>
>> [snip]
>>
>>>>
>>>> +    if (igd_guest_opregion) {
>>>> +        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>> +                (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>> +                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>
>>> don't spread casts all around.
>>> Should be a last resort.
>>
>> Okay.
>>
>>>
>>>> +                3,
>>>> +                DPCI_REMOVE_MAPPING);
>>>> +        if (ret) {
>>>> +            return ret;
>>>> +        }
>>>> +    }
>>>> +
>>>>       return 0;
>>>>   }
>>>>
>>>> @@ -447,3 +462,52 @@ err_out:
>>>>       XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
>>>>       return -1;
>>>>   }
>>>> +
>>>> +uint32_t igd_read_opregion(XenPCIPassthroughState *s)
>>>> +{
>>>> +    uint32_t val = 0;
>>>> +
>>>> +    if (igd_guest_opregion == 0) {
>>>
>>> !igd_guest_opregion is shorter and does the same,
>>
>> Okay.
>>
>>>
>>>> +        return val;
>>>> +    }
>>>> +
>>>> +    val = igd_guest_opregion;
>>>> +
>>>> +    XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
>>>> +    return val;
>>>> +}
>>>> +
>>>> +void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
>>>> +{
>>>> +    int ret;
>>>> +
>>>> +    if (igd_guest_opregion) {
>>>> +        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
>>>> +                   val);
>>>> +        return;
>>>> +    }
>>>> +
>>>> +    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
>>>> +            (uint8_t *)&igd_host_opregion, 4);
>>>> +    igd_guest_opregion = (unsigned long)(val & ~0xfff)
>>>> +                            | (igd_host_opregion & 0xfff);
>>>> +
>>>
>>> Clearly broken on BE.
>>
>> I still can't understand why we need to address this in BE case.
>
> So code is clean and reusable. Copy and paste is a fact of life,
> you don't want people to inherit bugs.

Understood.

> If some code absolutely must be LE specific,
> it needs a comment that explains this and cautions
> people against trying to use it elsewhere in QEMU.

I think its fine enough to add a comment.

Thanks
Tiejun

>
>
>>> Maybe not important here but writing clean code is
>>> just as easy.
>>> uint8_t igd_host_opregion[4];
>>>
>>> ...
>>>
>>>      xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
>>> 			   igd_host_opregion, sizeof igd_host_opregion);
>>>
>>>      igd_guest_opregion = (val & ~0xfff) |
>>> 	    (pci_get_word(igd_host_opregion) & 0xfff);
>>>
>>> 0xfff should be a macro too to avoid duplication.
>>>
>>
>> Okay.
>>
>> Thanks
>> Tiejun
>

Re: [v5][PATCH 5/5] xen, gfx passthrough: add opregion mapping

[Chen, Tiejun]

On 2014/6/29 19:43, Michael S. Tsirkin wrote:
> On Fri, Jun 27, 2014 at 05:22:18PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 15:13, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 10:17:21AM +0800, Tiejun Chen wrote:
>>
>> [snip]
>>
>>>> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
>>>> index 507165c..25147cf 100644
>>>> --- a/hw/xen/xen_pt.h
>>>> +++ b/hw/xen/xen_pt.h
>>>> @@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read)
>>>>   #define XEN_PT_BAR_UNMAPPED (-1)
>>>>
>>>>   #define PCI_CAP_MAX 48
>>>> -
>>>> +#define PCI_INTEL_OPREGION 0xfc
>>>>
>>>
>>> XEN_.... please
>>>
>>> PCI_CAP_MAX should be fixed too.
>>
>> They are specific to PCI, not XEN.
>
> They are?  Where in the PCI spec does it say 48?
> Same for PCI_INTEL_OPREGION.
>
>> Why should we add such a prefix?
>
> So that people working on core pci do not have to worry about breaking
> your devices by adding a symbol in the global header.

Okay.

>
>
>>>
>>>
>>
>> [snip]
>>
>>>>
>>>> +    if (igd_guest_opregion) {
>>>> +        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>>>> +                (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>>>> +                (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>>>
>>> don't spread casts all around.
>>> Should be a last resort.
>>
>> Okay.
>>
>>>
>>>> +                3,
>>>> +                DPCI_REMOVE_MAPPING);
>>>> +        if (ret) {
>>>> +            return ret;
>>>> +        }
>>>> +    }
>>>> +
>>>>       return 0;
>>>>   }
>>>>
>>>> @@ -447,3 +462,52 @@ err_out:
>>>>       XEN_PT_ERR(pci_dev, "Can't get pci_dev_host_bridge\n");
>>>>       return -1;
>>>>   }
>>>> +
>>>> +uint32_t igd_read_opregion(XenPCIPassthroughState *s)
>>>> +{
>>>> +    uint32_t val = 0;
>>>> +
>>>> +    if (igd_guest_opregion == 0) {
>>>
>>> !igd_guest_opregion is shorter and does the same,
>>
>> Okay.
>>
>>>
>>>> +        return val;
>>>> +    }
>>>> +
>>>> +    val = igd_guest_opregion;
>>>> +
>>>> +    XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
>>>> +    return val;
>>>> +}
>>>> +
>>>> +void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
>>>> +{
>>>> +    int ret;
>>>> +
>>>> +    if (igd_guest_opregion) {
>>>> +        XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
>>>> +                   val);
>>>> +        return;
>>>> +    }
>>>> +
>>>> +    xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
>>>> +            (uint8_t *)&igd_host_opregion, 4);
>>>> +    igd_guest_opregion = (unsigned long)(val & ~0xfff)
>>>> +                            | (igd_host_opregion & 0xfff);
>>>> +
>>>
>>> Clearly broken on BE.
>>
>> I still can't understand why we need to address this in BE case.
>
> So code is clean and reusable. Copy and paste is a fact of life,
> you don't want people to inherit bugs.

Understood.

> If some code absolutely must be LE specific,
> it needs a comment that explains this and cautions
> people against trying to use it elsewhere in QEMU.

I think its fine enough to add a comment.

Thanks
Tiejun

>
>
>>> Maybe not important here but writing clean code is
>>> just as easy.
>>> uint8_t igd_host_opregion[4];
>>>
>>> ...
>>>
>>>      xen_host_pci_get_block(&s->real_device, PCI_INTEL_OPREGION,
>>> 			   igd_host_opregion, sizeof igd_host_opregion);
>>>
>>>      igd_guest_opregion = (val & ~0xfff) |
>>> 	    (pci_get_word(igd_host_opregion) & 0xfff);
>>>
>>> 0xfff should be a macro too to avoid duplication.
>>>
>>
>> Okay.
>>
>> Thanks
>> Tiejun
>

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> * Don't set that ISA class property, instead, just fake this ISA bridge
>   with 00:1f.0.

How are you going to make this work for Q35 or another PCIe machine that 
already has an ISA bridge at 00:1f.0?

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> * Don't set that ISA class property, instead, just fake this ISA bridge
>   with 00:1f.0.

How are you going to make this work for Q35 or another PCIe machine that 
already has an ISA bridge at 00:1f.0?

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 08:19:19AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> >* Don't set that ISA class property, instead, just fake this ISA bridge
> >  with 00:1f.0.
> 
> How are you going to make this work for Q35 or another PCIe machine that
> already has an ISA bridge at 00:1f.0?
> 
> Paolo

Maybe it just works?
Is tweaking vendor/device/revision id to match host really necessary?

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 08:19:19AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> >* Don't set that ISA class property, instead, just fake this ISA bridge
> >  with 00:1f.0.
> 
> How are you going to make this work for Q35 or another PCIe machine that
> already has an ISA bridge at 00:1f.0?
> 
> Paolo

Maybe it just works?
Is tweaking vendor/device/revision id to match host really necessary?

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 09:15, Michael S. Tsirkin ha scritto:
> Maybe it just works?
> Is tweaking vendor/device/revision id to match host really necessary?

Yes, the driver inspects the fields and tweaks its behavior according to 
them.  It also pokes at configuration space of the host bridge.  It's 
quite disgusting.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 09:15, Michael S. Tsirkin ha scritto:
> Maybe it just works?
> Is tweaking vendor/device/revision id to match host really necessary?

Yes, the driver inspects the fields and tweaks its behavior according to 
them.  It also pokes at configuration space of the host bridge.  It's 
quite disgusting.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 14:19, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> * Don't set that ISA class property, instead, just fake this ISA bridge
>>   with 00:1f.0.
>
> How are you going to make this work for Q35 or another PCIe machine that
> already has an ISA bridge at 00:1f.0?
>

Could we simply pass the vendor/device ids of the host ISA bridge here?

Thanks
Tiejun

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 14:19, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> * Don't set that ISA class property, instead, just fake this ISA bridge
>>   with 00:1f.0.
>
> How are you going to make this work for Q35 or another PCIe machine that
> already has an ISA bridge at 00:1f.0?
>

Could we simply pass the vendor/device ids of the host ISA bridge here?

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 03:35:51PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 14:19, Paolo Bonzini wrote:
> >Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> >>* Don't set that ISA class property, instead, just fake this ISA bridge
> >>  with 00:1f.0.
> >
> >How are you going to make this work for Q35 or another PCIe machine that
> >already has an ISA bridge at 00:1f.0?
> >
> 
> Could we simply pass the vendor/device ids of the host ISA bridge here?
> 
> Thanks
> Tiejun

Will firmware have drivers for this bridge?

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 03:35:51PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 14:19, Paolo Bonzini wrote:
> >Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> >>* Don't set that ISA class property, instead, just fake this ISA bridge
> >>  with 00:1f.0.
> >
> >How are you going to make this work for Q35 or another PCIe machine that
> >already has an ISA bridge at 00:1f.0?
> >
> 
> Could we simply pass the vendor/device ids of the host ISA bridge here?
> 
> Thanks
> Tiejun

Will firmware have drivers for this bridge?

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 09:35, Chen, Tiejun ha scritto:
>> How are you going to make this work for Q35 or another PCIe machine that
>> already has an ISA bridge at 00:1f.0?
>>
>
> Could we simply pass the vendor/device ids of the host ISA bridge here?

No, because the firmware then would not recognize the host ISA bridge 
and would fail to initialize the ACPI PMBASE, the PCI interrupt routing, 
etc.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 09:35, Chen, Tiejun ha scritto:
>> How are you going to make this work for Q35 or another PCIe machine that
>> already has an ISA bridge at 00:1f.0?
>>
>
> Could we simply pass the vendor/device ids of the host ISA bridge here?

No, because the firmware then would not recognize the host ISA bridge 
and would fail to initialize the ACPI PMBASE, the PCI interrupt routing, 
etc.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 09:44:14AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 09:35, Chen, Tiejun ha scritto:
> >>How are you going to make this work for Q35 or another PCIe machine that
> >>already has an ISA bridge at 00:1f.0?
> >>
> >
> >Could we simply pass the vendor/device ids of the host ISA bridge here?
> 
> No, because the firmware then would not recognize the host ISA bridge and
> would fail to initialize the ACPI PMBASE, the PCI interrupt routing, etc.
> 
> Paolo

It might be possible to move the Q35 bridge elsewhere.
seabios doesn't care where the host bridge is.
ACPI tables in QEMU can be adjusted.

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 09:44:14AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 09:35, Chen, Tiejun ha scritto:
> >>How are you going to make this work for Q35 or another PCIe machine that
> >>already has an ISA bridge at 00:1f.0?
> >>
> >
> >Could we simply pass the vendor/device ids of the host ISA bridge here?
> 
> No, because the firmware then would not recognize the host ISA bridge and
> would fail to initialize the ACPI PMBASE, the PCI interrupt routing, etc.
> 
> Paolo

It might be possible to move the Q35 bridge elsewhere.
seabios doesn't care where the host bridge is.
ACPI tables in QEMU can be adjusted.

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
> It might be possible to move the Q35 bridge elsewhere.
> seabios doesn't care where the host bridge is.
> ACPI tables in QEMU can be adjusted.

But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver 
wants to run under virtual machines, it should stop acting as if it 
knows what the whole machine looks like.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
> It might be possible to move the Q35 bridge elsewhere.
> seabios doesn't care where the host bridge is.
> ACPI tables in QEMU can be adjusted.

But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver 
wants to run under virtual machines, it should stop acting as if it 
knows what the whole machine looks like.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
> >It might be possible to move the Q35 bridge elsewhere.
> >seabios doesn't care where the host bridge is.
> >ACPI tables in QEMU can be adjusted.
> 
> But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver wants
> to run under virtual machines, it should stop acting as if it knows what the
> whole machine looks like.
> 
> Paolo

If guest driver can be fixed that seems ideal.
I don't know how it works but presumably you guys do?

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
> >It might be possible to move the Q35 bridge elsewhere.
> >seabios doesn't care where the host bridge is.
> >ACPI tables in QEMU can be adjusted.
> 
> But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver wants
> to run under virtual machines, it should stop acting as if it knows what the
> whole machine looks like.
> 
> Paolo

If guest driver can be fixed that seems ideal.
I don't know how it works but presumably you guys do?

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 16:48, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
>> Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
>>> It might be possible to move the Q35 bridge elsewhere.
>>> seabios doesn't care where the host bridge is.
>>> ACPI tables in QEMU can be adjusted.
>>
>> But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver wants
>> to run under virtual machines, it should stop acting as if it knows what the
>> whole machine looks like.
>>
>> Paolo
>
> If guest driver can be fixed that seems ideal.
> I don't know how it works but presumably you guys do?

Paolo prefer we need to fix this in the driver like:

"
 >>> The right way could be to make QEMU add a vendor-specific capability to
 >>> the video device. The driver can probe for that capability before
 >>
 >> Do you mean we can pick two unused offsets in the configuration space of
 >> the video device as a vendor-specific capability to hold the
 >> vendor/device ids of the PCH?
 >
 > Yes, either that or add a new capability (which lets you choose the
 > offsets more freely).
 >
 > If the IGD driver needs config space fields of the MCH, those fields
 > could also be mirrored in the new capability.  QEMU would forward them
 > automatically.
 >
 > It could even be a new BAR, which gives even more freedom to allocate
 > the fields.
"

Thanks
Tiejun

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 16:48, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
>> Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
>>> It might be possible to move the Q35 bridge elsewhere.
>>> seabios doesn't care where the host bridge is.
>>> ACPI tables in QEMU can be adjusted.
>>
>> But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver wants
>> to run under virtual machines, it should stop acting as if it knows what the
>> whole machine looks like.
>>
>> Paolo
>
> If guest driver can be fixed that seems ideal.
> I don't know how it works but presumably you guys do?

Paolo prefer we need to fix this in the driver like:

"
 >>> The right way could be to make QEMU add a vendor-specific capability to
 >>> the video device. The driver can probe for that capability before
 >>
 >> Do you mean we can pick two unused offsets in the configuration space of
 >> the video device as a vendor-specific capability to hold the
 >> vendor/device ids of the PCH?
 >
 > Yes, either that or add a new capability (which lets you choose the
 > offsets more freely).
 >
 > If the IGD driver needs config space fields of the MCH, those fields
 > could also be mirrored in the new capability.  QEMU would forward them
 > automatically.
 >
 > It could even be a new BAR, which gives even more freedom to allocate
 > the fields.
"

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 16:48, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
> >>Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
> >>>It might be possible to move the Q35 bridge elsewhere.
> >>>seabios doesn't care where the host bridge is.
> >>>ACPI tables in QEMU can be adjusted.
> >>
> >>But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver wants
> >>to run under virtual machines, it should stop acting as if it knows what the
> >>whole machine looks like.
> >>
> >>Paolo
> >
> >If guest driver can be fixed that seems ideal.
> >I don't know how it works but presumably you guys do?
> 
> Paolo prefer we need to fix this in the driver like:
> 
> "
> >>> The right way could be to make QEMU add a vendor-specific capability to
> >>> the video device. The driver can probe for that capability before
> >>
> >> Do you mean we can pick two unused offsets in the configuration space of
> >> the video device as a vendor-specific capability to hold the
> >> vendor/device ids of the PCH?
> >
> > Yes, either that or add a new capability (which lets you choose the
> > offsets more freely).
> >
> > If the IGD driver needs config space fields of the MCH, those fields
> > could also be mirrored in the new capability.  QEMU would forward them
> > automatically.
> >
> > It could even be a new BAR, which gives even more freedom to allocate
> > the fields.
> "
> 
> Thanks
> Tiejun

Adding a vendor-specific capability or BAR
in an existing device is painful - hard to find
free space for it.
We could add a dummy device in PCI or ACPI, but
driver should really look for it using device/vendor id,
not at a specific address.
What exactly is it that the driver wants to know?

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 16:48, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
> >>Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
> >>>It might be possible to move the Q35 bridge elsewhere.
> >>>seabios doesn't care where the host bridge is.
> >>>ACPI tables in QEMU can be adjusted.
> >>
> >>But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver wants
> >>to run under virtual machines, it should stop acting as if it knows what the
> >>whole machine looks like.
> >>
> >>Paolo
> >
> >If guest driver can be fixed that seems ideal.
> >I don't know how it works but presumably you guys do?
> 
> Paolo prefer we need to fix this in the driver like:
> 
> "
> >>> The right way could be to make QEMU add a vendor-specific capability to
> >>> the video device. The driver can probe for that capability before
> >>
> >> Do you mean we can pick two unused offsets in the configuration space of
> >> the video device as a vendor-specific capability to hold the
> >> vendor/device ids of the PCH?
> >
> > Yes, either that or add a new capability (which lets you choose the
> > offsets more freely).
> >
> > If the IGD driver needs config space fields of the MCH, those fields
> > could also be mirrored in the new capability.  QEMU would forward them
> > automatically.
> >
> > It could even be a new BAR, which gives even more freedom to allocate
> > the fields.
> "
> 
> Thanks
> Tiejun

Adding a vendor-specific capability or BAR
in an existing device is painful - hard to find
free space for it.
We could add a dummy device in PCI or ACPI, but
driver should really look for it using device/vendor id,
not at a specific address.
What exactly is it that the driver wants to know?

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 17:09, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 16:48, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
>>>> Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
>>>>> It might be possible to move the Q35 bridge elsewhere.
>>>>> seabios doesn't care where the host bridge is.
>>>>> ACPI tables in QEMU can be adjusted.
>>>>
>>>> But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver wants
>>>> to run under virtual machines, it should stop acting as if it knows what the
>>>> whole machine looks like.
>>>>
>>>> Paolo
>>>
>>> If guest driver can be fixed that seems ideal.
>>> I don't know how it works but presumably you guys do?
>>
>> Paolo prefer we need to fix this in the driver like:
>>
>> "
>>>>> The right way could be to make QEMU add a vendor-specific capability to
>>>>> the video device. The driver can probe for that capability before
>>>>
>>>> Do you mean we can pick two unused offsets in the configuration space of
>>>> the video device as a vendor-specific capability to hold the
>>>> vendor/device ids of the PCH?
>>>
>>> Yes, either that or add a new capability (which lets you choose the
>>> offsets more freely).
>>>
>>> If the IGD driver needs config space fields of the MCH, those fields
>>> could also be mirrored in the new capability.  QEMU would forward them
>>> automatically.
>>>
>>> It could even be a new BAR, which gives even more freedom to allocate
>>> the fields.
>> "
>>
>> Thanks
>> Tiejun
>
> Adding a vendor-specific capability or BAR
> in an existing device is painful - hard to find
> free space for it.

Yes, this is a potential risk as well since we can't guarantee current 
free space is always valid for ever.

> We could add a dummy device in PCI or ACPI, but
> driver should really look for it using device/vendor id,
> not at a specific address.
> What exactly is it that the driver wants to know?
>

The i915 driver need to use the vendor/device ids to get what pch type 
is running, then go different paths.

Thanks
Tiejun

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 17:09, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 16:48, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
>>>> Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
>>>>> It might be possible to move the Q35 bridge elsewhere.
>>>>> seabios doesn't care where the host bridge is.
>>>>> ACPI tables in QEMU can be adjusted.
>>>>
>>>> But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver wants
>>>> to run under virtual machines, it should stop acting as if it knows what the
>>>> whole machine looks like.
>>>>
>>>> Paolo
>>>
>>> If guest driver can be fixed that seems ideal.
>>> I don't know how it works but presumably you guys do?
>>
>> Paolo prefer we need to fix this in the driver like:
>>
>> "
>>>>> The right way could be to make QEMU add a vendor-specific capability to
>>>>> the video device. The driver can probe for that capability before
>>>>
>>>> Do you mean we can pick two unused offsets in the configuration space of
>>>> the video device as a vendor-specific capability to hold the
>>>> vendor/device ids of the PCH?
>>>
>>> Yes, either that or add a new capability (which lets you choose the
>>> offsets more freely).
>>>
>>> If the IGD driver needs config space fields of the MCH, those fields
>>> could also be mirrored in the new capability.  QEMU would forward them
>>> automatically.
>>>
>>> It could even be a new BAR, which gives even more freedom to allocate
>>> the fields.
>> "
>>
>> Thanks
>> Tiejun
>
> Adding a vendor-specific capability or BAR
> in an existing device is painful - hard to find
> free space for it.

Yes, this is a potential risk as well since we can't guarantee current 
free space is always valid for ever.

> We could add a dummy device in PCI or ACPI, but
> driver should really look for it using device/vendor id,
> not at a specific address.
> What exactly is it that the driver wants to know?
>

The i915 driver need to use the vendor/device ids to get what pch type 
is running, then go different paths.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 11:21, Chen, Tiejun ha scritto:
>> Adding a vendor-specific capability or BAR
>> in an existing device is painful - hard to find
>> free space for it.
>
> Yes, this is a potential risk as well since we can't guarantee current
> free space is always valid for ever.

For past devices, we know which BARs they use.  For future devices, it 
would be nice if the PCH/MCH backdoor was specified so that we know they 
will leave a free BAR for virtualization.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 11:21, Chen, Tiejun ha scritto:
>> Adding a vendor-specific capability or BAR
>> in an existing device is painful - hard to find
>> free space for it.
>
> Yes, this is a potential risk as well since we can't guarantee current
> free space is always valid for ever.

For past devices, we know which BARs they use.  For future devices, it 
would be nice if the PCH/MCH backdoor was specified so that we know they 
will leave a free BAR for virtualization.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 17:31, Paolo Bonzini wrote:
> Il 25/06/2014 11:21, Chen, Tiejun ha scritto:
>>> Adding a vendor-specific capability or BAR
>>> in an existing device is painful - hard to find
>>> free space for it.
>>
>> Yes, this is a potential risk as well since we can't guarantee current
>> free space is always valid for ever.
>
> For past devices, we know which BARs they use.  For future devices, it
> would be nice if the PCH/MCH backdoor was specified so that we know they
> will leave a free BAR for virtualization.
>

Now I'm a bit confused about BAR here.

You're saying we will reserve a free BAR to address those information to 
expose to guest, but which device does this free BAR belong to? The 
video device? Or PCH/MCH?

Thanks
Tiejun

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 17:31, Paolo Bonzini wrote:
> Il 25/06/2014 11:21, Chen, Tiejun ha scritto:
>>> Adding a vendor-specific capability or BAR
>>> in an existing device is painful - hard to find
>>> free space for it.
>>
>> Yes, this is a potential risk as well since we can't guarantee current
>> free space is always valid for ever.
>
> For past devices, we know which BARs they use.  For future devices, it
> would be nice if the PCH/MCH backdoor was specified so that we know they
> will leave a free BAR for virtualization.
>

Now I'm a bit confused about BAR here.

You're saying we will reserve a free BAR to address those information to 
expose to guest, but which device does this free BAR belong to? The 
video device? Or PCH/MCH?

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 11:50, Chen, Tiejun ha scritto:
>>
>> For past devices, we know which BARs they use.  For future devices, it
>> would be nice if the PCH/MCH backdoor was specified so that we know they
>> will leave a free BAR for virtualization.
>>
>
> Now I'm a bit confused about BAR here.
>
> You're saying we will reserve a free BAR to address those information to
> expose to guest, but which device does this free BAR belong to? The
> video device? Or PCH/MCH?

The video device.  If the host device does not have the BAR (which will 
be the common case), QEMU can emulate it like this:

- offsets 0x0000..0x0fff map to configuration space of the host MCH

- offsets 0x1000..0x1fff map to configuration space of the host PCH

Of course this is only limited to offsets that are needed by the driver.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 11:50, Chen, Tiejun ha scritto:
>>
>> For past devices, we know which BARs they use.  For future devices, it
>> would be nice if the PCH/MCH backdoor was specified so that we know they
>> will leave a free BAR for virtualization.
>>
>
> Now I'm a bit confused about BAR here.
>
> You're saying we will reserve a free BAR to address those information to
> expose to guest, but which device does this free BAR belong to? The
> video device? Or PCH/MCH?

The video device.  If the host device does not have the BAR (which will 
be the common case), QEMU can emulate it like this:

- offsets 0x0000..0x0fff map to configuration space of the host MCH

- offsets 0x1000..0x1fff map to configuration space of the host PCH

Of course this is only limited to offsets that are needed by the driver.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 11:54:22AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 11:50, Chen, Tiejun ha scritto:
> >>
> >>For past devices, we know which BARs they use.  For future devices, it
> >>would be nice if the PCH/MCH backdoor was specified so that we know they
> >>will leave a free BAR for virtualization.
> >>
> >
> >Now I'm a bit confused about BAR here.
> >
> >You're saying we will reserve a free BAR to address those information to
> >expose to guest, but which device does this free BAR belong to? The
> >video device? Or PCH/MCH?
> 
> The video device.  If the host device does not have the BAR (which will be
> the common case), QEMU can emulate it like this:
> 
> - offsets 0x0000..0x0fff map to configuration space of the host MCH
> 
> - offsets 0x1000..0x1fff map to configuration space of the host PCH
> 
> Of course this is only limited to offsets that are needed by the driver.
> 
> Paolo

Ow.
If you need hacks like this, describe this in ACPI.
But I really hope not.

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 11:54:22AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 11:50, Chen, Tiejun ha scritto:
> >>
> >>For past devices, we know which BARs they use.  For future devices, it
> >>would be nice if the PCH/MCH backdoor was specified so that we know they
> >>will leave a free BAR for virtualization.
> >>
> >
> >Now I'm a bit confused about BAR here.
> >
> >You're saying we will reserve a free BAR to address those information to
> >expose to guest, but which device does this free BAR belong to? The
> >video device? Or PCH/MCH?
> 
> The video device.  If the host device does not have the BAR (which will be
> the common case), QEMU can emulate it like this:
> 
> - offsets 0x0000..0x0fff map to configuration space of the host MCH
> 
> - offsets 0x1000..0x1fff map to configuration space of the host PCH
> 
> Of course this is only limited to offsets that are needed by the driver.
> 
> Paolo

Ow.
If you need hacks like this, describe this in ACPI.
But I really hope not.

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 17:54, Paolo Bonzini wrote:
> Il 25/06/2014 11:50, Chen, Tiejun ha scritto:
>>>
>>> For past devices, we know which BARs they use.  For future devices, it
>>> would be nice if the PCH/MCH backdoor was specified so that we know they
>>> will leave a free BAR for virtualization.
>>>
>>
>> Now I'm a bit confused about BAR here.
>>
>> You're saying we will reserve a free BAR to address those information to
>> expose to guest, but which device does this free BAR belong to? The
>> video device? Or PCH/MCH?
>
> The video device.  If the host device does not have the BAR (which will
> be the common case), QEMU can emulate it like this:

According to some feedback, neither we have any unused PCI unused config 
offset, nor BAR.

>
> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>

Are you saying the config space in the video device? but will this 
overlap? Every PCIe device already have a 4K config space, right? So we 
should extend these two ranges:

0x0000..0x0fff: the standard PCIe config space in the video device
0x1000..0x1fff: map to configuration of the real host bridge
0x2000..0x2fff: map to configuration of the real ISA bridge

Right?

But as you know, we just need to expose a little config space from the 
real host bridge and the real ISA bridge, so this may be waste with 8K.

Thanks
Tiejun

> - offsets 0x1000..0x1fff map to configuration space of the host PCH
>
> Of course this is only limited to offsets that are needed by the driver.
>
> Paolo
>
>

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 17:54, Paolo Bonzini wrote:
> Il 25/06/2014 11:50, Chen, Tiejun ha scritto:
>>>
>>> For past devices, we know which BARs they use.  For future devices, it
>>> would be nice if the PCH/MCH backdoor was specified so that we know they
>>> will leave a free BAR for virtualization.
>>>
>>
>> Now I'm a bit confused about BAR here.
>>
>> You're saying we will reserve a free BAR to address those information to
>> expose to guest, but which device does this free BAR belong to? The
>> video device? Or PCH/MCH?
>
> The video device.  If the host device does not have the BAR (which will
> be the common case), QEMU can emulate it like this:

According to some feedback, neither we have any unused PCI unused config 
offset, nor BAR.

>
> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>

Are you saying the config space in the video device? but will this 
overlap? Every PCIe device already have a 4K config space, right? So we 
should extend these two ranges:

0x0000..0x0fff: the standard PCIe config space in the video device
0x1000..0x1fff: map to configuration of the real host bridge
0x2000..0x2fff: map to configuration of the real ISA bridge

Right?

But as you know, we just need to expose a little config space from the 
real host bridge and the real ISA bridge, so this may be waste with 8K.

Thanks
Tiejun

> - offsets 0x1000..0x1fff map to configuration space of the host PCH
>
> Of course this is only limited to offsets that are needed by the driver.
>
> Paolo
>
>

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>
>>
>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>
>
> Are you saying the config space in the video device?

No, I am saying in a new BAR, or at some magic offset of an existing 
MMIO BAR.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>
>>
>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>
>
> Are you saying the config space in the video device?

No, I am saying in a new BAR, or at some magic offset of an existing 
MMIO BAR.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Thu, Jun 26, 2014 at 12:03:58PM +0200, Paolo Bonzini wrote:
> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >
> >>
> >>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>
> >
> >Are you saying the config space in the video device?
> 
> No, I am saying in a new BAR, or at some magic offset of an existing MMIO
> BAR.
> 
> Paolo

I think v5 goes a bit overboard and overrides too many registers,
driver likely needs much less.

But IMHO retro-fitting this into PIIX is where the problem is.
We could invent 1000 ways to do this, all of varying levels of
ugliness.

But why don't we start by more or less cleanly emulating what the driver
needs?  If we start with Q35 - it shouldn't be hard to tweak it's MCH to
add the necessary config space, right?

I know xen doesn't support q35 now but it's opensource :)

I think that's a good step 1. We can do PV hacks on top if we
decide they aren't too painful.

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Thu, Jun 26, 2014 at 12:03:58PM +0200, Paolo Bonzini wrote:
> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >
> >>
> >>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>
> >
> >Are you saying the config space in the video device?
> 
> No, I am saying in a new BAR, or at some magic offset of an existing MMIO
> BAR.
> 
> Paolo

I think v5 goes a bit overboard and overrides too many registers,
driver likely needs much less.

But IMHO retro-fitting this into PIIX is where the problem is.
We could invent 1000 ways to do this, all of varying levels of
ugliness.

But why don't we start by more or less cleanly emulating what the driver
needs?  If we start with Q35 - it shouldn't be hard to tweak it's MCH to
add the necessary config space, right?

I know xen doesn't support q35 now but it's opensource :)

I think that's a good step 1. We can do PV hacks on top if we
decide they aren't too painful.

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 26/06/2014 13:26, Michael S. Tsirkin ha scritto:
> On Thu, Jun 26, 2014 at 12:03:58PM +0200, Paolo Bonzini wrote:
>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>
>>>>
>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>
>>>
>>> Are you saying the config space in the video device?
>>
>> No, I am saying in a new BAR, or at some magic offset of an existing MMIO
>> BAR.
>>
>> Paolo
>
> I think v5 goes a bit overboard and overrides too many registers,
> driver likely needs much less.
>
> But IMHO retro-fitting this into PIIX is where the problem is.
> We could invent 1000 ways to do this, all of varying levels of
> ugliness.
>
> But why don't we start by more or less cleanly emulating what the driver
> needs?  If we start with Q35 - it shouldn't be hard to tweak it's MCH to
> add the necessary config space, right?
>
> I know xen doesn't support q35 now but it's opensource :)
>
> I think that's a good step 1. We can do PV hacks on top if we
> decide they aren't too painful.

I don't think it's a PV hack.  It should be this way in real hardware 
too (not exactly _this_ hack, but at least no improper relationship 
among IGD/MCH/PCH).

Once you add nested virtualization and nested device assignment to the 
mix, hacking subsystem IDs simply does not scale.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 26/06/2014 13:26, Michael S. Tsirkin ha scritto:
> On Thu, Jun 26, 2014 at 12:03:58PM +0200, Paolo Bonzini wrote:
>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>
>>>>
>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>
>>>
>>> Are you saying the config space in the video device?
>>
>> No, I am saying in a new BAR, or at some magic offset of an existing MMIO
>> BAR.
>>
>> Paolo
>
> I think v5 goes a bit overboard and overrides too many registers,
> driver likely needs much less.
>
> But IMHO retro-fitting this into PIIX is where the problem is.
> We could invent 1000 ways to do this, all of varying levels of
> ugliness.
>
> But why don't we start by more or less cleanly emulating what the driver
> needs?  If we start with Q35 - it shouldn't be hard to tweak it's MCH to
> add the necessary config space, right?
>
> I know xen doesn't support q35 now but it's opensource :)
>
> I think that's a good step 1. We can do PV hacks on top if we
> decide they aren't too painful.

I don't think it's a PV hack.  It should be this way in real hardware 
too (not exactly _this_ hack, but at least no improper relationship 
among IGD/MCH/PCH).

Once you add nested virtualization and nested device assignment to the 
mix, hacking subsystem IDs simply does not scale.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Thu, Jun 26, 2014 at 01:30:42PM +0200, Paolo Bonzini wrote:
> Il 26/06/2014 13:26, Michael S. Tsirkin ha scritto:
> >On Thu, Jun 26, 2014 at 12:03:58PM +0200, Paolo Bonzini wrote:
> >>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>
> >>>>
> >>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>
> >>>
> >>>Are you saying the config space in the video device?
> >>
> >>No, I am saying in a new BAR, or at some magic offset of an existing MMIO
> >>BAR.
> >>
> >>Paolo
> >
> >I think v5 goes a bit overboard and overrides too many registers,
> >driver likely needs much less.
> >
> >But IMHO retro-fitting this into PIIX is where the problem is.
> >We could invent 1000 ways to do this, all of varying levels of
> >ugliness.
> >
> >But why don't we start by more or less cleanly emulating what the driver
> >needs?  If we start with Q35 - it shouldn't be hard to tweak it's MCH to
> >add the necessary config space, right?
> >
> >I know xen doesn't support q35 now but it's opensource :)
> >
> >I think that's a good step 1. We can do PV hacks on top if we
> >decide they aren't too painful.
> 
> I don't think it's a PV hack.  It should be this way in real hardware too

But it isn't.

> (not exactly _this_ hack, but at least no improper relationship among
> IGD/MCH/PCH).

Well that dependency between devices is common for embedded hardware,
and this is what we have here.

> Once you add nested virtualization and nested device assignment to the mix,
> hacking subsystem IDs simply does not scale.
> 
> Paolo

I'm not talking about subsystem id either, I'm talking about
closely emulating the physical system that driver expects.
In particular this definitely means not starting with PIIX :)

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Thu, Jun 26, 2014 at 01:30:42PM +0200, Paolo Bonzini wrote:
> Il 26/06/2014 13:26, Michael S. Tsirkin ha scritto:
> >On Thu, Jun 26, 2014 at 12:03:58PM +0200, Paolo Bonzini wrote:
> >>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>
> >>>>
> >>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>
> >>>
> >>>Are you saying the config space in the video device?
> >>
> >>No, I am saying in a new BAR, or at some magic offset of an existing MMIO
> >>BAR.
> >>
> >>Paolo
> >
> >I think v5 goes a bit overboard and overrides too many registers,
> >driver likely needs much less.
> >
> >But IMHO retro-fitting this into PIIX is where the problem is.
> >We could invent 1000 ways to do this, all of varying levels of
> >ugliness.
> >
> >But why don't we start by more or less cleanly emulating what the driver
> >needs?  If we start with Q35 - it shouldn't be hard to tweak it's MCH to
> >add the necessary config space, right?
> >
> >I know xen doesn't support q35 now but it's opensource :)
> >
> >I think that's a good step 1. We can do PV hacks on top if we
> >decide they aren't too painful.
> 
> I don't think it's a PV hack.  It should be this way in real hardware too

But it isn't.

> (not exactly _this_ hack, but at least no improper relationship among
> IGD/MCH/PCH).

Well that dependency between devices is common for embedded hardware,
and this is what we have here.

> Once you add nested virtualization and nested device assignment to the mix,
> hacking subsystem IDs simply does not scale.
> 
> Paolo

I'm not talking about subsystem id either, I'm talking about
closely emulating the physical system that driver expects.
In particular this definitely means not starting with PIIX :)

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 26/06/2014 13:36, Michael S. Tsirkin ha scritto:
>> It should be this way in real hardware too
> But it isn't.

That's why I mentioned that this hack should become architecturally 
specified (since it can work on real hardware too) with QEMU doing the 
emulation for current-generation devices.

> > (not exactly _this_ hack, but at least no improper relationship among
> > IGD/MCH/PCH).
>
> Well that dependency between devices is common for embedded hardware,
> and this is what we have here.

Sure, but then you should put MCH/PCH/IGD in the same IOMMU group, which 
basically means forgetting about IGD assignment.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 26/06/2014 13:36, Michael S. Tsirkin ha scritto:
>> It should be this way in real hardware too
> But it isn't.

That's why I mentioned that this hack should become architecturally 
specified (since it can work on real hardware too) with QEMU doing the 
emulation for current-generation devices.

> > (not exactly _this_ hack, but at least no improper relationship among
> > IGD/MCH/PCH).
>
> Well that dependency between devices is common for embedded hardware,
> and this is what we have here.

Sure, but then you should put MCH/PCH/IGD in the same IOMMU group, which 
basically means forgetting about IGD assignment.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Thu, Jun 26, 2014 at 03:30:11PM +0200, Paolo Bonzini wrote:
> Il 26/06/2014 13:36, Michael S. Tsirkin ha scritto:
> >>It should be this way in real hardware too
> >But it isn't.
> 
> That's why I mentioned that this hack should become architecturally
> specified (since it can work on real hardware too)

Someone will have to implement it on real hardware first :)
As long as no one does it's really PV.
I have no problem with PV as such, however
1. let's try to make it look less like a one-off hack
2. let's start with proper emulation, pv as step 2

> with QEMU doing the
> emulation for current-generation devices.
> 
> >> (not exactly _this_ hack, but at least no improper relationship among
> >> IGD/MCH/PCH).
> >
> >Well that dependency between devices is common for embedded hardware,
> >and this is what we have here.
> 
> Sure, but then you should put MCH/PCH/IGD in the same IOMMU group, which
> basically means forgetting about IGD assignment.
> 
> Paolo

I don't see why. We emulate parts of devices (e.g. BARs), ISA bridge/MCH is just
such part of device that we emulate.


-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Thu, Jun 26, 2014 at 03:30:11PM +0200, Paolo Bonzini wrote:
> Il 26/06/2014 13:36, Michael S. Tsirkin ha scritto:
> >>It should be this way in real hardware too
> >But it isn't.
> 
> That's why I mentioned that this hack should become architecturally
> specified (since it can work on real hardware too)

Someone will have to implement it on real hardware first :)
As long as no one does it's really PV.
I have no problem with PV as such, however
1. let's try to make it look less like a one-off hack
2. let's start with proper emulation, pv as step 2

> with QEMU doing the
> emulation for current-generation devices.
> 
> >> (not exactly _this_ hack, but at least no improper relationship among
> >> IGD/MCH/PCH).
> >
> >Well that dependency between devices is common for embedded hardware,
> >and this is what we have here.
> 
> Sure, but then you should put MCH/PCH/IGD in the same IOMMU group, which
> basically means forgetting about IGD assignment.
> 
> Paolo

I don't see why. We emulate parts of devices (e.g. BARs), ISA bridge/MCH is just
such part of device that we emulate.


-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/26 18:03, Paolo Bonzini wrote:
> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>
>>>
>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>
>>
>> Are you saying the config space in the video device?
>
> No, I am saying in a new BAR, or at some magic offset of an existing
> MMIO BAR.
>

As I mentioned previously, the IGD guy told me we have no any unused a 
offset or BAR in the config space.

And guy who are responsible for the native driver seems not be accept to 
extend some magic offset of an existing MMIO BAR.

In addition I think in a short time its not possible to migrate i440fx 
to q35 as a PCIe machine of xen. So could we do this step by step:

#1 phase: We just cover current qemu-xen implementation based on i44fx, 
so still provide that pseudo ISA bridge at 00:1f.0 as we already did.

#2 phase: Now, we will choose a capability ID that won't be conflicting 
with others. To do this properly, we need to get one from PCI SIG group. 
To have this workable and consistently validated, this method shouldn't 
be virt specific. Then native driver should use the same method. So when 
xen work on q35 PCIe machine, we can walk this way.

Anthony,

Any comments to address this in xen case?

Thanks
Tiejun

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/26 18:03, Paolo Bonzini wrote:
> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>
>>>
>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>
>>
>> Are you saying the config space in the video device?
>
> No, I am saying in a new BAR, or at some magic offset of an existing
> MMIO BAR.
>

As I mentioned previously, the IGD guy told me we have no any unused a 
offset or BAR in the config space.

And guy who are responsible for the native driver seems not be accept to 
extend some magic offset of an existing MMIO BAR.

In addition I think in a short time its not possible to migrate i440fx 
to q35 as a PCIe machine of xen. So could we do this step by step:

#1 phase: We just cover current qemu-xen implementation based on i44fx, 
so still provide that pseudo ISA bridge at 00:1f.0 as we already did.

#2 phase: Now, we will choose a capability ID that won't be conflicting 
with others. To do this properly, we need to get one from PCI SIG group. 
To have this workable and consistently validated, this method shouldn't 
be virt specific. Then native driver should use the same method. So when 
xen work on q35 PCIe machine, we can walk this way.

Anthony,

Any comments to address this in xen case?

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> On 2014/6/26 18:03, Paolo Bonzini wrote:
> >Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>
> >>>
> >>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>
> >>
> >>Are you saying the config space in the video device?
> >
> >No, I am saying in a new BAR, or at some magic offset of an existing
> >MMIO BAR.
> >
> 
> As I mentioned previously, the IGD guy told me we have no any unused a
> offset or BAR in the config space.
> 
> And guy who are responsible for the native driver seems not be accept to
> extend some magic offset of an existing MMIO BAR.
> 
> In addition I think in a short time its not possible to migrate i440fx to
> q35 as a PCIe machine of xen.

That seems like a weak motivation.  I don't see a need to get something
merged upstream in a short time: this seems sure to miss 2.1,
so you have the time to make it architecturally sound.
"Making existing guests work" would be a better motivation.
Isn't this possible with an mch chipset?


> So could we do this step by step:
> 
> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
> still provide that pseudo ISA bridge at 00:1f.0 as we already did.

By the way there is no reason to put it at 00:1f.0 specifically I think.
So it seems simple: create a dummy device that gets device and
vendor id as properties. If you really like, add an option to get values
from sysfs: device and vendor id are world readable, so just get them
directly and not through xen wrappers, this way you can open the files
RO and not RW.
You seem to poke at revision as well, I don't see
driver looking at that - strictly necessary?
If yes please patch host kernel to expose that info in sysfs,
though we can fall back on pci config if not there.

MCH (bridge_dev) hacks in i915 are nastier.
To clean them up, we really have to have an explicit driver for this
bridge, not a pass-through device.  Long term, the right thing to do is
likely to extend host driver and expose the necessary information in
sysfs on host kernel.




> #2 phase: Now, we will choose a capability ID that won't be conflicting with
> others. To do this properly, we need to get one from PCI SIG group. To have
> this workable and consistently validated, this method shouldn't be virt
> specific. Then native driver should use the same method.

You mean you will be able to talk sense into hardware guys?
I doubt that. If they could be convinced to make e.g. i915 base a
proper BAR, why didn't they?


> So when xen work on
> q35 PCIe machine, we can walk this way.

If you are emulating MCH anyway, pick one that is close
to what i915 driver expects. It would then work with existing
devices, without new capability IDs.


> Anthony,
> 
> Any comments to address this in xen case?
> 
> Thanks
> Tiejun

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> On 2014/6/26 18:03, Paolo Bonzini wrote:
> >Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>
> >>>
> >>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>
> >>
> >>Are you saying the config space in the video device?
> >
> >No, I am saying in a new BAR, or at some magic offset of an existing
> >MMIO BAR.
> >
> 
> As I mentioned previously, the IGD guy told me we have no any unused a
> offset or BAR in the config space.
> 
> And guy who are responsible for the native driver seems not be accept to
> extend some magic offset of an existing MMIO BAR.
> 
> In addition I think in a short time its not possible to migrate i440fx to
> q35 as a PCIe machine of xen.

That seems like a weak motivation.  I don't see a need to get something
merged upstream in a short time: this seems sure to miss 2.1,
so you have the time to make it architecturally sound.
"Making existing guests work" would be a better motivation.
Isn't this possible with an mch chipset?


> So could we do this step by step:
> 
> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
> still provide that pseudo ISA bridge at 00:1f.0 as we already did.

By the way there is no reason to put it at 00:1f.0 specifically I think.
So it seems simple: create a dummy device that gets device and
vendor id as properties. If you really like, add an option to get values
from sysfs: device and vendor id are world readable, so just get them
directly and not through xen wrappers, this way you can open the files
RO and not RW.
You seem to poke at revision as well, I don't see
driver looking at that - strictly necessary?
If yes please patch host kernel to expose that info in sysfs,
though we can fall back on pci config if not there.

MCH (bridge_dev) hacks in i915 are nastier.
To clean them up, we really have to have an explicit driver for this
bridge, not a pass-through device.  Long term, the right thing to do is
likely to extend host driver and expose the necessary information in
sysfs on host kernel.




> #2 phase: Now, we will choose a capability ID that won't be conflicting with
> others. To do this properly, we need to get one from PCI SIG group. To have
> this workable and consistently validated, this method shouldn't be virt
> specific. Then native driver should use the same method.

You mean you will be able to talk sense into hardware guys?
I doubt that. If they could be convinced to make e.g. i915 base a
proper BAR, why didn't they?


> So when xen work on
> q35 PCIe machine, we can walk this way.

If you are emulating MCH anyway, pick one that is close
to what i915 driver expects. It would then work with existing
devices, without new capability IDs.


> Anthony,
> 
> Any comments to address this in xen case?
> 
> Thanks
> Tiejun

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>
>>>>>
>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>
>>>>
>>>> Are you saying the config space in the video device?
>>>
>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>> MMIO BAR.
>>>
>>
>> As I mentioned previously, the IGD guy told me we have no any unused a
>> offset or BAR in the config space.
>>
>> And guy who are responsible for the native driver seems not be accept to
>> extend some magic offset of an existing MMIO BAR.
>>
>> In addition I think in a short time its not possible to migrate i440fx to
>> q35 as a PCIe machine of xen.
>
> That seems like a weak motivation.  I don't see a need to get something
> merged upstream in a short time: this seems sure to miss 2.1,
> so you have the time to make it architecturally sound.
> "Making existing guests work" would be a better motivation.

Yes.

> Isn't this possible with an mch chipset?

If you're saying q35, I mean AFAIK we have no any plan to migrate to 
this MCH in xen case. Additionally, I think I should follow this feature 
after q35 can work for xen scenario.

>
>
>> So could we do this step by step:
>>
>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>
> By the way there is no reason to put it at 00:1f.0 specifically I think.
> So it seems simple: create a dummy device that gets device and
> vendor id as properties. If you really like, add an option to get values

Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx 
passthrough: create pseudo intel isa bridge. There, we fake this device 
just at 00:1f.0.

But you guys don't like this, and shouldn't this be just this point we 
discussing now?

If you guys agree that , everything is fine.

> from sysfs: device and vendor id are world readable, so just get them
> directly and not through xen wrappers, this way you can open the files
> RO and not RW.
> You seem to poke at revision as well, I don't see
> driver looking at that - strictly necessary?
> If yes please patch host kernel to expose that info in sysfs,
> though we can fall back on pci config if not there.
>
> MCH (bridge_dev) hacks in i915 are nastier.
> To clean them up, we really have to have an explicit driver for this
> bridge, not a pass-through device.  Long term, the right thing to do is
> likely to extend host driver and expose the necessary information in
> sysfs on host kernel.
>
>

I'm a bit confused. Any sysfs should be filled by the associated PCIe 
device, shouldn't it? So qemu still need to emulate this PCIe device 
firstly, then set properties into sysfs.

>
>
>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>> others. To do this properly, we need to get one from PCI SIG group. To have
>> this workable and consistently validated, this method shouldn't be virt
>> specific. Then native driver should use the same method.
>
> You mean you will be able to talk sense into hardware guys?
> I doubt that. If they could be convinced to make e.g. i915 base a

We're negotiating this, so this is just our long term solution we figure 
out currently.

> proper BAR, why didn't they?

We already have no any free BAR as we mentioned previously.

>
>
>> So when xen work on
>> q35 PCIe machine, we can walk this way.
>
> If you are emulating MCH anyway, pick one that is close
> to what i915 driver expects. It would then work with existing

Looks you guys prefer we create a new MCH anyway, right? But is it 
necessary to create a new based on i440fx just for a little change?

Thanks
Tiejun

> devices, without new capability IDs.
>
>
>> Anthony,
>>
>> Any comments to address this in xen case?
>>
>> Thanks
>> Tiejun
>
>

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>
>>>>>
>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>
>>>>
>>>> Are you saying the config space in the video device?
>>>
>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>> MMIO BAR.
>>>
>>
>> As I mentioned previously, the IGD guy told me we have no any unused a
>> offset or BAR in the config space.
>>
>> And guy who are responsible for the native driver seems not be accept to
>> extend some magic offset of an existing MMIO BAR.
>>
>> In addition I think in a short time its not possible to migrate i440fx to
>> q35 as a PCIe machine of xen.
>
> That seems like a weak motivation.  I don't see a need to get something
> merged upstream in a short time: this seems sure to miss 2.1,
> so you have the time to make it architecturally sound.
> "Making existing guests work" would be a better motivation.

Yes.

> Isn't this possible with an mch chipset?

If you're saying q35, I mean AFAIK we have no any plan to migrate to 
this MCH in xen case. Additionally, I think I should follow this feature 
after q35 can work for xen scenario.

>
>
>> So could we do this step by step:
>>
>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>
> By the way there is no reason to put it at 00:1f.0 specifically I think.
> So it seems simple: create a dummy device that gets device and
> vendor id as properties. If you really like, add an option to get values

Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx 
passthrough: create pseudo intel isa bridge. There, we fake this device 
just at 00:1f.0.

But you guys don't like this, and shouldn't this be just this point we 
discussing now?

If you guys agree that , everything is fine.

> from sysfs: device and vendor id are world readable, so just get them
> directly and not through xen wrappers, this way you can open the files
> RO and not RW.
> You seem to poke at revision as well, I don't see
> driver looking at that - strictly necessary?
> If yes please patch host kernel to expose that info in sysfs,
> though we can fall back on pci config if not there.
>
> MCH (bridge_dev) hacks in i915 are nastier.
> To clean them up, we really have to have an explicit driver for this
> bridge, not a pass-through device.  Long term, the right thing to do is
> likely to extend host driver and expose the necessary information in
> sysfs on host kernel.
>
>

I'm a bit confused. Any sysfs should be filled by the associated PCIe 
device, shouldn't it? So qemu still need to emulate this PCIe device 
firstly, then set properties into sysfs.

>
>
>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>> others. To do this properly, we need to get one from PCI SIG group. To have
>> this workable and consistently validated, this method shouldn't be virt
>> specific. Then native driver should use the same method.
>
> You mean you will be able to talk sense into hardware guys?
> I doubt that. If they could be convinced to make e.g. i915 base a

We're negotiating this, so this is just our long term solution we figure 
out currently.

> proper BAR, why didn't they?

We already have no any free BAR as we mentioned previously.

>
>
>> So when xen work on
>> q35 PCIe machine, we can walk this way.
>
> If you are emulating MCH anyway, pick one that is close
> to what i915 driver expects. It would then work with existing

Looks you guys prefer we create a new MCH anyway, right? But is it 
necessary to create a new based on i440fx just for a little change?

Thanks
Tiejun

> devices, without new capability IDs.
>
>
>> Anthony,
>>
>> Any comments to address this in xen case?
>>
>> Thanks
>> Tiejun
>
>

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>
> >>>>>
> >>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>
> >>>>
> >>>>Are you saying the config space in the video device?
> >>>
> >>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>MMIO BAR.
> >>>
> >>
> >>As I mentioned previously, the IGD guy told me we have no any unused a
> >>offset or BAR in the config space.
> >>
> >>And guy who are responsible for the native driver seems not be accept to
> >>extend some magic offset of an existing MMIO BAR.
> >>
> >>In addition I think in a short time its not possible to migrate i440fx to
> >>q35 as a PCIe machine of xen.
> >
> >That seems like a weak motivation.  I don't see a need to get something
> >merged upstream in a short time: this seems sure to miss 2.1,
> >so you have the time to make it architecturally sound.
> >"Making existing guests work" would be a better motivation.
> 
> Yes.

So focus on this then. Existing guests will probably work
fine on a newer chipset - likely better than on i440fx.
xen management tools need to do some work to support this?
That will just give everyone more long term benefits.

If instead we create a hack that does not resemble
any existing hardware even remotely, what's the
chance that it will not break with any future
guest modification?


> >Isn't this possible with an mch chipset?
> 
> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> MCH in xen case.

q35 or a newer chipset that's closer to what guests expect.

> Additionally, I think I should follow this feature after
> q35 can work for xen scenario.

What's stopping you?

> >
> >
> >>So could we do this step by step:
> >>
> >>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >
> >By the way there is no reason to put it at 00:1f.0 specifically I think.
> >So it seems simple: create a dummy device that gets device and
> >vendor id as properties. If you really like, add an option to get values
> 
> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> passthrough: create pseudo intel isa bridge. There, we fake this device just
> at 00:1f.0.
> But you guys don't like this, and shouldn't this be just this point we
> discussing now?
> 
> If you guys agree that , everything is fine.

Actually, this isn't what you did.
Don't tie it to xen, and don't tie it to 1f.
Just make it a simple stub pci device.
Whoever wants it, creates it.

The thing I worry about, is the chance this will break going forward.
So you created a system with 2 isa bridges.
This is already not something that exists on real hardware.
So it might break some guests that will get confused.
Maybe we are lucky and most guests see an unfamiliar device
and ignore it. It seems believable.

But your MCH hack overrides registers in the pci host.
Are we lucky and there's nothing in these registers
of interest to guests? This seems much more fragile.
So please poke at the spec, and compile the list
of registers you want to touch, figure out why they are
safe to override, and put this all in code comments.

And the same thing that applies to the isa bridge
applies here too. It should work without QEMU touching
hosts' hardware.



> >from sysfs: device and vendor id are world readable, so just get them
> >directly and not through xen wrappers, this way you can open the files
> >RO and not RW.
> >You seem to poke at revision as well, I don't see
> >driver looking at that - strictly necessary?
> >If yes please patch host kernel to expose that info in sysfs,
> >though we can fall back on pci config if not there.
> >
> >MCH (bridge_dev) hacks in i915 are nastier.
> >To clean them up, we really have to have an explicit driver for this
> >bridge, not a pass-through device.  Long term, the right thing to do is
> >likely to extend host driver and expose the necessary information in
> >sysfs on host kernel.
> >
> >
> 
> I'm a bit confused. Any sysfs should be filled by the associated PCIe
> device, shouldn't it? So qemu still need to emulate this PCIe device
> firstly, then set properties into sysfs.

I am talking about getting host properties into qemu.
You don't want to give qemu R/W root access to host sysfs system
of the root bridge, that's not secure.
Avoiding read only access to filesystem is a good idea too, so it
should be possible to pass all parameters in as
device properties, and let whoever starts qemu
figure out what are reasonable values.

> >
> >
> >>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>others. To do this properly, we need to get one from PCI SIG group. To have
> >>this workable and consistently validated, this method shouldn't be virt
> >>specific. Then native driver should use the same method.
> >
> >You mean you will be able to talk sense into hardware guys?
> >I doubt that. If they could be convinced to make e.g. i915 base a
> 
> We're negotiating this, so this is just our long term solution we figure out
> currently.
> 
> >proper BAR, why didn't they?
> 
> We already have no any free BAR as we mentioned previously.

I thought you were talking about modifying hardware?

> >
> >
> >>So when xen work on
> >>q35 PCIe machine, we can walk this way.
> >
> >If you are emulating MCH anyway, pick one that is close
> >to what i915 driver expects. It would then work with existing
> 
> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> to create a new based on i440fx just for a little change?
> 
> Thanks
> Tiejun

You can inherit it. Maybe you are lucky and this happens to
work without conflicting with whatever other guests want to do.
But if you ask me, you are really just piling up hacks.
If some guest does not work on i440, you should just work on
emulating whatever it does work on.
That would have real value.

> >devices, without new capability IDs.
> >
> >
> >>Anthony,
> >>
> >>Any comments to address this in xen case?
> >>
> >>Thanks
> >>Tiejun
> >
> >

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>
> >>>>>
> >>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>
> >>>>
> >>>>Are you saying the config space in the video device?
> >>>
> >>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>MMIO BAR.
> >>>
> >>
> >>As I mentioned previously, the IGD guy told me we have no any unused a
> >>offset or BAR in the config space.
> >>
> >>And guy who are responsible for the native driver seems not be accept to
> >>extend some magic offset of an existing MMIO BAR.
> >>
> >>In addition I think in a short time its not possible to migrate i440fx to
> >>q35 as a PCIe machine of xen.
> >
> >That seems like a weak motivation.  I don't see a need to get something
> >merged upstream in a short time: this seems sure to miss 2.1,
> >so you have the time to make it architecturally sound.
> >"Making existing guests work" would be a better motivation.
> 
> Yes.

So focus on this then. Existing guests will probably work
fine on a newer chipset - likely better than on i440fx.
xen management tools need to do some work to support this?
That will just give everyone more long term benefits.

If instead we create a hack that does not resemble
any existing hardware even remotely, what's the
chance that it will not break with any future
guest modification?


> >Isn't this possible with an mch chipset?
> 
> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> MCH in xen case.

q35 or a newer chipset that's closer to what guests expect.

> Additionally, I think I should follow this feature after
> q35 can work for xen scenario.

What's stopping you?

> >
> >
> >>So could we do this step by step:
> >>
> >>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >
> >By the way there is no reason to put it at 00:1f.0 specifically I think.
> >So it seems simple: create a dummy device that gets device and
> >vendor id as properties. If you really like, add an option to get values
> 
> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> passthrough: create pseudo intel isa bridge. There, we fake this device just
> at 00:1f.0.
> But you guys don't like this, and shouldn't this be just this point we
> discussing now?
> 
> If you guys agree that , everything is fine.

Actually, this isn't what you did.
Don't tie it to xen, and don't tie it to 1f.
Just make it a simple stub pci device.
Whoever wants it, creates it.

The thing I worry about, is the chance this will break going forward.
So you created a system with 2 isa bridges.
This is already not something that exists on real hardware.
So it might break some guests that will get confused.
Maybe we are lucky and most guests see an unfamiliar device
and ignore it. It seems believable.

But your MCH hack overrides registers in the pci host.
Are we lucky and there's nothing in these registers
of interest to guests? This seems much more fragile.
So please poke at the spec, and compile the list
of registers you want to touch, figure out why they are
safe to override, and put this all in code comments.

And the same thing that applies to the isa bridge
applies here too. It should work without QEMU touching
hosts' hardware.



> >from sysfs: device and vendor id are world readable, so just get them
> >directly and not through xen wrappers, this way you can open the files
> >RO and not RW.
> >You seem to poke at revision as well, I don't see
> >driver looking at that - strictly necessary?
> >If yes please patch host kernel to expose that info in sysfs,
> >though we can fall back on pci config if not there.
> >
> >MCH (bridge_dev) hacks in i915 are nastier.
> >To clean them up, we really have to have an explicit driver for this
> >bridge, not a pass-through device.  Long term, the right thing to do is
> >likely to extend host driver and expose the necessary information in
> >sysfs on host kernel.
> >
> >
> 
> I'm a bit confused. Any sysfs should be filled by the associated PCIe
> device, shouldn't it? So qemu still need to emulate this PCIe device
> firstly, then set properties into sysfs.

I am talking about getting host properties into qemu.
You don't want to give qemu R/W root access to host sysfs system
of the root bridge, that's not secure.
Avoiding read only access to filesystem is a good idea too, so it
should be possible to pass all parameters in as
device properties, and let whoever starts qemu
figure out what are reasonable values.

> >
> >
> >>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>others. To do this properly, we need to get one from PCI SIG group. To have
> >>this workable and consistently validated, this method shouldn't be virt
> >>specific. Then native driver should use the same method.
> >
> >You mean you will be able to talk sense into hardware guys?
> >I doubt that. If they could be convinced to make e.g. i915 base a
> 
> We're negotiating this, so this is just our long term solution we figure out
> currently.
> 
> >proper BAR, why didn't they?
> 
> We already have no any free BAR as we mentioned previously.

I thought you were talking about modifying hardware?

> >
> >
> >>So when xen work on
> >>q35 PCIe machine, we can walk this way.
> >
> >If you are emulating MCH anyway, pick one that is close
> >to what i915 driver expects. It would then work with existing
> 
> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> to create a new based on i440fx just for a little change?
> 
> Thanks
> Tiejun

You can inherit it. Maybe you are lucky and this happens to
work without conflicting with whatever other guests want to do.
But if you ask me, you are really just piling up hacks.
If some guest does not work on i440, you should just work on
emulating whatever it does work on.
That would have real value.

> >devices, without new capability IDs.
> >
> >
> >>Anthony,
> >>
> >>Any comments to address this in xen case?
> >>
> >>Thanks
> >>Tiejun
> >
> >

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>
>>>>>>>
>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>
>>>>>>
>>>>>> Are you saying the config space in the video device?
>>>>>
>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>> MMIO BAR.
>>>>>
>>>>
>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>> offset or BAR in the config space.
>>>>
>>>> And guy who are responsible for the native driver seems not be accept to
>>>> extend some magic offset of an existing MMIO BAR.
>>>>
>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>> q35 as a PCIe machine of xen.
>>>
>>> That seems like a weak motivation.  I don't see a need to get something
>>> merged upstream in a short time: this seems sure to miss 2.1,
>>> so you have the time to make it architecturally sound.
>>> "Making existing guests work" would be a better motivation.
>>
>> Yes.
>
> So focus on this then. Existing guests will probably work
> fine on a newer chipset - likely better than on i440fx.
> xen management tools need to do some work to support this?
> That will just give everyone more long term benefits.
>
> If instead we create a hack that does not resemble
> any existing hardware even remotely, what's the
> chance that it will not break with any future
> guest modification?
>
>
>>> Isn't this possible with an mch chipset?
>>
>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>> MCH in xen case.
>
> q35 or a newer chipset that's closer to what guests expect.
>
>> Additionally, I think I should follow this feature after
>> q35 can work for xen scenario.
>
> What's stopping you?

I mean if you want create an new machine based on q35, actually this is 
equal to start making xen to migrate to q35 now. Right? I can't image 
how much effort should be done.

So this is a reason why I'm saying I'd like to follow this feature after 
q35 can work with xen completely.

>
>>>
>>>
>>>> So could we do this step by step:
>>>>
>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>
>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>> So it seems simple: create a dummy device that gets device and
>>> vendor id as properties. If you really like, add an option to get values
>>
>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>> at 00:1f.0.
>> But you guys don't like this, and shouldn't this be just this point we
>> discussing now?
>>
>> If you guys agree that , everything is fine.
>
> Actually, this isn't what you did.
> Don't tie it to xen, and don't tie it to 1f.
> Just make it a simple stub pci device.
> Whoever wants it, creates it.
>
> The thing I worry about, is the chance this will break going forward.
> So you created a system with 2 isa bridges.

I don't set class type to claim this is an ISA bridge, just a normal PCI 
device.

+static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice 
*hdev)
+{
+    struct PCIDevice *dev;
+
+    char rid;
+
+    /* We havt to use a simple PCI device to fake this ISA bridge
+     * to avoid making some confusion to BIOS and ACPI.
+     */
+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), 
"pseudo-intel-pch-isa-bridge");
+
+    qdev_init_nofail(&dev->qdev);
+
+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
+    pci_config_set_device_id(dev->config, hdev->device_id);
+
+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
+
+    pci_config_set_revision(dev->config, rid);
+
+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
+    return 0;
+}

> This is already not something that exists on real hardware.
> So it might break some guests that will get confused.
> Maybe we are lucky and most guests see an unfamiliar device
> and ignore it. It seems believable.
>
> But your MCH hack overrides registers in the pci host.

We just try to write *one* register we already confirm this is safe 
enough. Other register are read-only.

> Are we lucky and there's nothing in these registers
> of interest to guests? This seems much more fragile.
> So please poke at the spec, and compile the list
> of registers you want to touch, figure out why they are
> safe to override, and put this all in code comments.
>
> And the same thing that applies to the isa bridge

We just expose its own vendor/device ids here. We don't access to change 
anything in the isa bridge.

> applies here too. It should work without QEMU touching
> hosts' hardware.
>
>
>
>> >from sysfs: device and vendor id are world readable, so just get them
>>> directly and not through xen wrappers, this way you can open the files
>>> RO and not RW.
>>> You seem to poke at revision as well, I don't see
>>> driver looking at that - strictly necessary?
>>> If yes please patch host kernel to expose that info in sysfs,
>>> though we can fall back on pci config if not there.
>>>
>>> MCH (bridge_dev) hacks in i915 are nastier.
>>> To clean them up, we really have to have an explicit driver for this
>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>> likely to extend host driver and expose the necessary information in
>>> sysfs on host kernel.
>>>
>>>
>>
>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>> device, shouldn't it? So qemu still need to emulate this PCIe device
>> firstly, then set properties into sysfs.
>
> I am talking about getting host properties into qemu.
> You don't want to give qemu R/W root access to host sysfs system
> of the root bridge, that's not secure.

igd_pci_read()
	|
	+ xen_host_pci_get_block()
		|
		+ xen_host_pci_config_read(()
			|
			+  pread()

So shouldn't we already expose these information via sysfs?

> Avoiding read only access to filesystem is a good idea too, so it
> should be possible to pass all parameters in as
> device properties, and let whoever starts qemu
> figure out what are reasonable values.
>
>>>
>>>
>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>> this workable and consistently validated, this method shouldn't be virt
>>>> specific. Then native driver should use the same method.
>>>
>>> You mean you will be able to talk sense into hardware guys?
>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>
>> We're negotiating this, so this is just our long term solution we figure out
>> currently.
>>
>>> proper BAR, why didn't they?
>>
>> We already have no any free BAR as we mentioned previously.
>
> I thought you were talking about modifying hardware?

Yes.

Tiejun

>
>>>
>>>
>>>> So when xen work on
>>>> q35 PCIe machine, we can walk this way.
>>>
>>> If you are emulating MCH anyway, pick one that is close
>>> to what i915 driver expects. It would then work with existing
>>
>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>> to create a new based on i440fx just for a little change?
>>
>> Thanks
>> Tiejun
>
> You can inherit it. Maybe you are lucky and this happens to
> work without conflicting with whatever other guests want to do.
> But if you ask me, you are really just piling up hacks.
> If some guest does not work on i440, you should just work on
> emulating whatever it does work on.
> That would have real value.
>
>>> devices, without new capability IDs.
>>>
>>>
>>>> Anthony,
>>>>
>>>> Any comments to address this in xen case?
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>>
>
>

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>
>>>>>>>
>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>
>>>>>>
>>>>>> Are you saying the config space in the video device?
>>>>>
>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>> MMIO BAR.
>>>>>
>>>>
>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>> offset or BAR in the config space.
>>>>
>>>> And guy who are responsible for the native driver seems not be accept to
>>>> extend some magic offset of an existing MMIO BAR.
>>>>
>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>> q35 as a PCIe machine of xen.
>>>
>>> That seems like a weak motivation.  I don't see a need to get something
>>> merged upstream in a short time: this seems sure to miss 2.1,
>>> so you have the time to make it architecturally sound.
>>> "Making existing guests work" would be a better motivation.
>>
>> Yes.
>
> So focus on this then. Existing guests will probably work
> fine on a newer chipset - likely better than on i440fx.
> xen management tools need to do some work to support this?
> That will just give everyone more long term benefits.
>
> If instead we create a hack that does not resemble
> any existing hardware even remotely, what's the
> chance that it will not break with any future
> guest modification?
>
>
>>> Isn't this possible with an mch chipset?
>>
>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>> MCH in xen case.
>
> q35 or a newer chipset that's closer to what guests expect.
>
>> Additionally, I think I should follow this feature after
>> q35 can work for xen scenario.
>
> What's stopping you?

I mean if you want create an new machine based on q35, actually this is 
equal to start making xen to migrate to q35 now. Right? I can't image 
how much effort should be done.

So this is a reason why I'm saying I'd like to follow this feature after 
q35 can work with xen completely.

>
>>>
>>>
>>>> So could we do this step by step:
>>>>
>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>
>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>> So it seems simple: create a dummy device that gets device and
>>> vendor id as properties. If you really like, add an option to get values
>>
>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>> at 00:1f.0.
>> But you guys don't like this, and shouldn't this be just this point we
>> discussing now?
>>
>> If you guys agree that , everything is fine.
>
> Actually, this isn't what you did.
> Don't tie it to xen, and don't tie it to 1f.
> Just make it a simple stub pci device.
> Whoever wants it, creates it.
>
> The thing I worry about, is the chance this will break going forward.
> So you created a system with 2 isa bridges.

I don't set class type to claim this is an ISA bridge, just a normal PCI 
device.

+static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice 
*hdev)
+{
+    struct PCIDevice *dev;
+
+    char rid;
+
+    /* We havt to use a simple PCI device to fake this ISA bridge
+     * to avoid making some confusion to BIOS and ACPI.
+     */
+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0), 
"pseudo-intel-pch-isa-bridge");
+
+    qdev_init_nofail(&dev->qdev);
+
+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
+    pci_config_set_device_id(dev->config, hdev->device_id);
+
+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
+
+    pci_config_set_revision(dev->config, rid);
+
+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
+    return 0;
+}

> This is already not something that exists on real hardware.
> So it might break some guests that will get confused.
> Maybe we are lucky and most guests see an unfamiliar device
> and ignore it. It seems believable.
>
> But your MCH hack overrides registers in the pci host.

We just try to write *one* register we already confirm this is safe 
enough. Other register are read-only.

> Are we lucky and there's nothing in these registers
> of interest to guests? This seems much more fragile.
> So please poke at the spec, and compile the list
> of registers you want to touch, figure out why they are
> safe to override, and put this all in code comments.
>
> And the same thing that applies to the isa bridge

We just expose its own vendor/device ids here. We don't access to change 
anything in the isa bridge.

> applies here too. It should work without QEMU touching
> hosts' hardware.
>
>
>
>> >from sysfs: device and vendor id are world readable, so just get them
>>> directly and not through xen wrappers, this way you can open the files
>>> RO and not RW.
>>> You seem to poke at revision as well, I don't see
>>> driver looking at that - strictly necessary?
>>> If yes please patch host kernel to expose that info in sysfs,
>>> though we can fall back on pci config if not there.
>>>
>>> MCH (bridge_dev) hacks in i915 are nastier.
>>> To clean them up, we really have to have an explicit driver for this
>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>> likely to extend host driver and expose the necessary information in
>>> sysfs on host kernel.
>>>
>>>
>>
>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>> device, shouldn't it? So qemu still need to emulate this PCIe device
>> firstly, then set properties into sysfs.
>
> I am talking about getting host properties into qemu.
> You don't want to give qemu R/W root access to host sysfs system
> of the root bridge, that's not secure.

igd_pci_read()
	|
	+ xen_host_pci_get_block()
		|
		+ xen_host_pci_config_read(()
			|
			+  pread()

So shouldn't we already expose these information via sysfs?

> Avoiding read only access to filesystem is a good idea too, so it
> should be possible to pass all parameters in as
> device properties, and let whoever starts qemu
> figure out what are reasonable values.
>
>>>
>>>
>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>> this workable and consistently validated, this method shouldn't be virt
>>>> specific. Then native driver should use the same method.
>>>
>>> You mean you will be able to talk sense into hardware guys?
>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>
>> We're negotiating this, so this is just our long term solution we figure out
>> currently.
>>
>>> proper BAR, why didn't they?
>>
>> We already have no any free BAR as we mentioned previously.
>
> I thought you were talking about modifying hardware?

Yes.

Tiejun

>
>>>
>>>
>>>> So when xen work on
>>>> q35 PCIe machine, we can walk this way.
>>>
>>> If you are emulating MCH anyway, pick one that is close
>>> to what i915 driver expects. It would then work with existing
>>
>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>> to create a new based on i440fx just for a little change?
>>
>> Thanks
>> Tiejun
>
> You can inherit it. Maybe you are lucky and this happens to
> work without conflicting with whatever other guests want to do.
> But if you ask me, you are really just piling up hacks.
> If some guest does not work on i440, you should just work on
> emulating whatever it does work on.
> That would have real value.
>
>>> devices, without new capability IDs.
>>>
>>>
>>>> Anthony,
>>>>
>>>> Any comments to address this in xen case?
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>>
>
>

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>
> >>>>>>>
> >>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>
> >>>>>>
> >>>>>>Are you saying the config space in the video device?
> >>>>>
> >>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>MMIO BAR.
> >>>>>
> >>>>
> >>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>offset or BAR in the config space.
> >>>>
> >>>>And guy who are responsible for the native driver seems not be accept to
> >>>>extend some magic offset of an existing MMIO BAR.
> >>>>
> >>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>q35 as a PCIe machine of xen.
> >>>
> >>>That seems like a weak motivation.  I don't see a need to get something
> >>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>so you have the time to make it architecturally sound.
> >>>"Making existing guests work" would be a better motivation.
> >>
> >>Yes.
> >
> >So focus on this then. Existing guests will probably work
> >fine on a newer chipset - likely better than on i440fx.
> >xen management tools need to do some work to support this?
> >That will just give everyone more long term benefits.
> >
> >If instead we create a hack that does not resemble
> >any existing hardware even remotely, what's the
> >chance that it will not break with any future
> >guest modification?
> >
> >
> >>>Isn't this possible with an mch chipset?
> >>
> >>If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> >>MCH in xen case.
> >
> >q35 or a newer chipset that's closer to what guests expect.
> >
> >>Additionally, I think I should follow this feature after
> >>q35 can work for xen scenario.
> >
> >What's stopping you?
> 
> I mean if you want create an new machine based on q35, actually this is
> equal to start making xen to migrate to q35 now. Right? I can't image how
> much effort should be done.

I don't see why you don't try. Sounds like a more robust solution to me.

> So this is a reason why I'm saying I'd like to follow this feature after q35
> can work with xen completely.

Then we'll end up with more configurations to support, and to what end?

> >
> >>>
> >>>
> >>>>So could we do this step by step:
> >>>>
> >>>>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>>>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >>>
> >>>By the way there is no reason to put it at 00:1f.0 specifically I think.
> >>>So it seems simple: create a dummy device that gets device and
> >>>vendor id as properties. If you really like, add an option to get values
> >>
> >>Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> >>passthrough: create pseudo intel isa bridge. There, we fake this device just
> >>at 00:1f.0.
> >>But you guys don't like this, and shouldn't this be just this point we
> >>discussing now?
> >>
> >>If you guys agree that , everything is fine.
> >
> >Actually, this isn't what you did.
> >Don't tie it to xen, and don't tie it to 1f.
> >Just make it a simple stub pci device.
> >Whoever wants it, creates it.
> >
> >The thing I worry about, is the chance this will break going forward.
> >So you created a system with 2 isa bridges.
> 
> I don't set class type to claim this is an ISA bridge, just a normal PCI
> device.
> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
> *hdev)
> +{
> +    struct PCIDevice *dev;
> +
> +    char rid;
> +
> +    /* We havt to use a simple PCI device to fake this ISA bridge
> +     * to avoid making some confusion to BIOS and ACPI.
> +     */
> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
> "pseudo-intel-pch-isa-bridge");
> +
> +    qdev_init_nofail(&dev->qdev);
> +
> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> +    pci_config_set_device_id(dev->config, hdev->device_id);
> +
> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> +
> +    pci_config_set_revision(dev->config, rid);
> +
> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> +    return 0;
> +}

Then I don't see how it's supposed to work.
Doesn't i915 look for an isa bridge?

        /*
         * The reason to probe ISA bridge instead of Dev31:Fun0 is to
         * make graphics device passthrough work easy for VMM, that only
         * need to expose ISA bridge to let driver know the real hardware
         * underneath. This is a requirement from virtualization team.
         *
         * In some virtualized environments (e.g. XEN), there is irrelevant
         * ISA bridge in the system. To work reliably, we should scan trhough
         * all the ISA bridge devices and check for the first match, instead
         * of only checking the first one.
         */
        while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
                if (pch->vendor == PCI_VENDOR_ID_INTEL) {
                        unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
                        dev_priv->pch_id = id;

                        if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
                                dev_priv->pch_type = PCH_IBX;

etc



> >This is already not something that exists on real hardware.
> >So it might break some guests that will get confused.
> >Maybe we are lucky and most guests see an unfamiliar device
> >and ignore it. It seems believable.
> >
> >But your MCH hack overrides registers in the pci host.
> 
> We just try to write *one* register we already confirm this is safe enough.

This should go in code in form of comments:
document what this register does on 440fx
and why it's safe to override.
We don't see what you
confirmed off-line.

> Other register are read-only.

Doesn't matter, need to document these as well.

> >Are we lucky and there's nothing in these registers
> >of interest to guests? This seems much more fragile.
> >So please poke at the spec, and compile the list
> >of registers you want to touch, figure out why they are
> >safe to override, and put this all in code comments.
> >
> >And the same thing that applies to the isa bridge
> 
> We just expose its own vendor/device ids here. We don't access to change
> anything in the isa bridge.
> 
> >applies here too. It should work without QEMU touching
> >hosts' hardware.
> >
> >
> >
> >>>from sysfs: device and vendor id are world readable, so just get them
> >>>directly and not through xen wrappers, this way you can open the files
> >>>RO and not RW.
> >>>You seem to poke at revision as well, I don't see
> >>>driver looking at that - strictly necessary?
> >>>If yes please patch host kernel to expose that info in sysfs,
> >>>though we can fall back on pci config if not there.
> >>>
> >>>MCH (bridge_dev) hacks in i915 are nastier.
> >>>To clean them up, we really have to have an explicit driver for this
> >>>bridge, not a pass-through device.  Long term, the right thing to do is
> >>>likely to extend host driver and expose the necessary information in
> >>>sysfs on host kernel.
> >>>
> >>>
> >>
> >>I'm a bit confused. Any sysfs should be filled by the associated PCIe
> >>device, shouldn't it? So qemu still need to emulate this PCIe device
> >>firstly, then set properties into sysfs.
> >
> >I am talking about getting host properties into qemu.
> >You don't want to give qemu R/W root access to host sysfs system
> >of the root bridge, that's not secure.
> 
> igd_pci_read()
> 	|
> 	+ xen_host_pci_get_block()
> 		|
> 		+ xen_host_pci_config_read(()
> 			|
> 			+  pread()
> 
> So shouldn't we already expose these information via sysfs?

That's poking at sysfs of a real device, and after opening it RW.

> >Avoiding read only access to filesystem is a good idea too, so it
> >should be possible to pass all parameters in as
> >device properties, and let whoever starts qemu
> >figure out what are reasonable values.
> >
> >>>
> >>>
> >>>>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>>>others. To do this properly, we need to get one from PCI SIG group. To have
> >>>>this workable and consistently validated, this method shouldn't be virt
> >>>>specific. Then native driver should use the same method.
> >>>
> >>>You mean you will be able to talk sense into hardware guys?
> >>>I doubt that. If they could be convinced to make e.g. i915 base a
> >>
> >>We're negotiating this, so this is just our long term solution we figure out
> >>currently.
> >>
> >>>proper BAR, why didn't they?
> >>
> >>We already have no any free BAR as we mentioned previously.
> >
> >I thought you were talking about modifying hardware?
> 
> Yes.
> 
> Tiejun

And they can't figure out how to stick extra info in an existing BAR?
Oh well, that's hardware for you.

> >
> >>>
> >>>
> >>>>So when xen work on
> >>>>q35 PCIe machine, we can walk this way.
> >>>
> >>>If you are emulating MCH anyway, pick one that is close
> >>>to what i915 driver expects. It would then work with existing
> >>
> >>Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> >>to create a new based on i440fx just for a little change?
> >>
> >>Thanks
> >>Tiejun
> >
> >You can inherit it. Maybe you are lucky and this happens to
> >work without conflicting with whatever other guests want to do.
> >But if you ask me, you are really just piling up hacks.
> >If some guest does not work on i440, you should just work on
> >emulating whatever it does work on.
> >That would have real value.
> >
> >>>devices, without new capability IDs.
> >>>
> >>>
> >>>>Anthony,
> >>>>
> >>>>Any comments to address this in xen case?
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>
> >
> >

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>
> >>>>>>>
> >>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>
> >>>>>>
> >>>>>>Are you saying the config space in the video device?
> >>>>>
> >>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>MMIO BAR.
> >>>>>
> >>>>
> >>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>offset or BAR in the config space.
> >>>>
> >>>>And guy who are responsible for the native driver seems not be accept to
> >>>>extend some magic offset of an existing MMIO BAR.
> >>>>
> >>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>q35 as a PCIe machine of xen.
> >>>
> >>>That seems like a weak motivation.  I don't see a need to get something
> >>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>so you have the time to make it architecturally sound.
> >>>"Making existing guests work" would be a better motivation.
> >>
> >>Yes.
> >
> >So focus on this then. Existing guests will probably work
> >fine on a newer chipset - likely better than on i440fx.
> >xen management tools need to do some work to support this?
> >That will just give everyone more long term benefits.
> >
> >If instead we create a hack that does not resemble
> >any existing hardware even remotely, what's the
> >chance that it will not break with any future
> >guest modification?
> >
> >
> >>>Isn't this possible with an mch chipset?
> >>
> >>If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> >>MCH in xen case.
> >
> >q35 or a newer chipset that's closer to what guests expect.
> >
> >>Additionally, I think I should follow this feature after
> >>q35 can work for xen scenario.
> >
> >What's stopping you?
> 
> I mean if you want create an new machine based on q35, actually this is
> equal to start making xen to migrate to q35 now. Right? I can't image how
> much effort should be done.

I don't see why you don't try. Sounds like a more robust solution to me.

> So this is a reason why I'm saying I'd like to follow this feature after q35
> can work with xen completely.

Then we'll end up with more configurations to support, and to what end?

> >
> >>>
> >>>
> >>>>So could we do this step by step:
> >>>>
> >>>>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>>>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >>>
> >>>By the way there is no reason to put it at 00:1f.0 specifically I think.
> >>>So it seems simple: create a dummy device that gets device and
> >>>vendor id as properties. If you really like, add an option to get values
> >>
> >>Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> >>passthrough: create pseudo intel isa bridge. There, we fake this device just
> >>at 00:1f.0.
> >>But you guys don't like this, and shouldn't this be just this point we
> >>discussing now?
> >>
> >>If you guys agree that , everything is fine.
> >
> >Actually, this isn't what you did.
> >Don't tie it to xen, and don't tie it to 1f.
> >Just make it a simple stub pci device.
> >Whoever wants it, creates it.
> >
> >The thing I worry about, is the chance this will break going forward.
> >So you created a system with 2 isa bridges.
> 
> I don't set class type to claim this is an ISA bridge, just a normal PCI
> device.
> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
> *hdev)
> +{
> +    struct PCIDevice *dev;
> +
> +    char rid;
> +
> +    /* We havt to use a simple PCI device to fake this ISA bridge
> +     * to avoid making some confusion to BIOS and ACPI.
> +     */
> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
> "pseudo-intel-pch-isa-bridge");
> +
> +    qdev_init_nofail(&dev->qdev);
> +
> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> +    pci_config_set_device_id(dev->config, hdev->device_id);
> +
> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> +
> +    pci_config_set_revision(dev->config, rid);
> +
> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> +    return 0;
> +}

Then I don't see how it's supposed to work.
Doesn't i915 look for an isa bridge?

        /*
         * The reason to probe ISA bridge instead of Dev31:Fun0 is to
         * make graphics device passthrough work easy for VMM, that only
         * need to expose ISA bridge to let driver know the real hardware
         * underneath. This is a requirement from virtualization team.
         *
         * In some virtualized environments (e.g. XEN), there is irrelevant
         * ISA bridge in the system. To work reliably, we should scan trhough
         * all the ISA bridge devices and check for the first match, instead
         * of only checking the first one.
         */
        while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
                if (pch->vendor == PCI_VENDOR_ID_INTEL) {
                        unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
                        dev_priv->pch_id = id;

                        if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
                                dev_priv->pch_type = PCH_IBX;

etc



> >This is already not something that exists on real hardware.
> >So it might break some guests that will get confused.
> >Maybe we are lucky and most guests see an unfamiliar device
> >and ignore it. It seems believable.
> >
> >But your MCH hack overrides registers in the pci host.
> 
> We just try to write *one* register we already confirm this is safe enough.

This should go in code in form of comments:
document what this register does on 440fx
and why it's safe to override.
We don't see what you
confirmed off-line.

> Other register are read-only.

Doesn't matter, need to document these as well.

> >Are we lucky and there's nothing in these registers
> >of interest to guests? This seems much more fragile.
> >So please poke at the spec, and compile the list
> >of registers you want to touch, figure out why they are
> >safe to override, and put this all in code comments.
> >
> >And the same thing that applies to the isa bridge
> 
> We just expose its own vendor/device ids here. We don't access to change
> anything in the isa bridge.
> 
> >applies here too. It should work without QEMU touching
> >hosts' hardware.
> >
> >
> >
> >>>from sysfs: device and vendor id are world readable, so just get them
> >>>directly and not through xen wrappers, this way you can open the files
> >>>RO and not RW.
> >>>You seem to poke at revision as well, I don't see
> >>>driver looking at that - strictly necessary?
> >>>If yes please patch host kernel to expose that info in sysfs,
> >>>though we can fall back on pci config if not there.
> >>>
> >>>MCH (bridge_dev) hacks in i915 are nastier.
> >>>To clean them up, we really have to have an explicit driver for this
> >>>bridge, not a pass-through device.  Long term, the right thing to do is
> >>>likely to extend host driver and expose the necessary information in
> >>>sysfs on host kernel.
> >>>
> >>>
> >>
> >>I'm a bit confused. Any sysfs should be filled by the associated PCIe
> >>device, shouldn't it? So qemu still need to emulate this PCIe device
> >>firstly, then set properties into sysfs.
> >
> >I am talking about getting host properties into qemu.
> >You don't want to give qemu R/W root access to host sysfs system
> >of the root bridge, that's not secure.
> 
> igd_pci_read()
> 	|
> 	+ xen_host_pci_get_block()
> 		|
> 		+ xen_host_pci_config_read(()
> 			|
> 			+  pread()
> 
> So shouldn't we already expose these information via sysfs?

That's poking at sysfs of a real device, and after opening it RW.

> >Avoiding read only access to filesystem is a good idea too, so it
> >should be possible to pass all parameters in as
> >device properties, and let whoever starts qemu
> >figure out what are reasonable values.
> >
> >>>
> >>>
> >>>>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>>>others. To do this properly, we need to get one from PCI SIG group. To have
> >>>>this workable and consistently validated, this method shouldn't be virt
> >>>>specific. Then native driver should use the same method.
> >>>
> >>>You mean you will be able to talk sense into hardware guys?
> >>>I doubt that. If they could be convinced to make e.g. i915 base a
> >>
> >>We're negotiating this, so this is just our long term solution we figure out
> >>currently.
> >>
> >>>proper BAR, why didn't they?
> >>
> >>We already have no any free BAR as we mentioned previously.
> >
> >I thought you were talking about modifying hardware?
> 
> Yes.
> 
> Tiejun

And they can't figure out how to stick extra info in an existing BAR?
Oh well, that's hardware for you.

> >
> >>>
> >>>
> >>>>So when xen work on
> >>>>q35 PCIe machine, we can walk this way.
> >>>
> >>>If you are emulating MCH anyway, pick one that is close
> >>>to what i915 driver expects. It would then work with existing
> >>
> >>Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> >>to create a new based on i440fx just for a little change?
> >>
> >>Thanks
> >>Tiejun
> >
> >You can inherit it. Maybe you are lucky and this happens to
> >work without conflicting with whatever other guests want to do.
> >But if you ask me, you are really just piling up hacks.
> >If some guest does not work on i440, you should just work on
> >emulating whatever it does work on.
> >That would have real value.
> >
> >>>devices, without new capability IDs.
> >>>
> >>>
> >>>>Anthony,
> >>>>
> >>>>Any comments to address this in xen case?
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>
> >
> >

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/30 17:55, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
>> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>
>>>>>>>>
>>>>>>>> Are you saying the config space in the video device?
>>>>>>>
>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>> MMIO BAR.
>>>>>>>
>>>>>>
>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>> offset or BAR in the config space.
>>>>>>
>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>
>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>> q35 as a PCIe machine of xen.
>>>>>
>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>> so you have the time to make it architecturally sound.
>>>>> "Making existing guests work" would be a better motivation.
>>>>
>>>> Yes.
>>>
>>> So focus on this then. Existing guests will probably work
>>> fine on a newer chipset - likely better than on i440fx.
>>> xen management tools need to do some work to support this?
>>> That will just give everyone more long term benefits.
>>>
>>> If instead we create a hack that does not resemble
>>> any existing hardware even remotely, what's the
>>> chance that it will not break with any future
>>> guest modification?
>>>
>>>
>>>>> Isn't this possible with an mch chipset?
>>>>
>>>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>>>> MCH in xen case.
>>>
>>> q35 or a newer chipset that's closer to what guests expect.
>>>
>>>> Additionally, I think I should follow this feature after
>>>> q35 can work for xen scenario.
>>>
>>> What's stopping you?
>>
>> I mean if you want create an new machine based on q35, actually this is
>> equal to start making xen to migrate to q35 now. Right? I can't image how
>> much effort should be done.
>
> I don't see why you don't try. Sounds like a more robust solution to me.

As I think this is another requirement to us. I'm not sure if I have 
enough time to touch this currently.

>
>> So this is a reason why I'm saying I'd like to follow this feature after q35
>> can work with xen completely.
>
> Then we'll end up with more configurations to support, and to what end?
>
>>>
>>>>>
>>>>>
>>>>>> So could we do this step by step:
>>>>>>
>>>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>>>
>>>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>>>> So it seems simple: create a dummy device that gets device and
>>>>> vendor id as properties. If you really like, add an option to get values
>>>>
>>>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>>>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>>>> at 00:1f.0.
>>>> But you guys don't like this, and shouldn't this be just this point we
>>>> discussing now?
>>>>
>>>> If you guys agree that , everything is fine.
>>>
>>> Actually, this isn't what you did.
>>> Don't tie it to xen, and don't tie it to 1f.
>>> Just make it a simple stub pci device.
>>> Whoever wants it, creates it.
>>>
>>> The thing I worry about, is the chance this will break going forward.
>>> So you created a system with 2 isa bridges.
>>
>> I don't set class type to claim this is an ISA bridge, just a normal PCI
>> device.
>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>> *hdev)
>> +{
>> +    struct PCIDevice *dev;
>> +
>> +    char rid;
>> +
>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>> +     * to avoid making some confusion to BIOS and ACPI.
>> +     */
>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>> "pseudo-intel-pch-isa-bridge");
>> +
>> +    qdev_init_nofail(&dev->qdev);
>> +
>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>> +
>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>> +
>> +    pci_config_set_revision(dev->config, rid);
>> +
>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>> +    return 0;
>> +}
>
> Then I don't see how it's supposed to work.
> Doesn't i915 look for an isa bridge?
>
>          /*
>           * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>           * make graphics device passthrough work easy for VMM, that only
>           * need to expose ISA bridge to let driver know the real hardware
>           * underneath. This is a requirement from virtualization team.
>           *
>           * In some virtualized environments (e.g. XEN), there is irrelevant
>           * ISA bridge in the system. To work reliably, we should scan trhough
>           * all the ISA bridge devices and check for the first match, instead
>           * of only checking the first one.
>           */
>          while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>                  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>                          unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>                          dev_priv->pch_id = id;
>
>                          if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>                                  dev_priv->pch_type = PCH_IBX;
>
> etc
>

I already post this to mainline to change as follows:

-	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
+	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
+	if (pch) {

Please refer to this,

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead 
of check class type

Linux Native guys would like to accept this. And actually Windows always 
use devfn to detect this.

>
>
>>> This is already not something that exists on real hardware.
>>> So it might break some guests that will get confused.
>>> Maybe we are lucky and most guests see an unfamiliar device
>>> and ignore it. It seems believable.
>>>
>>> But your MCH hack overrides registers in the pci host.
>>
>> We just try to write *one* register we already confirm this is safe enough.
>
> This should go in code in form of comments:
> document what this register does on 440fx
> and why it's safe to override.
> We don't see what you
> confirmed off-line.

That offset is one specific to IGD usage, not for i440fx common. This is 
why we need to expose something in the host bridge. They're just 
introduced to support IGD.

>
>> Other register are read-only.
>
> Doesn't matter, need to document these as well.

I think everything are covered in igd_pci_write()/igd_pci_write().

>
>>> Are we lucky and there's nothing in these registers
>>> of interest to guests? This seems much more fragile.
>>> So please poke at the spec, and compile the list
>>> of registers you want to touch, figure out why they are
>>> safe to override, and put this all in code comments.
>>>
>>> And the same thing that applies to the isa bridge
>>
>> We just expose its own vendor/device ids here. We don't access to change
>> anything in the isa bridge.
>>
>>> applies here too. It should work without QEMU touching
>>> hosts' hardware.
>>>
>>>
>>>
>>>> >from sysfs: device and vendor id are world readable, so just get them
>>>>> directly and not through xen wrappers, this way you can open the files
>>>>> RO and not RW.
>>>>> You seem to poke at revision as well, I don't see
>>>>> driver looking at that - strictly necessary?
>>>>> If yes please patch host kernel to expose that info in sysfs,
>>>>> though we can fall back on pci config if not there.
>>>>>
>>>>> MCH (bridge_dev) hacks in i915 are nastier.
>>>>> To clean them up, we really have to have an explicit driver for this
>>>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>>>> likely to extend host driver and expose the necessary information in
>>>>> sysfs on host kernel.
>>>>>
>>>>>
>>>>
>>>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>>>> device, shouldn't it? So qemu still need to emulate this PCIe device
>>>> firstly, then set properties into sysfs.
>>>
>>> I am talking about getting host properties into qemu.
>>> You don't want to give qemu R/W root access to host sysfs system
>>> of the root bridge, that's not secure.
>>
>> igd_pci_read()
>> 	|
>> 	+ xen_host_pci_get_block()
>> 		|
>> 		+ xen_host_pci_config_read(()
>> 			|
>> 			+  pread()
>>
>> So shouldn't we already expose these information via sysfs?
>
> That's poking at sysfs of a real device, and after opening it RW.

I don't think we can really write anything to those read-only sysfs 
interface even we open them as RW.

Tiejun

>
>>> Avoiding read only access to filesystem is a good idea too, so it
>>> should be possible to pass all parameters in as
>>> device properties, and let whoever starts qemu
>>> figure out what are reasonable values.
>>>
>>>>>
>>>>>
>>>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>>>> this workable and consistently validated, this method shouldn't be virt
>>>>>> specific. Then native driver should use the same method.
>>>>>
>>>>> You mean you will be able to talk sense into hardware guys?
>>>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>>>
>>>> We're negotiating this, so this is just our long term solution we figure out
>>>> currently.
>>>>
>>>>> proper BAR, why didn't they?
>>>>
>>>> We already have no any free BAR as we mentioned previously.
>>>
>>> I thought you were talking about modifying hardware?
>>
>> Yes.
>>
>> Tiejun
>
> And they can't figure out how to stick extra info in an existing BAR?
> Oh well, that's hardware for you.
>
>>>
>>>>>
>>>>>
>>>>>> So when xen work on
>>>>>> q35 PCIe machine, we can walk this way.
>>>>>
>>>>> If you are emulating MCH anyway, pick one that is close
>>>>> to what i915 driver expects. It would then work with existing
>>>>
>>>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>>>> to create a new based on i440fx just for a little change?
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> You can inherit it. Maybe you are lucky and this happens to
>>> work without conflicting with whatever other guests want to do.
>>> But if you ask me, you are really just piling up hacks.
>>> If some guest does not work on i440, you should just work on
>>> emulating whatever it does work on.
>>> That would have real value.
>>>
>>>>> devices, without new capability IDs.
>>>>>
>>>>>
>>>>>> Anthony,
>>>>>>
>>>>>> Any comments to address this in xen case?
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>>
>>>
>>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/30 17:55, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
>> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>
>>>>>>>>
>>>>>>>> Are you saying the config space in the video device?
>>>>>>>
>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>> MMIO BAR.
>>>>>>>
>>>>>>
>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>> offset or BAR in the config space.
>>>>>>
>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>
>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>> q35 as a PCIe machine of xen.
>>>>>
>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>> so you have the time to make it architecturally sound.
>>>>> "Making existing guests work" would be a better motivation.
>>>>
>>>> Yes.
>>>
>>> So focus on this then. Existing guests will probably work
>>> fine on a newer chipset - likely better than on i440fx.
>>> xen management tools need to do some work to support this?
>>> That will just give everyone more long term benefits.
>>>
>>> If instead we create a hack that does not resemble
>>> any existing hardware even remotely, what's the
>>> chance that it will not break with any future
>>> guest modification?
>>>
>>>
>>>>> Isn't this possible with an mch chipset?
>>>>
>>>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>>>> MCH in xen case.
>>>
>>> q35 or a newer chipset that's closer to what guests expect.
>>>
>>>> Additionally, I think I should follow this feature after
>>>> q35 can work for xen scenario.
>>>
>>> What's stopping you?
>>
>> I mean if you want create an new machine based on q35, actually this is
>> equal to start making xen to migrate to q35 now. Right? I can't image how
>> much effort should be done.
>
> I don't see why you don't try. Sounds like a more robust solution to me.

As I think this is another requirement to us. I'm not sure if I have 
enough time to touch this currently.

>
>> So this is a reason why I'm saying I'd like to follow this feature after q35
>> can work with xen completely.
>
> Then we'll end up with more configurations to support, and to what end?
>
>>>
>>>>>
>>>>>
>>>>>> So could we do this step by step:
>>>>>>
>>>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>>>
>>>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>>>> So it seems simple: create a dummy device that gets device and
>>>>> vendor id as properties. If you really like, add an option to get values
>>>>
>>>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>>>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>>>> at 00:1f.0.
>>>> But you guys don't like this, and shouldn't this be just this point we
>>>> discussing now?
>>>>
>>>> If you guys agree that , everything is fine.
>>>
>>> Actually, this isn't what you did.
>>> Don't tie it to xen, and don't tie it to 1f.
>>> Just make it a simple stub pci device.
>>> Whoever wants it, creates it.
>>>
>>> The thing I worry about, is the chance this will break going forward.
>>> So you created a system with 2 isa bridges.
>>
>> I don't set class type to claim this is an ISA bridge, just a normal PCI
>> device.
>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>> *hdev)
>> +{
>> +    struct PCIDevice *dev;
>> +
>> +    char rid;
>> +
>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>> +     * to avoid making some confusion to BIOS and ACPI.
>> +     */
>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>> "pseudo-intel-pch-isa-bridge");
>> +
>> +    qdev_init_nofail(&dev->qdev);
>> +
>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>> +
>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>> +
>> +    pci_config_set_revision(dev->config, rid);
>> +
>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>> +    return 0;
>> +}
>
> Then I don't see how it's supposed to work.
> Doesn't i915 look for an isa bridge?
>
>          /*
>           * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>           * make graphics device passthrough work easy for VMM, that only
>           * need to expose ISA bridge to let driver know the real hardware
>           * underneath. This is a requirement from virtualization team.
>           *
>           * In some virtualized environments (e.g. XEN), there is irrelevant
>           * ISA bridge in the system. To work reliably, we should scan trhough
>           * all the ISA bridge devices and check for the first match, instead
>           * of only checking the first one.
>           */
>          while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>                  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>                          unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>                          dev_priv->pch_id = id;
>
>                          if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>                                  dev_priv->pch_type = PCH_IBX;
>
> etc
>

I already post this to mainline to change as follows:

-	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
+	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
+	if (pch) {

Please refer to this,

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead 
of check class type

Linux Native guys would like to accept this. And actually Windows always 
use devfn to detect this.

>
>
>>> This is already not something that exists on real hardware.
>>> So it might break some guests that will get confused.
>>> Maybe we are lucky and most guests see an unfamiliar device
>>> and ignore it. It seems believable.
>>>
>>> But your MCH hack overrides registers in the pci host.
>>
>> We just try to write *one* register we already confirm this is safe enough.
>
> This should go in code in form of comments:
> document what this register does on 440fx
> and why it's safe to override.
> We don't see what you
> confirmed off-line.

That offset is one specific to IGD usage, not for i440fx common. This is 
why we need to expose something in the host bridge. They're just 
introduced to support IGD.

>
>> Other register are read-only.
>
> Doesn't matter, need to document these as well.

I think everything are covered in igd_pci_write()/igd_pci_write().

>
>>> Are we lucky and there's nothing in these registers
>>> of interest to guests? This seems much more fragile.
>>> So please poke at the spec, and compile the list
>>> of registers you want to touch, figure out why they are
>>> safe to override, and put this all in code comments.
>>>
>>> And the same thing that applies to the isa bridge
>>
>> We just expose its own vendor/device ids here. We don't access to change
>> anything in the isa bridge.
>>
>>> applies here too. It should work without QEMU touching
>>> hosts' hardware.
>>>
>>>
>>>
>>>> >from sysfs: device and vendor id are world readable, so just get them
>>>>> directly and not through xen wrappers, this way you can open the files
>>>>> RO and not RW.
>>>>> You seem to poke at revision as well, I don't see
>>>>> driver looking at that - strictly necessary?
>>>>> If yes please patch host kernel to expose that info in sysfs,
>>>>> though we can fall back on pci config if not there.
>>>>>
>>>>> MCH (bridge_dev) hacks in i915 are nastier.
>>>>> To clean them up, we really have to have an explicit driver for this
>>>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>>>> likely to extend host driver and expose the necessary information in
>>>>> sysfs on host kernel.
>>>>>
>>>>>
>>>>
>>>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>>>> device, shouldn't it? So qemu still need to emulate this PCIe device
>>>> firstly, then set properties into sysfs.
>>>
>>> I am talking about getting host properties into qemu.
>>> You don't want to give qemu R/W root access to host sysfs system
>>> of the root bridge, that's not secure.
>>
>> igd_pci_read()
>> 	|
>> 	+ xen_host_pci_get_block()
>> 		|
>> 		+ xen_host_pci_config_read(()
>> 			|
>> 			+  pread()
>>
>> So shouldn't we already expose these information via sysfs?
>
> That's poking at sysfs of a real device, and after opening it RW.

I don't think we can really write anything to those read-only sysfs 
interface even we open them as RW.

Tiejun

>
>>> Avoiding read only access to filesystem is a good idea too, so it
>>> should be possible to pass all parameters in as
>>> device properties, and let whoever starts qemu
>>> figure out what are reasonable values.
>>>
>>>>>
>>>>>
>>>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>>>> this workable and consistently validated, this method shouldn't be virt
>>>>>> specific. Then native driver should use the same method.
>>>>>
>>>>> You mean you will be able to talk sense into hardware guys?
>>>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>>>
>>>> We're negotiating this, so this is just our long term solution we figure out
>>>> currently.
>>>>
>>>>> proper BAR, why didn't they?
>>>>
>>>> We already have no any free BAR as we mentioned previously.
>>>
>>> I thought you were talking about modifying hardware?
>>
>> Yes.
>>
>> Tiejun
>
> And they can't figure out how to stick extra info in an existing BAR?
> Oh well, that's hardware for you.
>
>>>
>>>>>
>>>>>
>>>>>> So when xen work on
>>>>>> q35 PCIe machine, we can walk this way.
>>>>>
>>>>> If you are emulating MCH anyway, pick one that is close
>>>>> to what i915 driver expects. It would then work with existing
>>>>
>>>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>>>> to create a new based on i440fx just for a little change?
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> You can inherit it. Maybe you are lucky and this happens to
>>> work without conflicting with whatever other guests want to do.
>>> But if you ask me, you are really just piling up hacks.
>>> If some guest does not work on i440, you should just work on
>>> emulating whatever it does work on.
>>> That would have real value.
>>>
>>>>> devices, without new capability IDs.
>>>>>
>>>>>
>>>>>> Anthony,
>>>>>>
>>>>>> Any comments to address this in xen case?
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>>
>>>
>>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 30/06/2014 12:20, Chen, Tiejun ha scritto:
>
> I already post this to mainline to change as follows:
>
> -    while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> +    pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> +    if (pch) {
>
> Please refer to this,
>
> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead
> of check class type
>
> Linux Native guys would like to accept this. And actually Windows always
> use devfn to detect this.

Fair enough, but that means that, when using IGD, Q35 will have to move 
the ISA bridge off 1f.0.

To me it seems fairly clear that as things stand IGD is not 
virtualizable without PV support.  We're beating a dead horse.

Paolo

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 30/06/2014 12:20, Chen, Tiejun ha scritto:
>
> I already post this to mainline to change as follows:
>
> -    while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> +    pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> +    if (pch) {
>
> Please refer to this,
>
> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead
> of check class type
>
> Linux Native guys would like to accept this. And actually Windows always
> use devfn to detect this.

Fair enough, but that means that, when using IGD, Q35 will have to move 
the ISA bridge off 1f.0.

To me it seems fairly clear that as things stand IGD is not 
virtualizable without PV support.  We're beating a dead horse.

Paolo

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 01:18:51PM +0200, Paolo Bonzini wrote:
> Il 30/06/2014 12:20, Chen, Tiejun ha scritto:
> >
> >I already post this to mainline to change as follows:
> >
> >-    while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >+    pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> >+    if (pch) {
> >
> >Please refer to this,
> >
> >[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead
> >of check class type
> >
> >Linux Native guys would like to accept this. And actually Windows always
> >use devfn to detect this.
> 
> Fair enough, but that means that, when using IGD, Q35 will have to move the
> ISA bridge off 1f.0.
> 
> To me it seems fairly clear that as things stand IGD is not virtualizable
> without PV support.  We're beating a dead horse.
> 
> Paolo

It seems virtualizeable without PV.  Virtualizing it just requires
emulating a chipset that's closer to what the driver expects,
which seems to be more effort than Tiejun is prepared to put in.

-- 
MST

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 01:18:51PM +0200, Paolo Bonzini wrote:
> Il 30/06/2014 12:20, Chen, Tiejun ha scritto:
> >
> >I already post this to mainline to change as follows:
> >
> >-    while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >+    pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> >+    if (pch) {
> >
> >Please refer to this,
> >
> >[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead
> >of check class type
> >
> >Linux Native guys would like to accept this. And actually Windows always
> >use devfn to detect this.
> 
> Fair enough, but that means that, when using IGD, Q35 will have to move the
> ISA bridge off 1f.0.
> 
> To me it seems fairly clear that as things stand IGD is not virtualizable
> without PV support.  We're beating a dead horse.
> 
> Paolo

It seems virtualizeable without PV.  Virtualizing it just requires
emulating a chipset that's closer to what the driver expects,
which seems to be more effort than Tiejun is prepared to put in.

-- 
MST

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
> On 2014/6/30 17:55, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>Are you saying the config space in the video device?
> >>>>>>>
> >>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>MMIO BAR.
> >>>>>>>
> >>>>>>
> >>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>offset or BAR in the config space.
> >>>>>>
> >>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>
> >>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>q35 as a PCIe machine of xen.
> >>>>>
> >>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>so you have the time to make it architecturally sound.
> >>>>>"Making existing guests work" would be a better motivation.
> >>>>
> >>>>Yes.
> >>>
> >>>So focus on this then. Existing guests will probably work
> >>>fine on a newer chipset - likely better than on i440fx.
> >>>xen management tools need to do some work to support this?
> >>>That will just give everyone more long term benefits.
> >>>
> >>>If instead we create a hack that does not resemble
> >>>any existing hardware even remotely, what's the
> >>>chance that it will not break with any future
> >>>guest modification?
> >>>
> >>>
> >>>>>Isn't this possible with an mch chipset?
> >>>>
> >>>>If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> >>>>MCH in xen case.
> >>>
> >>>q35 or a newer chipset that's closer to what guests expect.
> >>>
> >>>>Additionally, I think I should follow this feature after
> >>>>q35 can work for xen scenario.
> >>>
> >>>What's stopping you?
> >>
> >>I mean if you want create an new machine based on q35, actually this is
> >>equal to start making xen to migrate to q35 now. Right? I can't image how
> >>much effort should be done.
> >
> >I don't see why you don't try. Sounds like a more robust solution to me.
> 
> As I think this is another requirement to us. I'm not sure if I have enough
> time to touch this currently.
> 
> >
> >>So this is a reason why I'm saying I'd like to follow this feature after q35
> >>can work with xen completely.
> >
> >Then we'll end up with more configurations to support, and to what end?
> >
> >>>
> >>>>>
> >>>>>
> >>>>>>So could we do this step by step:
> >>>>>>
> >>>>>>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>>>>>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >>>>>
> >>>>>By the way there is no reason to put it at 00:1f.0 specifically I think.
> >>>>>So it seems simple: create a dummy device that gets device and
> >>>>>vendor id as properties. If you really like, add an option to get values
> >>>>
> >>>>Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> >>>>passthrough: create pseudo intel isa bridge. There, we fake this device just
> >>>>at 00:1f.0.
> >>>>But you guys don't like this, and shouldn't this be just this point we
> >>>>discussing now?
> >>>>
> >>>>If you guys agree that , everything is fine.
> >>>
> >>>Actually, this isn't what you did.
> >>>Don't tie it to xen, and don't tie it to 1f.
> >>>Just make it a simple stub pci device.
> >>>Whoever wants it, creates it.
> >>>
> >>>The thing I worry about, is the chance this will break going forward.
> >>>So you created a system with 2 isa bridges.
> >>
> >>I don't set class type to claim this is an ISA bridge, just a normal PCI
> >>device.
> >>+static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
> >>*hdev)
> >>+{
> >>+    struct PCIDevice *dev;
> >>+
> >>+    char rid;
> >>+
> >>+    /* We havt to use a simple PCI device to fake this ISA bridge
> >>+     * to avoid making some confusion to BIOS and ACPI.
> >>+     */
> >>+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
> >>"pseudo-intel-pch-isa-bridge");
> >>+
> >>+    qdev_init_nofail(&dev->qdev);
> >>+
> >>+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> >>+    pci_config_set_device_id(dev->config, hdev->device_id);
> >>+
> >>+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> >>+
> >>+    pci_config_set_revision(dev->config, rid);
> >>+
> >>+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> >>+    return 0;
> >>+}
> >
> >Then I don't see how it's supposed to work.
> >Doesn't i915 look for an isa bridge?
> >
> >         /*
> >          * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> >          * make graphics device passthrough work easy for VMM, that only
> >          * need to expose ISA bridge to let driver know the real hardware
> >          * underneath. This is a requirement from virtualization team.
> >          *
> >          * In some virtualized environments (e.g. XEN), there is irrelevant
> >          * ISA bridge in the system. To work reliably, we should scan trhough
> >          * all the ISA bridge devices and check for the first match, instead
> >          * of only checking the first one.
> >          */
> >         while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> >                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >                         dev_priv->pch_id = id;
> >
> >                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >                                 dev_priv->pch_type = PCH_IBX;
> >
> >etc
> >
> 
> I already post this to mainline to change as follows:
> 
> -	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> +	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> +	if (pch) {

I see - responded on that mail - but I thought the point is to make
existing guests run? In fact you said so explicitly.


> Please refer to this,
> 
> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
> check class type
> 
> Linux Native guys would like to accept this. And actually Windows always use
> devfn to detect this.

In fact I see this:

    linux 2.6.35-3.9 probes the 1st IA bridge

        no idea how would you fix this.
        try changing default class for the main bridge?

    linux 3.10 probes all ISA bridges

        requires your stub to be the isa bridge?


I don't see why are driver guys so willing to do crazy things.  They
want to match specific device/vendor id pairs, why don't they do just
that? Why poke at class, random slot numbers etc etc?



> >
> >
> >>>This is already not something that exists on real hardware.
> >>>So it might break some guests that will get confused.
> >>>Maybe we are lucky and most guests see an unfamiliar device
> >>>and ignore it. It seems believable.
> >>>
> >>>But your MCH hack overrides registers in the pci host.
> >>
> >>We just try to write *one* register we already confirm this is safe enough.
> >
> >This should go in code in form of comments:
> >document what this register does on 440fx
> >and why it's safe to override.
> >We don't see what you
> >confirmed off-line.
> 
> That offset is one specific to IGD usage, not for i440fx common. This is why
> we need to expose something in the host bridge. They're just introduced to
> support IGD.
> 
> >
> >>Other register are read-only.
> >
> >Doesn't matter, need to document these as well.
> 
> I think everything are covered in igd_pci_write()/igd_pci_write().
> 
> >
> >>>Are we lucky and there's nothing in these registers
> >>>of interest to guests? This seems much more fragile.
> >>>So please poke at the spec, and compile the list
> >>>of registers you want to touch, figure out why they are
> >>>safe to override, and put this all in code comments.
> >>>
> >>>And the same thing that applies to the isa bridge
> >>
> >>We just expose its own vendor/device ids here. We don't access to change
> >>anything in the isa bridge.
> >>
> >>>applies here too. It should work without QEMU touching
> >>>hosts' hardware.
> >>>
> >>>
> >>>
> >>>>>from sysfs: device and vendor id are world readable, so just get them
> >>>>>directly and not through xen wrappers, this way you can open the files
> >>>>>RO and not RW.
> >>>>>You seem to poke at revision as well, I don't see
> >>>>>driver looking at that - strictly necessary?
> >>>>>If yes please patch host kernel to expose that info in sysfs,
> >>>>>though we can fall back on pci config if not there.
> >>>>>
> >>>>>MCH (bridge_dev) hacks in i915 are nastier.
> >>>>>To clean them up, we really have to have an explicit driver for this
> >>>>>bridge, not a pass-through device.  Long term, the right thing to do is
> >>>>>likely to extend host driver and expose the necessary information in
> >>>>>sysfs on host kernel.
> >>>>>
> >>>>>
> >>>>
> >>>>I'm a bit confused. Any sysfs should be filled by the associated PCIe
> >>>>device, shouldn't it? So qemu still need to emulate this PCIe device
> >>>>firstly, then set properties into sysfs.
> >>>
> >>>I am talking about getting host properties into qemu.
> >>>You don't want to give qemu R/W root access to host sysfs system
> >>>of the root bridge, that's not secure.
> >>
> >>igd_pci_read()
> >>	|
> >>	+ xen_host_pci_get_block()
> >>		|
> >>		+ xen_host_pci_config_read(()
> >>			|
> >>			+  pread()
> >>
> >>So shouldn't we already expose these information via sysfs?
> >
> >That's poking at sysfs of a real device, and after opening it RW.
> 
> I don't think we can really write anything to those read-only sysfs
> interface even we open them as RW.
> 
> Tiejun
> 
> >
> >>>Avoiding read only access to filesystem is a good idea too, so it
> >>>should be possible to pass all parameters in as
> >>>device properties, and let whoever starts qemu
> >>>figure out what are reasonable values.
> >>>
> >>>>>
> >>>>>
> >>>>>>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>>>>>others. To do this properly, we need to get one from PCI SIG group. To have
> >>>>>>this workable and consistently validated, this method shouldn't be virt
> >>>>>>specific. Then native driver should use the same method.
> >>>>>
> >>>>>You mean you will be able to talk sense into hardware guys?
> >>>>>I doubt that. If they could be convinced to make e.g. i915 base a
> >>>>
> >>>>We're negotiating this, so this is just our long term solution we figure out
> >>>>currently.
> >>>>
> >>>>>proper BAR, why didn't they?
> >>>>
> >>>>We already have no any free BAR as we mentioned previously.
> >>>
> >>>I thought you were talking about modifying hardware?
> >>
> >>Yes.
> >>
> >>Tiejun
> >
> >And they can't figure out how to stick extra info in an existing BAR?
> >Oh well, that's hardware for you.
> >
> >>>
> >>>>>
> >>>>>
> >>>>>>So when xen work on
> >>>>>>q35 PCIe machine, we can walk this way.
> >>>>>
> >>>>>If you are emulating MCH anyway, pick one that is close
> >>>>>to what i915 driver expects. It would then work with existing
> >>>>
> >>>>Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> >>>>to create a new based on i440fx just for a little change?
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>You can inherit it. Maybe you are lucky and this happens to
> >>>work without conflicting with whatever other guests want to do.
> >>>But if you ask me, you are really just piling up hacks.
> >>>If some guest does not work on i440, you should just work on
> >>>emulating whatever it does work on.
> >>>That would have real value.
> >>>
> >>>>>devices, without new capability IDs.
> >>>>>
> >>>>>
> >>>>>>Anthony,
> >>>>>>
> >>>>>>Any comments to address this in xen case?
> >>>>>>
> >>>>>>Thanks
> >>>>>>Tiejun
> >>>>>
> >>>>>
> >>>
> >>>
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xen.org
> >http://lists.xen.org/xen-devel
> >
> >

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
> On 2014/6/30 17:55, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>Are you saying the config space in the video device?
> >>>>>>>
> >>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>MMIO BAR.
> >>>>>>>
> >>>>>>
> >>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>offset or BAR in the config space.
> >>>>>>
> >>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>
> >>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>q35 as a PCIe machine of xen.
> >>>>>
> >>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>so you have the time to make it architecturally sound.
> >>>>>"Making existing guests work" would be a better motivation.
> >>>>
> >>>>Yes.
> >>>
> >>>So focus on this then. Existing guests will probably work
> >>>fine on a newer chipset - likely better than on i440fx.
> >>>xen management tools need to do some work to support this?
> >>>That will just give everyone more long term benefits.
> >>>
> >>>If instead we create a hack that does not resemble
> >>>any existing hardware even remotely, what's the
> >>>chance that it will not break with any future
> >>>guest modification?
> >>>
> >>>
> >>>>>Isn't this possible with an mch chipset?
> >>>>
> >>>>If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> >>>>MCH in xen case.
> >>>
> >>>q35 or a newer chipset that's closer to what guests expect.
> >>>
> >>>>Additionally, I think I should follow this feature after
> >>>>q35 can work for xen scenario.
> >>>
> >>>What's stopping you?
> >>
> >>I mean if you want create an new machine based on q35, actually this is
> >>equal to start making xen to migrate to q35 now. Right? I can't image how
> >>much effort should be done.
> >
> >I don't see why you don't try. Sounds like a more robust solution to me.
> 
> As I think this is another requirement to us. I'm not sure if I have enough
> time to touch this currently.
> 
> >
> >>So this is a reason why I'm saying I'd like to follow this feature after q35
> >>can work with xen completely.
> >
> >Then we'll end up with more configurations to support, and to what end?
> >
> >>>
> >>>>>
> >>>>>
> >>>>>>So could we do this step by step:
> >>>>>>
> >>>>>>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>>>>>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >>>>>
> >>>>>By the way there is no reason to put it at 00:1f.0 specifically I think.
> >>>>>So it seems simple: create a dummy device that gets device and
> >>>>>vendor id as properties. If you really like, add an option to get values
> >>>>
> >>>>Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> >>>>passthrough: create pseudo intel isa bridge. There, we fake this device just
> >>>>at 00:1f.0.
> >>>>But you guys don't like this, and shouldn't this be just this point we
> >>>>discussing now?
> >>>>
> >>>>If you guys agree that , everything is fine.
> >>>
> >>>Actually, this isn't what you did.
> >>>Don't tie it to xen, and don't tie it to 1f.
> >>>Just make it a simple stub pci device.
> >>>Whoever wants it, creates it.
> >>>
> >>>The thing I worry about, is the chance this will break going forward.
> >>>So you created a system with 2 isa bridges.
> >>
> >>I don't set class type to claim this is an ISA bridge, just a normal PCI
> >>device.
> >>+static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
> >>*hdev)
> >>+{
> >>+    struct PCIDevice *dev;
> >>+
> >>+    char rid;
> >>+
> >>+    /* We havt to use a simple PCI device to fake this ISA bridge
> >>+     * to avoid making some confusion to BIOS and ACPI.
> >>+     */
> >>+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
> >>"pseudo-intel-pch-isa-bridge");
> >>+
> >>+    qdev_init_nofail(&dev->qdev);
> >>+
> >>+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> >>+    pci_config_set_device_id(dev->config, hdev->device_id);
> >>+
> >>+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> >>+
> >>+    pci_config_set_revision(dev->config, rid);
> >>+
> >>+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> >>+    return 0;
> >>+}
> >
> >Then I don't see how it's supposed to work.
> >Doesn't i915 look for an isa bridge?
> >
> >         /*
> >          * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> >          * make graphics device passthrough work easy for VMM, that only
> >          * need to expose ISA bridge to let driver know the real hardware
> >          * underneath. This is a requirement from virtualization team.
> >          *
> >          * In some virtualized environments (e.g. XEN), there is irrelevant
> >          * ISA bridge in the system. To work reliably, we should scan trhough
> >          * all the ISA bridge devices and check for the first match, instead
> >          * of only checking the first one.
> >          */
> >         while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> >                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >                         dev_priv->pch_id = id;
> >
> >                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >                                 dev_priv->pch_type = PCH_IBX;
> >
> >etc
> >
> 
> I already post this to mainline to change as follows:
> 
> -	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> +	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> +	if (pch) {

I see - responded on that mail - but I thought the point is to make
existing guests run? In fact you said so explicitly.


> Please refer to this,
> 
> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
> check class type
> 
> Linux Native guys would like to accept this. And actually Windows always use
> devfn to detect this.

In fact I see this:

    linux 2.6.35-3.9 probes the 1st IA bridge

        no idea how would you fix this.
        try changing default class for the main bridge?

    linux 3.10 probes all ISA bridges

        requires your stub to be the isa bridge?


I don't see why are driver guys so willing to do crazy things.  They
want to match specific device/vendor id pairs, why don't they do just
that? Why poke at class, random slot numbers etc etc?



> >
> >
> >>>This is already not something that exists on real hardware.
> >>>So it might break some guests that will get confused.
> >>>Maybe we are lucky and most guests see an unfamiliar device
> >>>and ignore it. It seems believable.
> >>>
> >>>But your MCH hack overrides registers in the pci host.
> >>
> >>We just try to write *one* register we already confirm this is safe enough.
> >
> >This should go in code in form of comments:
> >document what this register does on 440fx
> >and why it's safe to override.
> >We don't see what you
> >confirmed off-line.
> 
> That offset is one specific to IGD usage, not for i440fx common. This is why
> we need to expose something in the host bridge. They're just introduced to
> support IGD.
> 
> >
> >>Other register are read-only.
> >
> >Doesn't matter, need to document these as well.
> 
> I think everything are covered in igd_pci_write()/igd_pci_write().
> 
> >
> >>>Are we lucky and there's nothing in these registers
> >>>of interest to guests? This seems much more fragile.
> >>>So please poke at the spec, and compile the list
> >>>of registers you want to touch, figure out why they are
> >>>safe to override, and put this all in code comments.
> >>>
> >>>And the same thing that applies to the isa bridge
> >>
> >>We just expose its own vendor/device ids here. We don't access to change
> >>anything in the isa bridge.
> >>
> >>>applies here too. It should work without QEMU touching
> >>>hosts' hardware.
> >>>
> >>>
> >>>
> >>>>>from sysfs: device and vendor id are world readable, so just get them
> >>>>>directly and not through xen wrappers, this way you can open the files
> >>>>>RO and not RW.
> >>>>>You seem to poke at revision as well, I don't see
> >>>>>driver looking at that - strictly necessary?
> >>>>>If yes please patch host kernel to expose that info in sysfs,
> >>>>>though we can fall back on pci config if not there.
> >>>>>
> >>>>>MCH (bridge_dev) hacks in i915 are nastier.
> >>>>>To clean them up, we really have to have an explicit driver for this
> >>>>>bridge, not a pass-through device.  Long term, the right thing to do is
> >>>>>likely to extend host driver and expose the necessary information in
> >>>>>sysfs on host kernel.
> >>>>>
> >>>>>
> >>>>
> >>>>I'm a bit confused. Any sysfs should be filled by the associated PCIe
> >>>>device, shouldn't it? So qemu still need to emulate this PCIe device
> >>>>firstly, then set properties into sysfs.
> >>>
> >>>I am talking about getting host properties into qemu.
> >>>You don't want to give qemu R/W root access to host sysfs system
> >>>of the root bridge, that's not secure.
> >>
> >>igd_pci_read()
> >>	|
> >>	+ xen_host_pci_get_block()
> >>		|
> >>		+ xen_host_pci_config_read(()
> >>			|
> >>			+  pread()
> >>
> >>So shouldn't we already expose these information via sysfs?
> >
> >That's poking at sysfs of a real device, and after opening it RW.
> 
> I don't think we can really write anything to those read-only sysfs
> interface even we open them as RW.
> 
> Tiejun
> 
> >
> >>>Avoiding read only access to filesystem is a good idea too, so it
> >>>should be possible to pass all parameters in as
> >>>device properties, and let whoever starts qemu
> >>>figure out what are reasonable values.
> >>>
> >>>>>
> >>>>>
> >>>>>>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>>>>>others. To do this properly, we need to get one from PCI SIG group. To have
> >>>>>>this workable and consistently validated, this method shouldn't be virt
> >>>>>>specific. Then native driver should use the same method.
> >>>>>
> >>>>>You mean you will be able to talk sense into hardware guys?
> >>>>>I doubt that. If they could be convinced to make e.g. i915 base a
> >>>>
> >>>>We're negotiating this, so this is just our long term solution we figure out
> >>>>currently.
> >>>>
> >>>>>proper BAR, why didn't they?
> >>>>
> >>>>We already have no any free BAR as we mentioned previously.
> >>>
> >>>I thought you were talking about modifying hardware?
> >>
> >>Yes.
> >>
> >>Tiejun
> >
> >And they can't figure out how to stick extra info in an existing BAR?
> >Oh well, that's hardware for you.
> >
> >>>
> >>>>>
> >>>>>
> >>>>>>So when xen work on
> >>>>>>q35 PCIe machine, we can walk this way.
> >>>>>
> >>>>>If you are emulating MCH anyway, pick one that is close
> >>>>>to what i915 driver expects. It would then work with existing
> >>>>
> >>>>Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> >>>>to create a new based on i440fx just for a little change?
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>You can inherit it. Maybe you are lucky and this happens to
> >>>work without conflicting with whatever other guests want to do.
> >>>But if you ask me, you are really just piling up hacks.
> >>>If some guest does not work on i440, you should just work on
> >>>emulating whatever it does work on.
> >>>That would have real value.
> >>>
> >>>>>devices, without new capability IDs.
> >>>>>
> >>>>>
> >>>>>>Anthony,
> >>>>>>
> >>>>>>Any comments to address this in xen case?
> >>>>>>
> >>>>>>Thanks
> >>>>>>Tiejun
> >>>>>
> >>>>>
> >>>
> >>>
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xen.org
> >http://lists.xen.org/xen-devel
> >
> >

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/30 19:28, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
>> On 2014/6/30 17:55, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>
>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>> MMIO BAR.
>>>>>>>>>
>>>>>>>>
>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>> offset or BAR in the config space.
>>>>>>>>
>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>
>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>
>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>> so you have the time to make it architecturally sound.
>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>
>>>>>> Yes.
>>>>>
>>>>> So focus on this then. Existing guests will probably work
>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>> xen management tools need to do some work to support this?
>>>>> That will just give everyone more long term benefits.
>>>>>
>>>>> If instead we create a hack that does not resemble
>>>>> any existing hardware even remotely, what's the
>>>>> chance that it will not break with any future
>>>>> guest modification?
>>>>>
>>>>>
>>>>>>> Isn't this possible with an mch chipset?
>>>>>>
>>>>>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>>>>>> MCH in xen case.
>>>>>
>>>>> q35 or a newer chipset that's closer to what guests expect.
>>>>>
>>>>>> Additionally, I think I should follow this feature after
>>>>>> q35 can work for xen scenario.
>>>>>
>>>>> What's stopping you?
>>>>
>>>> I mean if you want create an new machine based on q35, actually this is
>>>> equal to start making xen to migrate to q35 now. Right? I can't image how
>>>> much effort should be done.
>>>
>>> I don't see why you don't try. Sounds like a more robust solution to me.
>>
>> As I think this is another requirement to us. I'm not sure if I have enough
>> time to touch this currently.
>>
>>>
>>>> So this is a reason why I'm saying I'd like to follow this feature after q35
>>>> can work with xen completely.
>>>
>>> Then we'll end up with more configurations to support, and to what end?
>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> So could we do this step by step:
>>>>>>>>
>>>>>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>>>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>>>>>
>>>>>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>>>>>> So it seems simple: create a dummy device that gets device and
>>>>>>> vendor id as properties. If you really like, add an option to get values
>>>>>>
>>>>>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>>>>>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>>>>>> at 00:1f.0.
>>>>>> But you guys don't like this, and shouldn't this be just this point we
>>>>>> discussing now?
>>>>>>
>>>>>> If you guys agree that , everything is fine.
>>>>>
>>>>> Actually, this isn't what you did.
>>>>> Don't tie it to xen, and don't tie it to 1f.
>>>>> Just make it a simple stub pci device.
>>>>> Whoever wants it, creates it.
>>>>>
>>>>> The thing I worry about, is the chance this will break going forward.
>>>>> So you created a system with 2 isa bridges.
>>>>
>>>> I don't set class type to claim this is an ISA bridge, just a normal PCI
>>>> device.
>>>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>>>> *hdev)
>>>> +{
>>>> +    struct PCIDevice *dev;
>>>> +
>>>> +    char rid;
>>>> +
>>>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>>>> +     * to avoid making some confusion to BIOS and ACPI.
>>>> +     */
>>>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>>>> "pseudo-intel-pch-isa-bridge");
>>>> +
>>>> +    qdev_init_nofail(&dev->qdev);
>>>> +
>>>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>>>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>>>> +
>>>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>>>> +
>>>> +    pci_config_set_revision(dev->config, rid);
>>>> +
>>>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>>> +    return 0;
>>>> +}
>>>
>>> Then I don't see how it's supposed to work.
>>> Doesn't i915 look for an isa bridge?
>>>
>>>          /*
>>>           * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>>>           * make graphics device passthrough work easy for VMM, that only
>>>           * need to expose ISA bridge to let driver know the real hardware
>>>           * underneath. This is a requirement from virtualization team.
>>>           *
>>>           * In some virtualized environments (e.g. XEN), there is irrelevant
>>>           * ISA bridge in the system. To work reliably, we should scan trhough
>>>           * all the ISA bridge devices and check for the first match, instead
>>>           * of only checking the first one.
>>>           */
>>>          while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>                  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>                          unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>                          dev_priv->pch_id = id;
>>>
>>>                          if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>                                  dev_priv->pch_type = PCH_IBX;
>>>
>>> etc
>>>
>>
>> I already post this to mainline to change as follows:
>>
>> -	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>> +	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>> +	if (pch) {
>
> I see - responded on that mail - but I thought the point is to make
> existing guests run? In fact you said so explicitly.
>
>
>> Please refer to this,
>>
>> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
>> check class type
>>
>> Linux Native guys would like to accept this. And actually Windows always use
>> devfn to detect this.
>
> In fact I see this:
>
>      linux 2.6.35-3.9 probes the 1st IA bridge
>
>          no idea how would you fix this.
>          try changing default class for the main bridge?
>
>      linux 3.10 probes all ISA bridges
>
>          requires your stub to be the isa bridge?
>
>
> I don't see why are driver guys so willing to do crazy things.  They
> want to match specific device/vendor id pairs, why don't they do just
> that? Why poke at class, random slot numbers etc etc?

AFAIK what they did is from our previous incorrect requirement as I 
understand. So we need to correct this.

Thanks
Tiejun

>
>
>
>>>
>>>
>>>>> This is already not something that exists on real hardware.
>>>>> So it might break some guests that will get confused.
>>>>> Maybe we are lucky and most guests see an unfamiliar device
>>>>> and ignore it. It seems believable.
>>>>>
>>>>> But your MCH hack overrides registers in the pci host.
>>>>
>>>> We just try to write *one* register we already confirm this is safe enough.
>>>
>>> This should go in code in form of comments:
>>> document what this register does on 440fx
>>> and why it's safe to override.
>>> We don't see what you
>>> confirmed off-line.
>>
>> That offset is one specific to IGD usage, not for i440fx common. This is why
>> we need to expose something in the host bridge. They're just introduced to
>> support IGD.
>>
>>>
>>>> Other register are read-only.
>>>
>>> Doesn't matter, need to document these as well.
>>
>> I think everything are covered in igd_pci_write()/igd_pci_write().
>>
>>>
>>>>> Are we lucky and there's nothing in these registers
>>>>> of interest to guests? This seems much more fragile.
>>>>> So please poke at the spec, and compile the list
>>>>> of registers you want to touch, figure out why they are
>>>>> safe to override, and put this all in code comments.
>>>>>
>>>>> And the same thing that applies to the isa bridge
>>>>
>>>> We just expose its own vendor/device ids here. We don't access to change
>>>> anything in the isa bridge.
>>>>
>>>>> applies here too. It should work without QEMU touching
>>>>> hosts' hardware.
>>>>>
>>>>>
>>>>>
>>>>>> >from sysfs: device and vendor id are world readable, so just get them
>>>>>>> directly and not through xen wrappers, this way you can open the files
>>>>>>> RO and not RW.
>>>>>>> You seem to poke at revision as well, I don't see
>>>>>>> driver looking at that - strictly necessary?
>>>>>>> If yes please patch host kernel to expose that info in sysfs,
>>>>>>> though we can fall back on pci config if not there.
>>>>>>>
>>>>>>> MCH (bridge_dev) hacks in i915 are nastier.
>>>>>>> To clean them up, we really have to have an explicit driver for this
>>>>>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>>>>>> likely to extend host driver and expose the necessary information in
>>>>>>> sysfs on host kernel.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>>>>>> device, shouldn't it? So qemu still need to emulate this PCIe device
>>>>>> firstly, then set properties into sysfs.
>>>>>
>>>>> I am talking about getting host properties into qemu.
>>>>> You don't want to give qemu R/W root access to host sysfs system
>>>>> of the root bridge, that's not secure.
>>>>
>>>> igd_pci_read()
>>>> 	|
>>>> 	+ xen_host_pci_get_block()
>>>> 		|
>>>> 		+ xen_host_pci_config_read(()
>>>> 			|
>>>> 			+  pread()
>>>>
>>>> So shouldn't we already expose these information via sysfs?
>>>
>>> That's poking at sysfs of a real device, and after opening it RW.
>>
>> I don't think we can really write anything to those read-only sysfs
>> interface even we open them as RW.
>>
>> Tiejun
>>
>>>
>>>>> Avoiding read only access to filesystem is a good idea too, so it
>>>>> should be possible to pass all parameters in as
>>>>> device properties, and let whoever starts qemu
>>>>> figure out what are reasonable values.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>>>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>>>>>> this workable and consistently validated, this method shouldn't be virt
>>>>>>>> specific. Then native driver should use the same method.
>>>>>>>
>>>>>>> You mean you will be able to talk sense into hardware guys?
>>>>>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>>>>>
>>>>>> We're negotiating this, so this is just our long term solution we figure out
>>>>>> currently.
>>>>>>
>>>>>>> proper BAR, why didn't they?
>>>>>>
>>>>>> We already have no any free BAR as we mentioned previously.
>>>>>
>>>>> I thought you were talking about modifying hardware?
>>>>
>>>> Yes.
>>>>
>>>> Tiejun
>>>
>>> And they can't figure out how to stick extra info in an existing BAR?
>>> Oh well, that's hardware for you.
>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> So when xen work on
>>>>>>>> q35 PCIe machine, we can walk this way.
>>>>>>>
>>>>>>> If you are emulating MCH anyway, pick one that is close
>>>>>>> to what i915 driver expects. It would then work with existing
>>>>>>
>>>>>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>>>>>> to create a new based on i440fx just for a little change?
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>> You can inherit it. Maybe you are lucky and this happens to
>>>>> work without conflicting with whatever other guests want to do.
>>>>> But if you ask me, you are really just piling up hacks.
>>>>> If some guest does not work on i440, you should just work on
>>>>> emulating whatever it does work on.
>>>>> That would have real value.
>>>>>
>>>>>>> devices, without new capability IDs.
>>>>>>>
>>>>>>>
>>>>>>>> Anthony,
>>>>>>>>
>>>>>>>> Any comments to address this in xen case?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Tiejun
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>>
>>>
>

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/30 19:28, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
>> On 2014/6/30 17:55, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>
>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>> MMIO BAR.
>>>>>>>>>
>>>>>>>>
>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>> offset or BAR in the config space.
>>>>>>>>
>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>
>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>
>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>> so you have the time to make it architecturally sound.
>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>
>>>>>> Yes.
>>>>>
>>>>> So focus on this then. Existing guests will probably work
>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>> xen management tools need to do some work to support this?
>>>>> That will just give everyone more long term benefits.
>>>>>
>>>>> If instead we create a hack that does not resemble
>>>>> any existing hardware even remotely, what's the
>>>>> chance that it will not break with any future
>>>>> guest modification?
>>>>>
>>>>>
>>>>>>> Isn't this possible with an mch chipset?
>>>>>>
>>>>>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>>>>>> MCH in xen case.
>>>>>
>>>>> q35 or a newer chipset that's closer to what guests expect.
>>>>>
>>>>>> Additionally, I think I should follow this feature after
>>>>>> q35 can work for xen scenario.
>>>>>
>>>>> What's stopping you?
>>>>
>>>> I mean if you want create an new machine based on q35, actually this is
>>>> equal to start making xen to migrate to q35 now. Right? I can't image how
>>>> much effort should be done.
>>>
>>> I don't see why you don't try. Sounds like a more robust solution to me.
>>
>> As I think this is another requirement to us. I'm not sure if I have enough
>> time to touch this currently.
>>
>>>
>>>> So this is a reason why I'm saying I'd like to follow this feature after q35
>>>> can work with xen completely.
>>>
>>> Then we'll end up with more configurations to support, and to what end?
>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> So could we do this step by step:
>>>>>>>>
>>>>>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>>>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>>>>>
>>>>>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>>>>>> So it seems simple: create a dummy device that gets device and
>>>>>>> vendor id as properties. If you really like, add an option to get values
>>>>>>
>>>>>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>>>>>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>>>>>> at 00:1f.0.
>>>>>> But you guys don't like this, and shouldn't this be just this point we
>>>>>> discussing now?
>>>>>>
>>>>>> If you guys agree that , everything is fine.
>>>>>
>>>>> Actually, this isn't what you did.
>>>>> Don't tie it to xen, and don't tie it to 1f.
>>>>> Just make it a simple stub pci device.
>>>>> Whoever wants it, creates it.
>>>>>
>>>>> The thing I worry about, is the chance this will break going forward.
>>>>> So you created a system with 2 isa bridges.
>>>>
>>>> I don't set class type to claim this is an ISA bridge, just a normal PCI
>>>> device.
>>>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>>>> *hdev)
>>>> +{
>>>> +    struct PCIDevice *dev;
>>>> +
>>>> +    char rid;
>>>> +
>>>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>>>> +     * to avoid making some confusion to BIOS and ACPI.
>>>> +     */
>>>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>>>> "pseudo-intel-pch-isa-bridge");
>>>> +
>>>> +    qdev_init_nofail(&dev->qdev);
>>>> +
>>>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>>>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>>>> +
>>>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>>>> +
>>>> +    pci_config_set_revision(dev->config, rid);
>>>> +
>>>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>>> +    return 0;
>>>> +}
>>>
>>> Then I don't see how it's supposed to work.
>>> Doesn't i915 look for an isa bridge?
>>>
>>>          /*
>>>           * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>>>           * make graphics device passthrough work easy for VMM, that only
>>>           * need to expose ISA bridge to let driver know the real hardware
>>>           * underneath. This is a requirement from virtualization team.
>>>           *
>>>           * In some virtualized environments (e.g. XEN), there is irrelevant
>>>           * ISA bridge in the system. To work reliably, we should scan trhough
>>>           * all the ISA bridge devices and check for the first match, instead
>>>           * of only checking the first one.
>>>           */
>>>          while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>                  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>                          unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>                          dev_priv->pch_id = id;
>>>
>>>                          if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>                                  dev_priv->pch_type = PCH_IBX;
>>>
>>> etc
>>>
>>
>> I already post this to mainline to change as follows:
>>
>> -	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>> +	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>> +	if (pch) {
>
> I see - responded on that mail - but I thought the point is to make
> existing guests run? In fact you said so explicitly.
>
>
>> Please refer to this,
>>
>> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
>> check class type
>>
>> Linux Native guys would like to accept this. And actually Windows always use
>> devfn to detect this.
>
> In fact I see this:
>
>      linux 2.6.35-3.9 probes the 1st IA bridge
>
>          no idea how would you fix this.
>          try changing default class for the main bridge?
>
>      linux 3.10 probes all ISA bridges
>
>          requires your stub to be the isa bridge?
>
>
> I don't see why are driver guys so willing to do crazy things.  They
> want to match specific device/vendor id pairs, why don't they do just
> that? Why poke at class, random slot numbers etc etc?

AFAIK what they did is from our previous incorrect requirement as I 
understand. So we need to correct this.

Thanks
Tiejun

>
>
>
>>>
>>>
>>>>> This is already not something that exists on real hardware.
>>>>> So it might break some guests that will get confused.
>>>>> Maybe we are lucky and most guests see an unfamiliar device
>>>>> and ignore it. It seems believable.
>>>>>
>>>>> But your MCH hack overrides registers in the pci host.
>>>>
>>>> We just try to write *one* register we already confirm this is safe enough.
>>>
>>> This should go in code in form of comments:
>>> document what this register does on 440fx
>>> and why it's safe to override.
>>> We don't see what you
>>> confirmed off-line.
>>
>> That offset is one specific to IGD usage, not for i440fx common. This is why
>> we need to expose something in the host bridge. They're just introduced to
>> support IGD.
>>
>>>
>>>> Other register are read-only.
>>>
>>> Doesn't matter, need to document these as well.
>>
>> I think everything are covered in igd_pci_write()/igd_pci_write().
>>
>>>
>>>>> Are we lucky and there's nothing in these registers
>>>>> of interest to guests? This seems much more fragile.
>>>>> So please poke at the spec, and compile the list
>>>>> of registers you want to touch, figure out why they are
>>>>> safe to override, and put this all in code comments.
>>>>>
>>>>> And the same thing that applies to the isa bridge
>>>>
>>>> We just expose its own vendor/device ids here. We don't access to change
>>>> anything in the isa bridge.
>>>>
>>>>> applies here too. It should work without QEMU touching
>>>>> hosts' hardware.
>>>>>
>>>>>
>>>>>
>>>>>> >from sysfs: device and vendor id are world readable, so just get them
>>>>>>> directly and not through xen wrappers, this way you can open the files
>>>>>>> RO and not RW.
>>>>>>> You seem to poke at revision as well, I don't see
>>>>>>> driver looking at that - strictly necessary?
>>>>>>> If yes please patch host kernel to expose that info in sysfs,
>>>>>>> though we can fall back on pci config if not there.
>>>>>>>
>>>>>>> MCH (bridge_dev) hacks in i915 are nastier.
>>>>>>> To clean them up, we really have to have an explicit driver for this
>>>>>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>>>>>> likely to extend host driver and expose the necessary information in
>>>>>>> sysfs on host kernel.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>>>>>> device, shouldn't it? So qemu still need to emulate this PCIe device
>>>>>> firstly, then set properties into sysfs.
>>>>>
>>>>> I am talking about getting host properties into qemu.
>>>>> You don't want to give qemu R/W root access to host sysfs system
>>>>> of the root bridge, that's not secure.
>>>>
>>>> igd_pci_read()
>>>> 	|
>>>> 	+ xen_host_pci_get_block()
>>>> 		|
>>>> 		+ xen_host_pci_config_read(()
>>>> 			|
>>>> 			+  pread()
>>>>
>>>> So shouldn't we already expose these information via sysfs?
>>>
>>> That's poking at sysfs of a real device, and after opening it RW.
>>
>> I don't think we can really write anything to those read-only sysfs
>> interface even we open them as RW.
>>
>> Tiejun
>>
>>>
>>>>> Avoiding read only access to filesystem is a good idea too, so it
>>>>> should be possible to pass all parameters in as
>>>>> device properties, and let whoever starts qemu
>>>>> figure out what are reasonable values.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>>>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>>>>>> this workable and consistently validated, this method shouldn't be virt
>>>>>>>> specific. Then native driver should use the same method.
>>>>>>>
>>>>>>> You mean you will be able to talk sense into hardware guys?
>>>>>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>>>>>
>>>>>> We're negotiating this, so this is just our long term solution we figure out
>>>>>> currently.
>>>>>>
>>>>>>> proper BAR, why didn't they?
>>>>>>
>>>>>> We already have no any free BAR as we mentioned previously.
>>>>>
>>>>> I thought you were talking about modifying hardware?
>>>>
>>>> Yes.
>>>>
>>>> Tiejun
>>>
>>> And they can't figure out how to stick extra info in an existing BAR?
>>> Oh well, that's hardware for you.
>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> So when xen work on
>>>>>>>> q35 PCIe machine, we can walk this way.
>>>>>>>
>>>>>>> If you are emulating MCH anyway, pick one that is close
>>>>>>> to what i915 driver expects. It would then work with existing
>>>>>>
>>>>>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>>>>>> to create a new based on i440fx just for a little change?
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>> You can inherit it. Maybe you are lucky and this happens to
>>>>> work without conflicting with whatever other guests want to do.
>>>>> But if you ask me, you are really just piling up hacks.
>>>>> If some guest does not work on i440, you should just work on
>>>>> emulating whatever it does work on.
>>>>> That would have real value.
>>>>>
>>>>>>> devices, without new capability IDs.
>>>>>>>
>>>>>>>
>>>>>>>> Anthony,
>>>>>>>>
>>>>>>>> Any comments to address this in xen case?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Tiejun
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>>
>>>
>

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
> On 2014/6/30 19:28, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/30 17:55, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >>>>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Are you saying the config space in the video device?
> >>>>>>>>>
> >>>>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>>>MMIO BAR.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>>>offset or BAR in the config space.
> >>>>>>>>
> >>>>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>>>
> >>>>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>>>q35 as a PCIe machine of xen.
> >>>>>>>
> >>>>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>>>so you have the time to make it architecturally sound.
> >>>>>>>"Making existing guests work" would be a better motivation.
> >>>>>>
> >>>>>>Yes.
> >>>>>
> >>>>>So focus on this then. Existing guests will probably work
> >>>>>fine on a newer chipset - likely better than on i440fx.
> >>>>>xen management tools need to do some work to support this?
> >>>>>That will just give everyone more long term benefits.
> >>>>>
> >>>>>If instead we create a hack that does not resemble
> >>>>>any existing hardware even remotely, what's the
> >>>>>chance that it will not break with any future
> >>>>>guest modification?
> >>>>>
> >>>>>
> >>>>>>>Isn't this possible with an mch chipset?
> >>>>>>
> >>>>>>If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> >>>>>>MCH in xen case.
> >>>>>
> >>>>>q35 or a newer chipset that's closer to what guests expect.
> >>>>>
> >>>>>>Additionally, I think I should follow this feature after
> >>>>>>q35 can work for xen scenario.
> >>>>>
> >>>>>What's stopping you?
> >>>>
> >>>>I mean if you want create an new machine based on q35, actually this is
> >>>>equal to start making xen to migrate to q35 now. Right? I can't image how
> >>>>much effort should be done.
> >>>
> >>>I don't see why you don't try. Sounds like a more robust solution to me.
> >>
> >>As I think this is another requirement to us. I'm not sure if I have enough
> >>time to touch this currently.
> >>
> >>>
> >>>>So this is a reason why I'm saying I'd like to follow this feature after q35
> >>>>can work with xen completely.
> >>>
> >>>Then we'll end up with more configurations to support, and to what end?
> >>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>So could we do this step by step:
> >>>>>>>>
> >>>>>>>>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>>>>>>>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >>>>>>>
> >>>>>>>By the way there is no reason to put it at 00:1f.0 specifically I think.
> >>>>>>>So it seems simple: create a dummy device that gets device and
> >>>>>>>vendor id as properties. If you really like, add an option to get values
> >>>>>>
> >>>>>>Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> >>>>>>passthrough: create pseudo intel isa bridge. There, we fake this device just
> >>>>>>at 00:1f.0.
> >>>>>>But you guys don't like this, and shouldn't this be just this point we
> >>>>>>discussing now?
> >>>>>>
> >>>>>>If you guys agree that , everything is fine.
> >>>>>
> >>>>>Actually, this isn't what you did.
> >>>>>Don't tie it to xen, and don't tie it to 1f.
> >>>>>Just make it a simple stub pci device.
> >>>>>Whoever wants it, creates it.
> >>>>>
> >>>>>The thing I worry about, is the chance this will break going forward.
> >>>>>So you created a system with 2 isa bridges.
> >>>>
> >>>>I don't set class type to claim this is an ISA bridge, just a normal PCI
> >>>>device.
> >>>>+static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
> >>>>*hdev)
> >>>>+{
> >>>>+    struct PCIDevice *dev;
> >>>>+
> >>>>+    char rid;
> >>>>+
> >>>>+    /* We havt to use a simple PCI device to fake this ISA bridge
> >>>>+     * to avoid making some confusion to BIOS and ACPI.
> >>>>+     */
> >>>>+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
> >>>>"pseudo-intel-pch-isa-bridge");
> >>>>+
> >>>>+    qdev_init_nofail(&dev->qdev);
> >>>>+
> >>>>+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> >>>>+    pci_config_set_device_id(dev->config, hdev->device_id);
> >>>>+
> >>>>+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> >>>>+
> >>>>+    pci_config_set_revision(dev->config, rid);
> >>>>+
> >>>>+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> >>>>+    return 0;
> >>>>+}
> >>>
> >>>Then I don't see how it's supposed to work.
> >>>Doesn't i915 look for an isa bridge?
> >>>
> >>>         /*
> >>>          * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> >>>          * make graphics device passthrough work easy for VMM, that only
> >>>          * need to expose ISA bridge to let driver know the real hardware
> >>>          * underneath. This is a requirement from virtualization team.
> >>>          *
> >>>          * In some virtualized environments (e.g. XEN), there is irrelevant
> >>>          * ISA bridge in the system. To work reliably, we should scan trhough
> >>>          * all the ISA bridge devices and check for the first match, instead
> >>>          * of only checking the first one.
> >>>          */
> >>>         while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>>                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> >>>                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >>>                         dev_priv->pch_id = id;
> >>>
> >>>                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >>>                                 dev_priv->pch_type = PCH_IBX;
> >>>
> >>>etc
> >>>
> >>
> >>I already post this to mainline to change as follows:
> >>
> >>-	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>+	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> >>+	if (pch) {
> >
> >I see - responded on that mail - but I thought the point is to make
> >existing guests run? In fact you said so explicitly.
> >
> >
> >>Please refer to this,
> >>
> >>[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
> >>check class type
> >>
> >>Linux Native guys would like to accept this. And actually Windows always use
> >>devfn to detect this.
> >
> >In fact I see this:
> >
> >     linux 2.6.35-3.9 probes the 1st IA bridge
> >
> >         no idea how would you fix this.
> >         try changing default class for the main bridge?
> >
> >     linux 3.10 probes all ISA bridges
> >
> >         requires your stub to be the isa bridge?
> >
> >
> >I don't see why are driver guys so willing to do crazy things.  They
> >want to match specific device/vendor id pairs, why don't they do just
> >that? Why poke at class, random slot numbers etc etc?
> 
> AFAIK what they did is from our previous incorrect requirement as I
> understand. So we need to correct this.
> 
> Thanks
> Tiejun

Since we can't fix existing guests, I would say
get things working first, find a clean way for
new driver to work next.

> >
> >
> >
> >>>
> >>>
> >>>>>This is already not something that exists on real hardware.
> >>>>>So it might break some guests that will get confused.
> >>>>>Maybe we are lucky and most guests see an unfamiliar device
> >>>>>and ignore it. It seems believable.
> >>>>>
> >>>>>But your MCH hack overrides registers in the pci host.
> >>>>
> >>>>We just try to write *one* register we already confirm this is safe enough.
> >>>
> >>>This should go in code in form of comments:
> >>>document what this register does on 440fx
> >>>and why it's safe to override.
> >>>We don't see what you
> >>>confirmed off-line.
> >>
> >>That offset is one specific to IGD usage, not for i440fx common. This is why
> >>we need to expose something in the host bridge. They're just introduced to
> >>support IGD.
> >>
> >>>
> >>>>Other register are read-only.
> >>>
> >>>Doesn't matter, need to document these as well.
> >>
> >>I think everything are covered in igd_pci_write()/igd_pci_write().
> >>
> >>>
> >>>>>Are we lucky and there's nothing in these registers
> >>>>>of interest to guests? This seems much more fragile.
> >>>>>So please poke at the spec, and compile the list
> >>>>>of registers you want to touch, figure out why they are
> >>>>>safe to override, and put this all in code comments.
> >>>>>
> >>>>>And the same thing that applies to the isa bridge
> >>>>
> >>>>We just expose its own vendor/device ids here. We don't access to change
> >>>>anything in the isa bridge.
> >>>>
> >>>>>applies here too. It should work without QEMU touching
> >>>>>hosts' hardware.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>from sysfs: device and vendor id are world readable, so just get them
> >>>>>>>directly and not through xen wrappers, this way you can open the files
> >>>>>>>RO and not RW.
> >>>>>>>You seem to poke at revision as well, I don't see
> >>>>>>>driver looking at that - strictly necessary?
> >>>>>>>If yes please patch host kernel to expose that info in sysfs,
> >>>>>>>though we can fall back on pci config if not there.
> >>>>>>>
> >>>>>>>MCH (bridge_dev) hacks in i915 are nastier.
> >>>>>>>To clean them up, we really have to have an explicit driver for this
> >>>>>>>bridge, not a pass-through device.  Long term, the right thing to do is
> >>>>>>>likely to extend host driver and expose the necessary information in
> >>>>>>>sysfs on host kernel.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>I'm a bit confused. Any sysfs should be filled by the associated PCIe
> >>>>>>device, shouldn't it? So qemu still need to emulate this PCIe device
> >>>>>>firstly, then set properties into sysfs.
> >>>>>
> >>>>>I am talking about getting host properties into qemu.
> >>>>>You don't want to give qemu R/W root access to host sysfs system
> >>>>>of the root bridge, that's not secure.
> >>>>
> >>>>igd_pci_read()
> >>>>	|
> >>>>	+ xen_host_pci_get_block()
> >>>>		|
> >>>>		+ xen_host_pci_config_read(()
> >>>>			|
> >>>>			+  pread()
> >>>>
> >>>>So shouldn't we already expose these information via sysfs?
> >>>
> >>>That's poking at sysfs of a real device, and after opening it RW.
> >>
> >>I don't think we can really write anything to those read-only sysfs
> >>interface even we open them as RW.
> >>
> >>Tiejun
> >>
> >>>
> >>>>>Avoiding read only access to filesystem is a good idea too, so it
> >>>>>should be possible to pass all parameters in as
> >>>>>device properties, and let whoever starts qemu
> >>>>>figure out what are reasonable values.
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>>>>>>>others. To do this properly, we need to get one from PCI SIG group. To have
> >>>>>>>>this workable and consistently validated, this method shouldn't be virt
> >>>>>>>>specific. Then native driver should use the same method.
> >>>>>>>
> >>>>>>>You mean you will be able to talk sense into hardware guys?
> >>>>>>>I doubt that. If they could be convinced to make e.g. i915 base a
> >>>>>>
> >>>>>>We're negotiating this, so this is just our long term solution we figure out
> >>>>>>currently.
> >>>>>>
> >>>>>>>proper BAR, why didn't they?
> >>>>>>
> >>>>>>We already have no any free BAR as we mentioned previously.
> >>>>>
> >>>>>I thought you were talking about modifying hardware?
> >>>>
> >>>>Yes.
> >>>>
> >>>>Tiejun
> >>>
> >>>And they can't figure out how to stick extra info in an existing BAR?
> >>>Oh well, that's hardware for you.
> >>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>So when xen work on
> >>>>>>>>q35 PCIe machine, we can walk this way.
> >>>>>>>
> >>>>>>>If you are emulating MCH anyway, pick one that is close
> >>>>>>>to what i915 driver expects. It would then work with existing
> >>>>>>
> >>>>>>Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> >>>>>>to create a new based on i440fx just for a little change?
> >>>>>>
> >>>>>>Thanks
> >>>>>>Tiejun
> >>>>>
> >>>>>You can inherit it. Maybe you are lucky and this happens to
> >>>>>work without conflicting with whatever other guests want to do.
> >>>>>But if you ask me, you are really just piling up hacks.
> >>>>>If some guest does not work on i440, you should just work on
> >>>>>emulating whatever it does work on.
> >>>>>That would have real value.
> >>>>>
> >>>>>>>devices, without new capability IDs.
> >>>>>>>
> >>>>>>>
> >>>>>>>>Anthony,
> >>>>>>>>
> >>>>>>>>Any comments to address this in xen case?
> >>>>>>>>
> >>>>>>>>Thanks
> >>>>>>>>Tiejun
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>_______________________________________________
> >>>Xen-devel mailing list
> >>>Xen-devel@lists.xen.org
> >>>http://lists.xen.org/xen-devel
> >>>
> >>>
> >

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
> On 2014/6/30 19:28, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/30 17:55, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >>>>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>Are you saying the config space in the video device?
> >>>>>>>>>
> >>>>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>>>MMIO BAR.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>>>offset or BAR in the config space.
> >>>>>>>>
> >>>>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>>>
> >>>>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>>>q35 as a PCIe machine of xen.
> >>>>>>>
> >>>>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>>>so you have the time to make it architecturally sound.
> >>>>>>>"Making existing guests work" would be a better motivation.
> >>>>>>
> >>>>>>Yes.
> >>>>>
> >>>>>So focus on this then. Existing guests will probably work
> >>>>>fine on a newer chipset - likely better than on i440fx.
> >>>>>xen management tools need to do some work to support this?
> >>>>>That will just give everyone more long term benefits.
> >>>>>
> >>>>>If instead we create a hack that does not resemble
> >>>>>any existing hardware even remotely, what's the
> >>>>>chance that it will not break with any future
> >>>>>guest modification?
> >>>>>
> >>>>>
> >>>>>>>Isn't this possible with an mch chipset?
> >>>>>>
> >>>>>>If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> >>>>>>MCH in xen case.
> >>>>>
> >>>>>q35 or a newer chipset that's closer to what guests expect.
> >>>>>
> >>>>>>Additionally, I think I should follow this feature after
> >>>>>>q35 can work for xen scenario.
> >>>>>
> >>>>>What's stopping you?
> >>>>
> >>>>I mean if you want create an new machine based on q35, actually this is
> >>>>equal to start making xen to migrate to q35 now. Right? I can't image how
> >>>>much effort should be done.
> >>>
> >>>I don't see why you don't try. Sounds like a more robust solution to me.
> >>
> >>As I think this is another requirement to us. I'm not sure if I have enough
> >>time to touch this currently.
> >>
> >>>
> >>>>So this is a reason why I'm saying I'd like to follow this feature after q35
> >>>>can work with xen completely.
> >>>
> >>>Then we'll end up with more configurations to support, and to what end?
> >>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>So could we do this step by step:
> >>>>>>>>
> >>>>>>>>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>>>>>>>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >>>>>>>
> >>>>>>>By the way there is no reason to put it at 00:1f.0 specifically I think.
> >>>>>>>So it seems simple: create a dummy device that gets device and
> >>>>>>>vendor id as properties. If you really like, add an option to get values
> >>>>>>
> >>>>>>Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> >>>>>>passthrough: create pseudo intel isa bridge. There, we fake this device just
> >>>>>>at 00:1f.0.
> >>>>>>But you guys don't like this, and shouldn't this be just this point we
> >>>>>>discussing now?
> >>>>>>
> >>>>>>If you guys agree that , everything is fine.
> >>>>>
> >>>>>Actually, this isn't what you did.
> >>>>>Don't tie it to xen, and don't tie it to 1f.
> >>>>>Just make it a simple stub pci device.
> >>>>>Whoever wants it, creates it.
> >>>>>
> >>>>>The thing I worry about, is the chance this will break going forward.
> >>>>>So you created a system with 2 isa bridges.
> >>>>
> >>>>I don't set class type to claim this is an ISA bridge, just a normal PCI
> >>>>device.
> >>>>+static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
> >>>>*hdev)
> >>>>+{
> >>>>+    struct PCIDevice *dev;
> >>>>+
> >>>>+    char rid;
> >>>>+
> >>>>+    /* We havt to use a simple PCI device to fake this ISA bridge
> >>>>+     * to avoid making some confusion to BIOS and ACPI.
> >>>>+     */
> >>>>+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
> >>>>"pseudo-intel-pch-isa-bridge");
> >>>>+
> >>>>+    qdev_init_nofail(&dev->qdev);
> >>>>+
> >>>>+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> >>>>+    pci_config_set_device_id(dev->config, hdev->device_id);
> >>>>+
> >>>>+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> >>>>+
> >>>>+    pci_config_set_revision(dev->config, rid);
> >>>>+
> >>>>+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> >>>>+    return 0;
> >>>>+}
> >>>
> >>>Then I don't see how it's supposed to work.
> >>>Doesn't i915 look for an isa bridge?
> >>>
> >>>         /*
> >>>          * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> >>>          * make graphics device passthrough work easy for VMM, that only
> >>>          * need to expose ISA bridge to let driver know the real hardware
> >>>          * underneath. This is a requirement from virtualization team.
> >>>          *
> >>>          * In some virtualized environments (e.g. XEN), there is irrelevant
> >>>          * ISA bridge in the system. To work reliably, we should scan trhough
> >>>          * all the ISA bridge devices and check for the first match, instead
> >>>          * of only checking the first one.
> >>>          */
> >>>         while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>>                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> >>>                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >>>                         dev_priv->pch_id = id;
> >>>
> >>>                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >>>                                 dev_priv->pch_type = PCH_IBX;
> >>>
> >>>etc
> >>>
> >>
> >>I already post this to mainline to change as follows:
> >>
> >>-	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>+	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> >>+	if (pch) {
> >
> >I see - responded on that mail - but I thought the point is to make
> >existing guests run? In fact you said so explicitly.
> >
> >
> >>Please refer to this,
> >>
> >>[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
> >>check class type
> >>
> >>Linux Native guys would like to accept this. And actually Windows always use
> >>devfn to detect this.
> >
> >In fact I see this:
> >
> >     linux 2.6.35-3.9 probes the 1st IA bridge
> >
> >         no idea how would you fix this.
> >         try changing default class for the main bridge?
> >
> >     linux 3.10 probes all ISA bridges
> >
> >         requires your stub to be the isa bridge?
> >
> >
> >I don't see why are driver guys so willing to do crazy things.  They
> >want to match specific device/vendor id pairs, why don't they do just
> >that? Why poke at class, random slot numbers etc etc?
> 
> AFAIK what they did is from our previous incorrect requirement as I
> understand. So we need to correct this.
> 
> Thanks
> Tiejun

Since we can't fix existing guests, I would say
get things working first, find a clean way for
new driver to work next.

> >
> >
> >
> >>>
> >>>
> >>>>>This is already not something that exists on real hardware.
> >>>>>So it might break some guests that will get confused.
> >>>>>Maybe we are lucky and most guests see an unfamiliar device
> >>>>>and ignore it. It seems believable.
> >>>>>
> >>>>>But your MCH hack overrides registers in the pci host.
> >>>>
> >>>>We just try to write *one* register we already confirm this is safe enough.
> >>>
> >>>This should go in code in form of comments:
> >>>document what this register does on 440fx
> >>>and why it's safe to override.
> >>>We don't see what you
> >>>confirmed off-line.
> >>
> >>That offset is one specific to IGD usage, not for i440fx common. This is why
> >>we need to expose something in the host bridge. They're just introduced to
> >>support IGD.
> >>
> >>>
> >>>>Other register are read-only.
> >>>
> >>>Doesn't matter, need to document these as well.
> >>
> >>I think everything are covered in igd_pci_write()/igd_pci_write().
> >>
> >>>
> >>>>>Are we lucky and there's nothing in these registers
> >>>>>of interest to guests? This seems much more fragile.
> >>>>>So please poke at the spec, and compile the list
> >>>>>of registers you want to touch, figure out why they are
> >>>>>safe to override, and put this all in code comments.
> >>>>>
> >>>>>And the same thing that applies to the isa bridge
> >>>>
> >>>>We just expose its own vendor/device ids here. We don't access to change
> >>>>anything in the isa bridge.
> >>>>
> >>>>>applies here too. It should work without QEMU touching
> >>>>>hosts' hardware.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>from sysfs: device and vendor id are world readable, so just get them
> >>>>>>>directly and not through xen wrappers, this way you can open the files
> >>>>>>>RO and not RW.
> >>>>>>>You seem to poke at revision as well, I don't see
> >>>>>>>driver looking at that - strictly necessary?
> >>>>>>>If yes please patch host kernel to expose that info in sysfs,
> >>>>>>>though we can fall back on pci config if not there.
> >>>>>>>
> >>>>>>>MCH (bridge_dev) hacks in i915 are nastier.
> >>>>>>>To clean them up, we really have to have an explicit driver for this
> >>>>>>>bridge, not a pass-through device.  Long term, the right thing to do is
> >>>>>>>likely to extend host driver and expose the necessary information in
> >>>>>>>sysfs on host kernel.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>I'm a bit confused. Any sysfs should be filled by the associated PCIe
> >>>>>>device, shouldn't it? So qemu still need to emulate this PCIe device
> >>>>>>firstly, then set properties into sysfs.
> >>>>>
> >>>>>I am talking about getting host properties into qemu.
> >>>>>You don't want to give qemu R/W root access to host sysfs system
> >>>>>of the root bridge, that's not secure.
> >>>>
> >>>>igd_pci_read()
> >>>>	|
> >>>>	+ xen_host_pci_get_block()
> >>>>		|
> >>>>		+ xen_host_pci_config_read(()
> >>>>			|
> >>>>			+  pread()
> >>>>
> >>>>So shouldn't we already expose these information via sysfs?
> >>>
> >>>That's poking at sysfs of a real device, and after opening it RW.
> >>
> >>I don't think we can really write anything to those read-only sysfs
> >>interface even we open them as RW.
> >>
> >>Tiejun
> >>
> >>>
> >>>>>Avoiding read only access to filesystem is a good idea too, so it
> >>>>>should be possible to pass all parameters in as
> >>>>>device properties, and let whoever starts qemu
> >>>>>figure out what are reasonable values.
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>>>>>>>others. To do this properly, we need to get one from PCI SIG group. To have
> >>>>>>>>this workable and consistently validated, this method shouldn't be virt
> >>>>>>>>specific. Then native driver should use the same method.
> >>>>>>>
> >>>>>>>You mean you will be able to talk sense into hardware guys?
> >>>>>>>I doubt that. If they could be convinced to make e.g. i915 base a
> >>>>>>
> >>>>>>We're negotiating this, so this is just our long term solution we figure out
> >>>>>>currently.
> >>>>>>
> >>>>>>>proper BAR, why didn't they?
> >>>>>>
> >>>>>>We already have no any free BAR as we mentioned previously.
> >>>>>
> >>>>>I thought you were talking about modifying hardware?
> >>>>
> >>>>Yes.
> >>>>
> >>>>Tiejun
> >>>
> >>>And they can't figure out how to stick extra info in an existing BAR?
> >>>Oh well, that's hardware for you.
> >>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>So when xen work on
> >>>>>>>>q35 PCIe machine, we can walk this way.
> >>>>>>>
> >>>>>>>If you are emulating MCH anyway, pick one that is close
> >>>>>>>to what i915 driver expects. It would then work with existing
> >>>>>>
> >>>>>>Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> >>>>>>to create a new based on i440fx just for a little change?
> >>>>>>
> >>>>>>Thanks
> >>>>>>Tiejun
> >>>>>
> >>>>>You can inherit it. Maybe you are lucky and this happens to
> >>>>>work without conflicting with whatever other guests want to do.
> >>>>>But if you ask me, you are really just piling up hacks.
> >>>>>If some guest does not work on i440, you should just work on
> >>>>>emulating whatever it does work on.
> >>>>>That would have real value.
> >>>>>
> >>>>>>>devices, without new capability IDs.
> >>>>>>>
> >>>>>>>
> >>>>>>>>Anthony,
> >>>>>>>>
> >>>>>>>>Any comments to address this in xen case?
> >>>>>>>>
> >>>>>>>>Thanks
> >>>>>>>>Tiejun
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>_______________________________________________
> >>>Xen-devel mailing list
> >>>Xen-devel@lists.xen.org
> >>>http://lists.xen.org/xen-devel
> >>>
> >>>
> >

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/1 17:12, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
>> On 2014/6/30 19:28, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/30 17:55, Michael S. Tsirkin wrote:
>>>>> On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>>
>>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>>> MMIO BAR.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>>
>>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>>
>>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>>
>>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>
>>>>>>> So focus on this then. Existing guests will probably work
>>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>>> xen management tools need to do some work to support this?
>>>>>>> That will just give everyone more long term benefits.
>>>>>>>
>>>>>>> If instead we create a hack that does not resemble
>>>>>>> any existing hardware even remotely, what's the
>>>>>>> chance that it will not break with any future
>>>>>>> guest modification?
>>>>>>>
>>>>>>>
>>>>>>>>> Isn't this possible with an mch chipset?
>>>>>>>>
>>>>>>>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>>>>>>>> MCH in xen case.
>>>>>>>
>>>>>>> q35 or a newer chipset that's closer to what guests expect.
>>>>>>>
>>>>>>>> Additionally, I think I should follow this feature after
>>>>>>>> q35 can work for xen scenario.
>>>>>>>
>>>>>>> What's stopping you?
>>>>>>
>>>>>> I mean if you want create an new machine based on q35, actually this is
>>>>>> equal to start making xen to migrate to q35 now. Right? I can't image how
>>>>>> much effort should be done.
>>>>>
>>>>> I don't see why you don't try. Sounds like a more robust solution to me.
>>>>
>>>> As I think this is another requirement to us. I'm not sure if I have enough
>>>> time to touch this currently.
>>>>
>>>>>
>>>>>> So this is a reason why I'm saying I'd like to follow this feature after q35
>>>>>> can work with xen completely.
>>>>>
>>>>> Then we'll end up with more configurations to support, and to what end?
>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So could we do this step by step:
>>>>>>>>>>
>>>>>>>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>>>>>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>>>>>>>
>>>>>>>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>>>>>>>> So it seems simple: create a dummy device that gets device and
>>>>>>>>> vendor id as properties. If you really like, add an option to get values
>>>>>>>>
>>>>>>>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>>>>>>>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>>>>>>>> at 00:1f.0.
>>>>>>>> But you guys don't like this, and shouldn't this be just this point we
>>>>>>>> discussing now?
>>>>>>>>
>>>>>>>> If you guys agree that , everything is fine.
>>>>>>>
>>>>>>> Actually, this isn't what you did.
>>>>>>> Don't tie it to xen, and don't tie it to 1f.
>>>>>>> Just make it a simple stub pci device.
>>>>>>> Whoever wants it, creates it.
>>>>>>>
>>>>>>> The thing I worry about, is the chance this will break going forward.
>>>>>>> So you created a system with 2 isa bridges.
>>>>>>
>>>>>> I don't set class type to claim this is an ISA bridge, just a normal PCI
>>>>>> device.
>>>>>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>>>>>> *hdev)
>>>>>> +{
>>>>>> +    struct PCIDevice *dev;
>>>>>> +
>>>>>> +    char rid;
>>>>>> +
>>>>>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>>>>>> +     * to avoid making some confusion to BIOS and ACPI.
>>>>>> +     */
>>>>>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>>>>>> "pseudo-intel-pch-isa-bridge");
>>>>>> +
>>>>>> +    qdev_init_nofail(&dev->qdev);
>>>>>> +
>>>>>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>>>>>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>>>>>> +
>>>>>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>>>>>> +
>>>>>> +    pci_config_set_revision(dev->config, rid);
>>>>>> +
>>>>>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>>>>> +    return 0;
>>>>>> +}
>>>>>
>>>>> Then I don't see how it's supposed to work.
>>>>> Doesn't i915 look for an isa bridge?
>>>>>
>>>>>          /*
>>>>>           * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>>>>>           * make graphics device passthrough work easy for VMM, that only
>>>>>           * need to expose ISA bridge to let driver know the real hardware
>>>>>           * underneath. This is a requirement from virtualization team.
>>>>>           *
>>>>>           * In some virtualized environments (e.g. XEN), there is irrelevant
>>>>>           * ISA bridge in the system. To work reliably, we should scan trhough
>>>>>           * all the ISA bridge devices and check for the first match, instead
>>>>>           * of only checking the first one.
>>>>>           */
>>>>>          while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>>>                  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>                          unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>                          dev_priv->pch_id = id;
>>>>>
>>>>>                          if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>                                  dev_priv->pch_type = PCH_IBX;
>>>>>
>>>>> etc
>>>>>
>>>>
>>>> I already post this to mainline to change as follows:
>>>>
>>>> -	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>> +	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>>>> +	if (pch) {
>>>
>>> I see - responded on that mail - but I thought the point is to make
>>> existing guests run? In fact you said so explicitly.
>>>
>>>
>>>> Please refer to this,
>>>>
>>>> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
>>>> check class type
>>>>
>>>> Linux Native guys would like to accept this. And actually Windows always use
>>>> devfn to detect this.
>>>
>>> In fact I see this:
>>>
>>>      linux 2.6.35-3.9 probes the 1st IA bridge
>>>
>>>          no idea how would you fix this.
>>>          try changing default class for the main bridge?
>>>
>>>      linux 3.10 probes all ISA bridges
>>>
>>>          requires your stub to be the isa bridge?
>>>
>>>
>>> I don't see why are driver guys so willing to do crazy things.  They
>>> want to match specific device/vendor id pairs, why don't they do just
>>> that? Why poke at class, random slot numbers etc etc?
>>
>> AFAIK what they did is from our previous incorrect requirement as I
>> understand. So we need to correct this.
>>
>> Thanks
>> Tiejun
>
> Since we can't fix existing guests, I would say

This shouldn't be a fix existing guest, and this is why I can send this 
before you guys accept GFX passthrough for qemu ML.

I think you can re-read that patch head description. 1f.0 can work under 
all scenarios including qemu-xen-traditonal.

And this is also expected by native Linux organically, and especially 
Windows always use devfn to detect PCH, this is not like current Linux. 
So here I just sync this to make sense.

Unless you'd like to make Linux specific to this point.

Tiejun

> get things working first, find a clean way for
> new driver to work next.
>
>>>
>>>
>>>
>>>>>
>>>>>
>>>>>>> This is already not something that exists on real hardware.
>>>>>>> So it might break some guests that will get confused.
>>>>>>> Maybe we are lucky and most guests see an unfamiliar device
>>>>>>> and ignore it. It seems believable.
>>>>>>>
>>>>>>> But your MCH hack overrides registers in the pci host.
>>>>>>
>>>>>> We just try to write *one* register we already confirm this is safe enough.
>>>>>
>>>>> This should go in code in form of comments:
>>>>> document what this register does on 440fx
>>>>> and why it's safe to override.
>>>>> We don't see what you
>>>>> confirmed off-line.
>>>>
>>>> That offset is one specific to IGD usage, not for i440fx common. This is why
>>>> we need to expose something in the host bridge. They're just introduced to
>>>> support IGD.
>>>>
>>>>>
>>>>>> Other register are read-only.
>>>>>
>>>>> Doesn't matter, need to document these as well.
>>>>
>>>> I think everything are covered in igd_pci_write()/igd_pci_write().
>>>>
>>>>>
>>>>>>> Are we lucky and there's nothing in these registers
>>>>>>> of interest to guests? This seems much more fragile.
>>>>>>> So please poke at the spec, and compile the list
>>>>>>> of registers you want to touch, figure out why they are
>>>>>>> safe to override, and put this all in code comments.
>>>>>>>
>>>>>>> And the same thing that applies to the isa bridge
>>>>>>
>>>>>> We just expose its own vendor/device ids here. We don't access to change
>>>>>> anything in the isa bridge.
>>>>>>
>>>>>>> applies here too. It should work without QEMU touching
>>>>>>> hosts' hardware.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> >from sysfs: device and vendor id are world readable, so just get them
>>>>>>>>> directly and not through xen wrappers, this way you can open the files
>>>>>>>>> RO and not RW.
>>>>>>>>> You seem to poke at revision as well, I don't see
>>>>>>>>> driver looking at that - strictly necessary?
>>>>>>>>> If yes please patch host kernel to expose that info in sysfs,
>>>>>>>>> though we can fall back on pci config if not there.
>>>>>>>>>
>>>>>>>>> MCH (bridge_dev) hacks in i915 are nastier.
>>>>>>>>> To clean them up, we really have to have an explicit driver for this
>>>>>>>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>>>>>>>> likely to extend host driver and expose the necessary information in
>>>>>>>>> sysfs on host kernel.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>>>>>>>> device, shouldn't it? So qemu still need to emulate this PCIe device
>>>>>>>> firstly, then set properties into sysfs.
>>>>>>>
>>>>>>> I am talking about getting host properties into qemu.
>>>>>>> You don't want to give qemu R/W root access to host sysfs system
>>>>>>> of the root bridge, that's not secure.
>>>>>>
>>>>>> igd_pci_read()
>>>>>> 	|
>>>>>> 	+ xen_host_pci_get_block()
>>>>>> 		|
>>>>>> 		+ xen_host_pci_config_read(()
>>>>>> 			|
>>>>>> 			+  pread()
>>>>>>
>>>>>> So shouldn't we already expose these information via sysfs?
>>>>>
>>>>> That's poking at sysfs of a real device, and after opening it RW.
>>>>
>>>> I don't think we can really write anything to those read-only sysfs
>>>> interface even we open them as RW.
>>>>
>>>> Tiejun
>>>>
>>>>>
>>>>>>> Avoiding read only access to filesystem is a good idea too, so it
>>>>>>> should be possible to pass all parameters in as
>>>>>>> device properties, and let whoever starts qemu
>>>>>>> figure out what are reasonable values.
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>>>>>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>>>>>>>> this workable and consistently validated, this method shouldn't be virt
>>>>>>>>>> specific. Then native driver should use the same method.
>>>>>>>>>
>>>>>>>>> You mean you will be able to talk sense into hardware guys?
>>>>>>>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>>>>>>>
>>>>>>>> We're negotiating this, so this is just our long term solution we figure out
>>>>>>>> currently.
>>>>>>>>
>>>>>>>>> proper BAR, why didn't they?
>>>>>>>>
>>>>>>>> We already have no any free BAR as we mentioned previously.
>>>>>>>
>>>>>>> I thought you were talking about modifying hardware?
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> Tiejun
>>>>>
>>>>> And they can't figure out how to stick extra info in an existing BAR?
>>>>> Oh well, that's hardware for you.
>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So when xen work on
>>>>>>>>>> q35 PCIe machine, we can walk this way.
>>>>>>>>>
>>>>>>>>> If you are emulating MCH anyway, pick one that is close
>>>>>>>>> to what i915 driver expects. It would then work with existing
>>>>>>>>
>>>>>>>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>>>>>>>> to create a new based on i440fx just for a little change?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Tiejun
>>>>>>>
>>>>>>> You can inherit it. Maybe you are lucky and this happens to
>>>>>>> work without conflicting with whatever other guests want to do.
>>>>>>> But if you ask me, you are really just piling up hacks.
>>>>>>> If some guest does not work on i440, you should just work on
>>>>>>> emulating whatever it does work on.
>>>>>>> That would have real value.
>>>>>>>
>>>>>>>>> devices, without new capability IDs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Anthony,
>>>>>>>>>>
>>>>>>>>>> Any comments to address this in xen case?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Tiejun
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xen.org
>>>>> http://lists.xen.org/xen-devel
>>>>>
>>>>>
>>>
>
>

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/1 17:12, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
>> On 2014/6/30 19:28, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/30 17:55, Michael S. Tsirkin wrote:
>>>>> On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>>
>>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>>> MMIO BAR.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>>
>>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>>
>>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>>
>>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>
>>>>>>> So focus on this then. Existing guests will probably work
>>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>>> xen management tools need to do some work to support this?
>>>>>>> That will just give everyone more long term benefits.
>>>>>>>
>>>>>>> If instead we create a hack that does not resemble
>>>>>>> any existing hardware even remotely, what's the
>>>>>>> chance that it will not break with any future
>>>>>>> guest modification?
>>>>>>>
>>>>>>>
>>>>>>>>> Isn't this possible with an mch chipset?
>>>>>>>>
>>>>>>>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>>>>>>>> MCH in xen case.
>>>>>>>
>>>>>>> q35 or a newer chipset that's closer to what guests expect.
>>>>>>>
>>>>>>>> Additionally, I think I should follow this feature after
>>>>>>>> q35 can work for xen scenario.
>>>>>>>
>>>>>>> What's stopping you?
>>>>>>
>>>>>> I mean if you want create an new machine based on q35, actually this is
>>>>>> equal to start making xen to migrate to q35 now. Right? I can't image how
>>>>>> much effort should be done.
>>>>>
>>>>> I don't see why you don't try. Sounds like a more robust solution to me.
>>>>
>>>> As I think this is another requirement to us. I'm not sure if I have enough
>>>> time to touch this currently.
>>>>
>>>>>
>>>>>> So this is a reason why I'm saying I'd like to follow this feature after q35
>>>>>> can work with xen completely.
>>>>>
>>>>> Then we'll end up with more configurations to support, and to what end?
>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So could we do this step by step:
>>>>>>>>>>
>>>>>>>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>>>>>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>>>>>>>
>>>>>>>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>>>>>>>> So it seems simple: create a dummy device that gets device and
>>>>>>>>> vendor id as properties. If you really like, add an option to get values
>>>>>>>>
>>>>>>>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>>>>>>>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>>>>>>>> at 00:1f.0.
>>>>>>>> But you guys don't like this, and shouldn't this be just this point we
>>>>>>>> discussing now?
>>>>>>>>
>>>>>>>> If you guys agree that , everything is fine.
>>>>>>>
>>>>>>> Actually, this isn't what you did.
>>>>>>> Don't tie it to xen, and don't tie it to 1f.
>>>>>>> Just make it a simple stub pci device.
>>>>>>> Whoever wants it, creates it.
>>>>>>>
>>>>>>> The thing I worry about, is the chance this will break going forward.
>>>>>>> So you created a system with 2 isa bridges.
>>>>>>
>>>>>> I don't set class type to claim this is an ISA bridge, just a normal PCI
>>>>>> device.
>>>>>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>>>>>> *hdev)
>>>>>> +{
>>>>>> +    struct PCIDevice *dev;
>>>>>> +
>>>>>> +    char rid;
>>>>>> +
>>>>>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>>>>>> +     * to avoid making some confusion to BIOS and ACPI.
>>>>>> +     */
>>>>>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>>>>>> "pseudo-intel-pch-isa-bridge");
>>>>>> +
>>>>>> +    qdev_init_nofail(&dev->qdev);
>>>>>> +
>>>>>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>>>>>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>>>>>> +
>>>>>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>>>>>> +
>>>>>> +    pci_config_set_revision(dev->config, rid);
>>>>>> +
>>>>>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>>>>> +    return 0;
>>>>>> +}
>>>>>
>>>>> Then I don't see how it's supposed to work.
>>>>> Doesn't i915 look for an isa bridge?
>>>>>
>>>>>          /*
>>>>>           * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>>>>>           * make graphics device passthrough work easy for VMM, that only
>>>>>           * need to expose ISA bridge to let driver know the real hardware
>>>>>           * underneath. This is a requirement from virtualization team.
>>>>>           *
>>>>>           * In some virtualized environments (e.g. XEN), there is irrelevant
>>>>>           * ISA bridge in the system. To work reliably, we should scan trhough
>>>>>           * all the ISA bridge devices and check for the first match, instead
>>>>>           * of only checking the first one.
>>>>>           */
>>>>>          while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>>>                  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>                          unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>                          dev_priv->pch_id = id;
>>>>>
>>>>>                          if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>                                  dev_priv->pch_type = PCH_IBX;
>>>>>
>>>>> etc
>>>>>
>>>>
>>>> I already post this to mainline to change as follows:
>>>>
>>>> -	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>> +	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>>>> +	if (pch) {
>>>
>>> I see - responded on that mail - but I thought the point is to make
>>> existing guests run? In fact you said so explicitly.
>>>
>>>
>>>> Please refer to this,
>>>>
>>>> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
>>>> check class type
>>>>
>>>> Linux Native guys would like to accept this. And actually Windows always use
>>>> devfn to detect this.
>>>
>>> In fact I see this:
>>>
>>>      linux 2.6.35-3.9 probes the 1st IA bridge
>>>
>>>          no idea how would you fix this.
>>>          try changing default class for the main bridge?
>>>
>>>      linux 3.10 probes all ISA bridges
>>>
>>>          requires your stub to be the isa bridge?
>>>
>>>
>>> I don't see why are driver guys so willing to do crazy things.  They
>>> want to match specific device/vendor id pairs, why don't they do just
>>> that? Why poke at class, random slot numbers etc etc?
>>
>> AFAIK what they did is from our previous incorrect requirement as I
>> understand. So we need to correct this.
>>
>> Thanks
>> Tiejun
>
> Since we can't fix existing guests, I would say

This shouldn't be a fix existing guest, and this is why I can send this 
before you guys accept GFX passthrough for qemu ML.

I think you can re-read that patch head description. 1f.0 can work under 
all scenarios including qemu-xen-traditonal.

And this is also expected by native Linux organically, and especially 
Windows always use devfn to detect PCH, this is not like current Linux. 
So here I just sync this to make sense.

Unless you'd like to make Linux specific to this point.

Tiejun

> get things working first, find a clean way for
> new driver to work next.
>
>>>
>>>
>>>
>>>>>
>>>>>
>>>>>>> This is already not something that exists on real hardware.
>>>>>>> So it might break some guests that will get confused.
>>>>>>> Maybe we are lucky and most guests see an unfamiliar device
>>>>>>> and ignore it. It seems believable.
>>>>>>>
>>>>>>> But your MCH hack overrides registers in the pci host.
>>>>>>
>>>>>> We just try to write *one* register we already confirm this is safe enough.
>>>>>
>>>>> This should go in code in form of comments:
>>>>> document what this register does on 440fx
>>>>> and why it's safe to override.
>>>>> We don't see what you
>>>>> confirmed off-line.
>>>>
>>>> That offset is one specific to IGD usage, not for i440fx common. This is why
>>>> we need to expose something in the host bridge. They're just introduced to
>>>> support IGD.
>>>>
>>>>>
>>>>>> Other register are read-only.
>>>>>
>>>>> Doesn't matter, need to document these as well.
>>>>
>>>> I think everything are covered in igd_pci_write()/igd_pci_write().
>>>>
>>>>>
>>>>>>> Are we lucky and there's nothing in these registers
>>>>>>> of interest to guests? This seems much more fragile.
>>>>>>> So please poke at the spec, and compile the list
>>>>>>> of registers you want to touch, figure out why they are
>>>>>>> safe to override, and put this all in code comments.
>>>>>>>
>>>>>>> And the same thing that applies to the isa bridge
>>>>>>
>>>>>> We just expose its own vendor/device ids here. We don't access to change
>>>>>> anything in the isa bridge.
>>>>>>
>>>>>>> applies here too. It should work without QEMU touching
>>>>>>> hosts' hardware.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> >from sysfs: device and vendor id are world readable, so just get them
>>>>>>>>> directly and not through xen wrappers, this way you can open the files
>>>>>>>>> RO and not RW.
>>>>>>>>> You seem to poke at revision as well, I don't see
>>>>>>>>> driver looking at that - strictly necessary?
>>>>>>>>> If yes please patch host kernel to expose that info in sysfs,
>>>>>>>>> though we can fall back on pci config if not there.
>>>>>>>>>
>>>>>>>>> MCH (bridge_dev) hacks in i915 are nastier.
>>>>>>>>> To clean them up, we really have to have an explicit driver for this
>>>>>>>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>>>>>>>> likely to extend host driver and expose the necessary information in
>>>>>>>>> sysfs on host kernel.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>>>>>>>> device, shouldn't it? So qemu still need to emulate this PCIe device
>>>>>>>> firstly, then set properties into sysfs.
>>>>>>>
>>>>>>> I am talking about getting host properties into qemu.
>>>>>>> You don't want to give qemu R/W root access to host sysfs system
>>>>>>> of the root bridge, that's not secure.
>>>>>>
>>>>>> igd_pci_read()
>>>>>> 	|
>>>>>> 	+ xen_host_pci_get_block()
>>>>>> 		|
>>>>>> 		+ xen_host_pci_config_read(()
>>>>>> 			|
>>>>>> 			+  pread()
>>>>>>
>>>>>> So shouldn't we already expose these information via sysfs?
>>>>>
>>>>> That's poking at sysfs of a real device, and after opening it RW.
>>>>
>>>> I don't think we can really write anything to those read-only sysfs
>>>> interface even we open them as RW.
>>>>
>>>> Tiejun
>>>>
>>>>>
>>>>>>> Avoiding read only access to filesystem is a good idea too, so it
>>>>>>> should be possible to pass all parameters in as
>>>>>>> device properties, and let whoever starts qemu
>>>>>>> figure out what are reasonable values.
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>>>>>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>>>>>>>> this workable and consistently validated, this method shouldn't be virt
>>>>>>>>>> specific. Then native driver should use the same method.
>>>>>>>>>
>>>>>>>>> You mean you will be able to talk sense into hardware guys?
>>>>>>>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>>>>>>>
>>>>>>>> We're negotiating this, so this is just our long term solution we figure out
>>>>>>>> currently.
>>>>>>>>
>>>>>>>>> proper BAR, why didn't they?
>>>>>>>>
>>>>>>>> We already have no any free BAR as we mentioned previously.
>>>>>>>
>>>>>>> I thought you were talking about modifying hardware?
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> Tiejun
>>>>>
>>>>> And they can't figure out how to stick extra info in an existing BAR?
>>>>> Oh well, that's hardware for you.
>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So when xen work on
>>>>>>>>>> q35 PCIe machine, we can walk this way.
>>>>>>>>>
>>>>>>>>> If you are emulating MCH anyway, pick one that is close
>>>>>>>>> to what i915 driver expects. It would then work with existing
>>>>>>>>
>>>>>>>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>>>>>>>> to create a new based on i440fx just for a little change?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Tiejun
>>>>>>>
>>>>>>> You can inherit it. Maybe you are lucky and this happens to
>>>>>>> work without conflicting with whatever other guests want to do.
>>>>>>> But if you ask me, you are really just piling up hacks.
>>>>>>> If some guest does not work on i440, you should just work on
>>>>>>> emulating whatever it does work on.
>>>>>>> That would have real value.
>>>>>>>
>>>>>>>>> devices, without new capability IDs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Anthony,
>>>>>>>>>>
>>>>>>>>>> Any comments to address this in xen case?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Tiejun
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xen.org
>>>>> http://lists.xen.org/xen-devel
>>>>>
>>>>>
>>>
>
>

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 05:46:58PM +0800, Chen, Tiejun wrote:
> On 2014/7/1 17:12, Michael S. Tsirkin wrote:
> >On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
> >>On 2014/6/30 19:28, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/30 17:55, Michael S. Tsirkin wrote:
> >>>>>On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >>>>>>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>>>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>Are you saying the config space in the video device?
> >>>>>>>>>>>
> >>>>>>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>>>>>MMIO BAR.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>>>>>offset or BAR in the config space.
> >>>>>>>>>>
> >>>>>>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>>>>>
> >>>>>>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>>>>>q35 as a PCIe machine of xen.
> >>>>>>>>>
> >>>>>>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>>>>>so you have the time to make it architecturally sound.
> >>>>>>>>>"Making existing guests work" would be a better motivation.
> >>>>>>>>
> >>>>>>>>Yes.
> >>>>>>>
> >>>>>>>So focus on this then. Existing guests will probably work
> >>>>>>>fine on a newer chipset - likely better than on i440fx.
> >>>>>>>xen management tools need to do some work to support this?
> >>>>>>>That will just give everyone more long term benefits.
> >>>>>>>
> >>>>>>>If instead we create a hack that does not resemble
> >>>>>>>any existing hardware even remotely, what's the
> >>>>>>>chance that it will not break with any future
> >>>>>>>guest modification?
> >>>>>>>
> >>>>>>>
> >>>>>>>>>Isn't this possible with an mch chipset?
> >>>>>>>>
> >>>>>>>>If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> >>>>>>>>MCH in xen case.
> >>>>>>>
> >>>>>>>q35 or a newer chipset that's closer to what guests expect.
> >>>>>>>
> >>>>>>>>Additionally, I think I should follow this feature after
> >>>>>>>>q35 can work for xen scenario.
> >>>>>>>
> >>>>>>>What's stopping you?
> >>>>>>
> >>>>>>I mean if you want create an new machine based on q35, actually this is
> >>>>>>equal to start making xen to migrate to q35 now. Right? I can't image how
> >>>>>>much effort should be done.
> >>>>>
> >>>>>I don't see why you don't try. Sounds like a more robust solution to me.
> >>>>
> >>>>As I think this is another requirement to us. I'm not sure if I have enough
> >>>>time to touch this currently.
> >>>>
> >>>>>
> >>>>>>So this is a reason why I'm saying I'd like to follow this feature after q35
> >>>>>>can work with xen completely.
> >>>>>
> >>>>>Then we'll end up with more configurations to support, and to what end?
> >>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>So could we do this step by step:
> >>>>>>>>>>
> >>>>>>>>>>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>>>>>>>>>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >>>>>>>>>
> >>>>>>>>>By the way there is no reason to put it at 00:1f.0 specifically I think.
> >>>>>>>>>So it seems simple: create a dummy device that gets device and
> >>>>>>>>>vendor id as properties. If you really like, add an option to get values
> >>>>>>>>
> >>>>>>>>Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> >>>>>>>>passthrough: create pseudo intel isa bridge. There, we fake this device just
> >>>>>>>>at 00:1f.0.
> >>>>>>>>But you guys don't like this, and shouldn't this be just this point we
> >>>>>>>>discussing now?
> >>>>>>>>
> >>>>>>>>If you guys agree that , everything is fine.
> >>>>>>>
> >>>>>>>Actually, this isn't what you did.
> >>>>>>>Don't tie it to xen, and don't tie it to 1f.
> >>>>>>>Just make it a simple stub pci device.
> >>>>>>>Whoever wants it, creates it.
> >>>>>>>
> >>>>>>>The thing I worry about, is the chance this will break going forward.
> >>>>>>>So you created a system with 2 isa bridges.
> >>>>>>
> >>>>>>I don't set class type to claim this is an ISA bridge, just a normal PCI
> >>>>>>device.
> >>>>>>+static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
> >>>>>>*hdev)
> >>>>>>+{
> >>>>>>+    struct PCIDevice *dev;
> >>>>>>+
> >>>>>>+    char rid;
> >>>>>>+
> >>>>>>+    /* We havt to use a simple PCI device to fake this ISA bridge
> >>>>>>+     * to avoid making some confusion to BIOS and ACPI.
> >>>>>>+     */
> >>>>>>+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
> >>>>>>"pseudo-intel-pch-isa-bridge");
> >>>>>>+
> >>>>>>+    qdev_init_nofail(&dev->qdev);
> >>>>>>+
> >>>>>>+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> >>>>>>+    pci_config_set_device_id(dev->config, hdev->device_id);
> >>>>>>+
> >>>>>>+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> >>>>>>+
> >>>>>>+    pci_config_set_revision(dev->config, rid);
> >>>>>>+
> >>>>>>+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> >>>>>>+    return 0;
> >>>>>>+}
> >>>>>
> >>>>>Then I don't see how it's supposed to work.
> >>>>>Doesn't i915 look for an isa bridge?
> >>>>>
> >>>>>         /*
> >>>>>          * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> >>>>>          * make graphics device passthrough work easy for VMM, that only
> >>>>>          * need to expose ISA bridge to let driver know the real hardware
> >>>>>          * underneath. This is a requirement from virtualization team.
> >>>>>          *
> >>>>>          * In some virtualized environments (e.g. XEN), there is irrelevant
> >>>>>          * ISA bridge in the system. To work reliably, we should scan trhough
> >>>>>          * all the ISA bridge devices and check for the first match, instead
> >>>>>          * of only checking the first one.
> >>>>>          */
> >>>>>         while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>>>>                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> >>>>>                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >>>>>                         dev_priv->pch_id = id;
> >>>>>
> >>>>>                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >>>>>                                 dev_priv->pch_type = PCH_IBX;
> >>>>>
> >>>>>etc
> >>>>>
> >>>>
> >>>>I already post this to mainline to change as follows:
> >>>>
> >>>>-	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>>>+	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> >>>>+	if (pch) {
> >>>
> >>>I see - responded on that mail - but I thought the point is to make
> >>>existing guests run? In fact you said so explicitly.
> >>>
> >>>
> >>>>Please refer to this,
> >>>>
> >>>>[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
> >>>>check class type
> >>>>
> >>>>Linux Native guys would like to accept this. And actually Windows always use
> >>>>devfn to detect this.
> >>>
> >>>In fact I see this:
> >>>
> >>>     linux 2.6.35-3.9 probes the 1st IA bridge
> >>>
> >>>         no idea how would you fix this.
> >>>         try changing default class for the main bridge?
> >>>
> >>>     linux 3.10 probes all ISA bridges
> >>>
> >>>         requires your stub to be the isa bridge?
> >>>
> >>>
> >>>I don't see why are driver guys so willing to do crazy things.  They
> >>>want to match specific device/vendor id pairs, why don't they do just
> >>>that? Why poke at class, random slot numbers etc etc?
> >>
> >>AFAIK what they did is from our previous incorrect requirement as I
> >>understand. So we need to correct this.
> >>
> >>Thanks
> >>Tiejun
> >
> >Since we can't fix existing guests, I would say
> 
> This shouldn't be a fix existing guest, and this is why I can send this
> before you guys accept GFX passthrough for qemu ML.
> 
> I think you can re-read that patch head description. 1f.0 can work under all
> scenarios including qemu-xen-traditonal.
> 
> And this is also expected by native Linux organically, and especially
> Windows always use devfn to detect PCH, this is not like current Linux. So
> here I just sync this to make sense.
> 
> Unless you'd like to make Linux specific to this point.
> 
> Tiejun

Why don't both windows and linux drivers look device up
by device and vendor id?
Same applies to MCH really.


> >get things working first, find a clean way for
> >new driver to work next.
> >
> >>>
> >>>
> >>>
> >>>>>
> >>>>>
> >>>>>>>This is already not something that exists on real hardware.
> >>>>>>>So it might break some guests that will get confused.
> >>>>>>>Maybe we are lucky and most guests see an unfamiliar device
> >>>>>>>and ignore it. It seems believable.
> >>>>>>>
> >>>>>>>But your MCH hack overrides registers in the pci host.
> >>>>>>
> >>>>>>We just try to write *one* register we already confirm this is safe enough.
> >>>>>
> >>>>>This should go in code in form of comments:
> >>>>>document what this register does on 440fx
> >>>>>and why it's safe to override.
> >>>>>We don't see what you
> >>>>>confirmed off-line.
> >>>>
> >>>>That offset is one specific to IGD usage, not for i440fx common. This is why
> >>>>we need to expose something in the host bridge. They're just introduced to
> >>>>support IGD.
> >>>>
> >>>>>
> >>>>>>Other register are read-only.
> >>>>>
> >>>>>Doesn't matter, need to document these as well.
> >>>>
> >>>>I think everything are covered in igd_pci_write()/igd_pci_write().
> >>>>
> >>>>>
> >>>>>>>Are we lucky and there's nothing in these registers
> >>>>>>>of interest to guests? This seems much more fragile.
> >>>>>>>So please poke at the spec, and compile the list
> >>>>>>>of registers you want to touch, figure out why they are
> >>>>>>>safe to override, and put this all in code comments.
> >>>>>>>
> >>>>>>>And the same thing that applies to the isa bridge
> >>>>>>
> >>>>>>We just expose its own vendor/device ids here. We don't access to change
> >>>>>>anything in the isa bridge.
> >>>>>>
> >>>>>>>applies here too. It should work without QEMU touching
> >>>>>>>hosts' hardware.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>from sysfs: device and vendor id are world readable, so just get them
> >>>>>>>>>directly and not through xen wrappers, this way you can open the files
> >>>>>>>>>RO and not RW.
> >>>>>>>>>You seem to poke at revision as well, I don't see
> >>>>>>>>>driver looking at that - strictly necessary?
> >>>>>>>>>If yes please patch host kernel to expose that info in sysfs,
> >>>>>>>>>though we can fall back on pci config if not there.
> >>>>>>>>>
> >>>>>>>>>MCH (bridge_dev) hacks in i915 are nastier.
> >>>>>>>>>To clean them up, we really have to have an explicit driver for this
> >>>>>>>>>bridge, not a pass-through device.  Long term, the right thing to do is
> >>>>>>>>>likely to extend host driver and expose the necessary information in
> >>>>>>>>>sysfs on host kernel.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>I'm a bit confused. Any sysfs should be filled by the associated PCIe
> >>>>>>>>device, shouldn't it? So qemu still need to emulate this PCIe device
> >>>>>>>>firstly, then set properties into sysfs.
> >>>>>>>
> >>>>>>>I am talking about getting host properties into qemu.
> >>>>>>>You don't want to give qemu R/W root access to host sysfs system
> >>>>>>>of the root bridge, that's not secure.
> >>>>>>
> >>>>>>igd_pci_read()
> >>>>>>	|
> >>>>>>	+ xen_host_pci_get_block()
> >>>>>>		|
> >>>>>>		+ xen_host_pci_config_read(()
> >>>>>>			|
> >>>>>>			+  pread()
> >>>>>>
> >>>>>>So shouldn't we already expose these information via sysfs?
> >>>>>
> >>>>>That's poking at sysfs of a real device, and after opening it RW.
> >>>>
> >>>>I don't think we can really write anything to those read-only sysfs
> >>>>interface even we open them as RW.
> >>>>
> >>>>Tiejun
> >>>>
> >>>>>
> >>>>>>>Avoiding read only access to filesystem is a good idea too, so it
> >>>>>>>should be possible to pass all parameters in as
> >>>>>>>device properties, and let whoever starts qemu
> >>>>>>>figure out what are reasonable values.
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>>>>>>>>>others. To do this properly, we need to get one from PCI SIG group. To have
> >>>>>>>>>>this workable and consistently validated, this method shouldn't be virt
> >>>>>>>>>>specific. Then native driver should use the same method.
> >>>>>>>>>
> >>>>>>>>>You mean you will be able to talk sense into hardware guys?
> >>>>>>>>>I doubt that. If they could be convinced to make e.g. i915 base a
> >>>>>>>>
> >>>>>>>>We're negotiating this, so this is just our long term solution we figure out
> >>>>>>>>currently.
> >>>>>>>>
> >>>>>>>>>proper BAR, why didn't they?
> >>>>>>>>
> >>>>>>>>We already have no any free BAR as we mentioned previously.
> >>>>>>>
> >>>>>>>I thought you were talking about modifying hardware?
> >>>>>>
> >>>>>>Yes.
> >>>>>>
> >>>>>>Tiejun
> >>>>>
> >>>>>And they can't figure out how to stick extra info in an existing BAR?
> >>>>>Oh well, that's hardware for you.
> >>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>So when xen work on
> >>>>>>>>>>q35 PCIe machine, we can walk this way.
> >>>>>>>>>
> >>>>>>>>>If you are emulating MCH anyway, pick one that is close
> >>>>>>>>>to what i915 driver expects. It would then work with existing
> >>>>>>>>
> >>>>>>>>Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> >>>>>>>>to create a new based on i440fx just for a little change?
> >>>>>>>>
> >>>>>>>>Thanks
> >>>>>>>>Tiejun
> >>>>>>>
> >>>>>>>You can inherit it. Maybe you are lucky and this happens to
> >>>>>>>work without conflicting with whatever other guests want to do.
> >>>>>>>But if you ask me, you are really just piling up hacks.
> >>>>>>>If some guest does not work on i440, you should just work on
> >>>>>>>emulating whatever it does work on.
> >>>>>>>That would have real value.
> >>>>>>>
> >>>>>>>>>devices, without new capability IDs.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>Anthony,
> >>>>>>>>>>
> >>>>>>>>>>Any comments to address this in xen case?
> >>>>>>>>>>
> >>>>>>>>>>Thanks
> >>>>>>>>>>Tiejun
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>Xen-devel mailing list
> >>>>>Xen-devel@lists.xen.org
> >>>>>http://lists.xen.org/xen-devel
> >>>>>
> >>>>>
> >>>
> >
> >

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 05:46:58PM +0800, Chen, Tiejun wrote:
> On 2014/7/1 17:12, Michael S. Tsirkin wrote:
> >On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
> >>On 2014/6/30 19:28, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/30 17:55, Michael S. Tsirkin wrote:
> >>>>>On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >>>>>>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>>>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>Are you saying the config space in the video device?
> >>>>>>>>>>>
> >>>>>>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>>>>>MMIO BAR.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>>>>>offset or BAR in the config space.
> >>>>>>>>>>
> >>>>>>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>>>>>
> >>>>>>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>>>>>q35 as a PCIe machine of xen.
> >>>>>>>>>
> >>>>>>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>>>>>so you have the time to make it architecturally sound.
> >>>>>>>>>"Making existing guests work" would be a better motivation.
> >>>>>>>>
> >>>>>>>>Yes.
> >>>>>>>
> >>>>>>>So focus on this then. Existing guests will probably work
> >>>>>>>fine on a newer chipset - likely better than on i440fx.
> >>>>>>>xen management tools need to do some work to support this?
> >>>>>>>That will just give everyone more long term benefits.
> >>>>>>>
> >>>>>>>If instead we create a hack that does not resemble
> >>>>>>>any existing hardware even remotely, what's the
> >>>>>>>chance that it will not break with any future
> >>>>>>>guest modification?
> >>>>>>>
> >>>>>>>
> >>>>>>>>>Isn't this possible with an mch chipset?
> >>>>>>>>
> >>>>>>>>If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> >>>>>>>>MCH in xen case.
> >>>>>>>
> >>>>>>>q35 or a newer chipset that's closer to what guests expect.
> >>>>>>>
> >>>>>>>>Additionally, I think I should follow this feature after
> >>>>>>>>q35 can work for xen scenario.
> >>>>>>>
> >>>>>>>What's stopping you?
> >>>>>>
> >>>>>>I mean if you want create an new machine based on q35, actually this is
> >>>>>>equal to start making xen to migrate to q35 now. Right? I can't image how
> >>>>>>much effort should be done.
> >>>>>
> >>>>>I don't see why you don't try. Sounds like a more robust solution to me.
> >>>>
> >>>>As I think this is another requirement to us. I'm not sure if I have enough
> >>>>time to touch this currently.
> >>>>
> >>>>>
> >>>>>>So this is a reason why I'm saying I'd like to follow this feature after q35
> >>>>>>can work with xen completely.
> >>>>>
> >>>>>Then we'll end up with more configurations to support, and to what end?
> >>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>So could we do this step by step:
> >>>>>>>>>>
> >>>>>>>>>>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>>>>>>>>>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >>>>>>>>>
> >>>>>>>>>By the way there is no reason to put it at 00:1f.0 specifically I think.
> >>>>>>>>>So it seems simple: create a dummy device that gets device and
> >>>>>>>>>vendor id as properties. If you really like, add an option to get values
> >>>>>>>>
> >>>>>>>>Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> >>>>>>>>passthrough: create pseudo intel isa bridge. There, we fake this device just
> >>>>>>>>at 00:1f.0.
> >>>>>>>>But you guys don't like this, and shouldn't this be just this point we
> >>>>>>>>discussing now?
> >>>>>>>>
> >>>>>>>>If you guys agree that , everything is fine.
> >>>>>>>
> >>>>>>>Actually, this isn't what you did.
> >>>>>>>Don't tie it to xen, and don't tie it to 1f.
> >>>>>>>Just make it a simple stub pci device.
> >>>>>>>Whoever wants it, creates it.
> >>>>>>>
> >>>>>>>The thing I worry about, is the chance this will break going forward.
> >>>>>>>So you created a system with 2 isa bridges.
> >>>>>>
> >>>>>>I don't set class type to claim this is an ISA bridge, just a normal PCI
> >>>>>>device.
> >>>>>>+static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
> >>>>>>*hdev)
> >>>>>>+{
> >>>>>>+    struct PCIDevice *dev;
> >>>>>>+
> >>>>>>+    char rid;
> >>>>>>+
> >>>>>>+    /* We havt to use a simple PCI device to fake this ISA bridge
> >>>>>>+     * to avoid making some confusion to BIOS and ACPI.
> >>>>>>+     */
> >>>>>>+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
> >>>>>>"pseudo-intel-pch-isa-bridge");
> >>>>>>+
> >>>>>>+    qdev_init_nofail(&dev->qdev);
> >>>>>>+
> >>>>>>+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> >>>>>>+    pci_config_set_device_id(dev->config, hdev->device_id);
> >>>>>>+
> >>>>>>+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> >>>>>>+
> >>>>>>+    pci_config_set_revision(dev->config, rid);
> >>>>>>+
> >>>>>>+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> >>>>>>+    return 0;
> >>>>>>+}
> >>>>>
> >>>>>Then I don't see how it's supposed to work.
> >>>>>Doesn't i915 look for an isa bridge?
> >>>>>
> >>>>>         /*
> >>>>>          * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> >>>>>          * make graphics device passthrough work easy for VMM, that only
> >>>>>          * need to expose ISA bridge to let driver know the real hardware
> >>>>>          * underneath. This is a requirement from virtualization team.
> >>>>>          *
> >>>>>          * In some virtualized environments (e.g. XEN), there is irrelevant
> >>>>>          * ISA bridge in the system. To work reliably, we should scan trhough
> >>>>>          * all the ISA bridge devices and check for the first match, instead
> >>>>>          * of only checking the first one.
> >>>>>          */
> >>>>>         while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>>>>                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> >>>>>                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >>>>>                         dev_priv->pch_id = id;
> >>>>>
> >>>>>                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >>>>>                                 dev_priv->pch_type = PCH_IBX;
> >>>>>
> >>>>>etc
> >>>>>
> >>>>
> >>>>I already post this to mainline to change as follows:
> >>>>
> >>>>-	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>>>+	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> >>>>+	if (pch) {
> >>>
> >>>I see - responded on that mail - but I thought the point is to make
> >>>existing guests run? In fact you said so explicitly.
> >>>
> >>>
> >>>>Please refer to this,
> >>>>
> >>>>[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
> >>>>check class type
> >>>>
> >>>>Linux Native guys would like to accept this. And actually Windows always use
> >>>>devfn to detect this.
> >>>
> >>>In fact I see this:
> >>>
> >>>     linux 2.6.35-3.9 probes the 1st IA bridge
> >>>
> >>>         no idea how would you fix this.
> >>>         try changing default class for the main bridge?
> >>>
> >>>     linux 3.10 probes all ISA bridges
> >>>
> >>>         requires your stub to be the isa bridge?
> >>>
> >>>
> >>>I don't see why are driver guys so willing to do crazy things.  They
> >>>want to match specific device/vendor id pairs, why don't they do just
> >>>that? Why poke at class, random slot numbers etc etc?
> >>
> >>AFAIK what they did is from our previous incorrect requirement as I
> >>understand. So we need to correct this.
> >>
> >>Thanks
> >>Tiejun
> >
> >Since we can't fix existing guests, I would say
> 
> This shouldn't be a fix existing guest, and this is why I can send this
> before you guys accept GFX passthrough for qemu ML.
> 
> I think you can re-read that patch head description. 1f.0 can work under all
> scenarios including qemu-xen-traditonal.
> 
> And this is also expected by native Linux organically, and especially
> Windows always use devfn to detect PCH, this is not like current Linux. So
> here I just sync this to make sense.
> 
> Unless you'd like to make Linux specific to this point.
> 
> Tiejun

Why don't both windows and linux drivers look device up
by device and vendor id?
Same applies to MCH really.


> >get things working first, find a clean way for
> >new driver to work next.
> >
> >>>
> >>>
> >>>
> >>>>>
> >>>>>
> >>>>>>>This is already not something that exists on real hardware.
> >>>>>>>So it might break some guests that will get confused.
> >>>>>>>Maybe we are lucky and most guests see an unfamiliar device
> >>>>>>>and ignore it. It seems believable.
> >>>>>>>
> >>>>>>>But your MCH hack overrides registers in the pci host.
> >>>>>>
> >>>>>>We just try to write *one* register we already confirm this is safe enough.
> >>>>>
> >>>>>This should go in code in form of comments:
> >>>>>document what this register does on 440fx
> >>>>>and why it's safe to override.
> >>>>>We don't see what you
> >>>>>confirmed off-line.
> >>>>
> >>>>That offset is one specific to IGD usage, not for i440fx common. This is why
> >>>>we need to expose something in the host bridge. They're just introduced to
> >>>>support IGD.
> >>>>
> >>>>>
> >>>>>>Other register are read-only.
> >>>>>
> >>>>>Doesn't matter, need to document these as well.
> >>>>
> >>>>I think everything are covered in igd_pci_write()/igd_pci_write().
> >>>>
> >>>>>
> >>>>>>>Are we lucky and there's nothing in these registers
> >>>>>>>of interest to guests? This seems much more fragile.
> >>>>>>>So please poke at the spec, and compile the list
> >>>>>>>of registers you want to touch, figure out why they are
> >>>>>>>safe to override, and put this all in code comments.
> >>>>>>>
> >>>>>>>And the same thing that applies to the isa bridge
> >>>>>>
> >>>>>>We just expose its own vendor/device ids here. We don't access to change
> >>>>>>anything in the isa bridge.
> >>>>>>
> >>>>>>>applies here too. It should work without QEMU touching
> >>>>>>>hosts' hardware.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>from sysfs: device and vendor id are world readable, so just get them
> >>>>>>>>>directly and not through xen wrappers, this way you can open the files
> >>>>>>>>>RO and not RW.
> >>>>>>>>>You seem to poke at revision as well, I don't see
> >>>>>>>>>driver looking at that - strictly necessary?
> >>>>>>>>>If yes please patch host kernel to expose that info in sysfs,
> >>>>>>>>>though we can fall back on pci config if not there.
> >>>>>>>>>
> >>>>>>>>>MCH (bridge_dev) hacks in i915 are nastier.
> >>>>>>>>>To clean them up, we really have to have an explicit driver for this
> >>>>>>>>>bridge, not a pass-through device.  Long term, the right thing to do is
> >>>>>>>>>likely to extend host driver and expose the necessary information in
> >>>>>>>>>sysfs on host kernel.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>I'm a bit confused. Any sysfs should be filled by the associated PCIe
> >>>>>>>>device, shouldn't it? So qemu still need to emulate this PCIe device
> >>>>>>>>firstly, then set properties into sysfs.
> >>>>>>>
> >>>>>>>I am talking about getting host properties into qemu.
> >>>>>>>You don't want to give qemu R/W root access to host sysfs system
> >>>>>>>of the root bridge, that's not secure.
> >>>>>>
> >>>>>>igd_pci_read()
> >>>>>>	|
> >>>>>>	+ xen_host_pci_get_block()
> >>>>>>		|
> >>>>>>		+ xen_host_pci_config_read(()
> >>>>>>			|
> >>>>>>			+  pread()
> >>>>>>
> >>>>>>So shouldn't we already expose these information via sysfs?
> >>>>>
> >>>>>That's poking at sysfs of a real device, and after opening it RW.
> >>>>
> >>>>I don't think we can really write anything to those read-only sysfs
> >>>>interface even we open them as RW.
> >>>>
> >>>>Tiejun
> >>>>
> >>>>>
> >>>>>>>Avoiding read only access to filesystem is a good idea too, so it
> >>>>>>>should be possible to pass all parameters in as
> >>>>>>>device properties, and let whoever starts qemu
> >>>>>>>figure out what are reasonable values.
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>>>>>>>>>others. To do this properly, we need to get one from PCI SIG group. To have
> >>>>>>>>>>this workable and consistently validated, this method shouldn't be virt
> >>>>>>>>>>specific. Then native driver should use the same method.
> >>>>>>>>>
> >>>>>>>>>You mean you will be able to talk sense into hardware guys?
> >>>>>>>>>I doubt that. If they could be convinced to make e.g. i915 base a
> >>>>>>>>
> >>>>>>>>We're negotiating this, so this is just our long term solution we figure out
> >>>>>>>>currently.
> >>>>>>>>
> >>>>>>>>>proper BAR, why didn't they?
> >>>>>>>>
> >>>>>>>>We already have no any free BAR as we mentioned previously.
> >>>>>>>
> >>>>>>>I thought you were talking about modifying hardware?
> >>>>>>
> >>>>>>Yes.
> >>>>>>
> >>>>>>Tiejun
> >>>>>
> >>>>>And they can't figure out how to stick extra info in an existing BAR?
> >>>>>Oh well, that's hardware for you.
> >>>>>
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>So when xen work on
> >>>>>>>>>>q35 PCIe machine, we can walk this way.
> >>>>>>>>>
> >>>>>>>>>If you are emulating MCH anyway, pick one that is close
> >>>>>>>>>to what i915 driver expects. It would then work with existing
> >>>>>>>>
> >>>>>>>>Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> >>>>>>>>to create a new based on i440fx just for a little change?
> >>>>>>>>
> >>>>>>>>Thanks
> >>>>>>>>Tiejun
> >>>>>>>
> >>>>>>>You can inherit it. Maybe you are lucky and this happens to
> >>>>>>>work without conflicting with whatever other guests want to do.
> >>>>>>>But if you ask me, you are really just piling up hacks.
> >>>>>>>If some guest does not work on i440, you should just work on
> >>>>>>>emulating whatever it does work on.
> >>>>>>>That would have real value.
> >>>>>>>
> >>>>>>>>>devices, without new capability IDs.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>Anthony,
> >>>>>>>>>>
> >>>>>>>>>>Any comments to address this in xen case?
> >>>>>>>>>>
> >>>>>>>>>>Thanks
> >>>>>>>>>>Tiejun
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>Xen-devel mailing list
> >>>>>Xen-devel@lists.xen.org
> >>>>>http://lists.xen.org/xen-devel
> >>>>>
> >>>>>
> >>>
> >
> >

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/1 20:33, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 05:46:58PM +0800, Chen, Tiejun wrote:
>> On 2014/7/1 17:12, Michael S. Tsirkin wrote:
>>> On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/30 19:28, Michael S. Tsirkin wrote:
>>>>> On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/30 17:55, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>>>>> MMIO BAR.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>>>>
>>>>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>>>>
>>>>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>>>>
>>>>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>> So focus on this then. Existing guests will probably work
>>>>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>>>>> xen management tools need to do some work to support this?
>>>>>>>>> That will just give everyone more long term benefits.
>>>>>>>>>
>>>>>>>>> If instead we create a hack that does not resemble
>>>>>>>>> any existing hardware even remotely, what's the
>>>>>>>>> chance that it will not break with any future
>>>>>>>>> guest modification?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Isn't this possible with an mch chipset?
>>>>>>>>>>
>>>>>>>>>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>>>>>>>>>> MCH in xen case.
>>>>>>>>>
>>>>>>>>> q35 or a newer chipset that's closer to what guests expect.
>>>>>>>>>
>>>>>>>>>> Additionally, I think I should follow this feature after
>>>>>>>>>> q35 can work for xen scenario.
>>>>>>>>>
>>>>>>>>> What's stopping you?
>>>>>>>>
>>>>>>>> I mean if you want create an new machine based on q35, actually this is
>>>>>>>> equal to start making xen to migrate to q35 now. Right? I can't image how
>>>>>>>> much effort should be done.
>>>>>>>
>>>>>>> I don't see why you don't try. Sounds like a more robust solution to me.
>>>>>>
>>>>>> As I think this is another requirement to us. I'm not sure if I have enough
>>>>>> time to touch this currently.
>>>>>>
>>>>>>>
>>>>>>>> So this is a reason why I'm saying I'd like to follow this feature after q35
>>>>>>>> can work with xen completely.
>>>>>>>
>>>>>>> Then we'll end up with more configurations to support, and to what end?
>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> So could we do this step by step:
>>>>>>>>>>>>
>>>>>>>>>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>>>>>>>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>>>>>>>>>
>>>>>>>>>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>>>>>>>>>> So it seems simple: create a dummy device that gets device and
>>>>>>>>>>> vendor id as properties. If you really like, add an option to get values
>>>>>>>>>>
>>>>>>>>>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>>>>>>>>>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>>>>>>>>>> at 00:1f.0.
>>>>>>>>>> But you guys don't like this, and shouldn't this be just this point we
>>>>>>>>>> discussing now?
>>>>>>>>>>
>>>>>>>>>> If you guys agree that , everything is fine.
>>>>>>>>>
>>>>>>>>> Actually, this isn't what you did.
>>>>>>>>> Don't tie it to xen, and don't tie it to 1f.
>>>>>>>>> Just make it a simple stub pci device.
>>>>>>>>> Whoever wants it, creates it.
>>>>>>>>>
>>>>>>>>> The thing I worry about, is the chance this will break going forward.
>>>>>>>>> So you created a system with 2 isa bridges.
>>>>>>>>
>>>>>>>> I don't set class type to claim this is an ISA bridge, just a normal PCI
>>>>>>>> device.
>>>>>>>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>>>>>>>> *hdev)
>>>>>>>> +{
>>>>>>>> +    struct PCIDevice *dev;
>>>>>>>> +
>>>>>>>> +    char rid;
>>>>>>>> +
>>>>>>>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>>>>>>>> +     * to avoid making some confusion to BIOS and ACPI.
>>>>>>>> +     */
>>>>>>>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>>>>>>>> "pseudo-intel-pch-isa-bridge");
>>>>>>>> +
>>>>>>>> +    qdev_init_nofail(&dev->qdev);
>>>>>>>> +
>>>>>>>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>>>>>>>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>>>>>>>> +
>>>>>>>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>>>>>>>> +
>>>>>>>> +    pci_config_set_revision(dev->config, rid);
>>>>>>>> +
>>>>>>>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>>>>>>> +    return 0;
>>>>>>>> +}
>>>>>>>
>>>>>>> Then I don't see how it's supposed to work.
>>>>>>> Doesn't i915 look for an isa bridge?
>>>>>>>
>>>>>>>          /*
>>>>>>>           * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>>>>>>>           * make graphics device passthrough work easy for VMM, that only
>>>>>>>           * need to expose ISA bridge to let driver know the real hardware
>>>>>>>           * underneath. This is a requirement from virtualization team.
>>>>>>>           *
>>>>>>>           * In some virtualized environments (e.g. XEN), there is irrelevant
>>>>>>>           * ISA bridge in the system. To work reliably, we should scan trhough
>>>>>>>           * all the ISA bridge devices and check for the first match, instead
>>>>>>>           * of only checking the first one.
>>>>>>>           */
>>>>>>>          while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>>>>>                  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>>>                          unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>>>                          dev_priv->pch_id = id;
>>>>>>>
>>>>>>>                          if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>>>                                  dev_priv->pch_type = PCH_IBX;
>>>>>>>
>>>>>>> etc
>>>>>>>
>>>>>>
>>>>>> I already post this to mainline to change as follows:
>>>>>>
>>>>>> -	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>>>> +	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>>>>>> +	if (pch) {
>>>>>
>>>>> I see - responded on that mail - but I thought the point is to make
>>>>> existing guests run? In fact you said so explicitly.
>>>>>
>>>>>
>>>>>> Please refer to this,
>>>>>>
>>>>>> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
>>>>>> check class type
>>>>>>
>>>>>> Linux Native guys would like to accept this. And actually Windows always use
>>>>>> devfn to detect this.
>>>>>
>>>>> In fact I see this:
>>>>>
>>>>>      linux 2.6.35-3.9 probes the 1st IA bridge
>>>>>
>>>>>          no idea how would you fix this.
>>>>>          try changing default class for the main bridge?
>>>>>
>>>>>      linux 3.10 probes all ISA bridges
>>>>>
>>>>>          requires your stub to be the isa bridge?
>>>>>
>>>>>
>>>>> I don't see why are driver guys so willing to do crazy things.  They
>>>>> want to match specific device/vendor id pairs, why don't they do just
>>>>> that? Why poke at class, random slot numbers etc etc?
>>>>
>>>> AFAIK what they did is from our previous incorrect requirement as I
>>>> understand. So we need to correct this.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> Since we can't fix existing guests, I would say
>>
>> This shouldn't be a fix existing guest, and this is why I can send this
>> before you guys accept GFX passthrough for qemu ML.
>>
>> I think you can re-read that patch head description. 1f.0 can work under all
>> scenarios including qemu-xen-traditonal.
>>
>> And this is also expected by native Linux organically, and especially
>> Windows always use devfn to detect PCH, this is not like current Linux. So
>> here I just sync this to make sense.
>>
>> Unless you'd like to make Linux specific to this point.
>>
>> Tiejun
>
> Why don't both windows and linux drivers look device up
> by device and vendor id?

Its easy to understand because the same video device can work under 
different PCH, but we need to do different initialization based on 
different PCH.

Thanks
Tiejun

> Same applies to MCH really.
>
>
>>> get things working first, find a clean way for
>>> new driver to work next.
>>>
>>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> This is already not something that exists on real hardware.
>>>>>>>>> So it might break some guests that will get confused.
>>>>>>>>> Maybe we are lucky and most guests see an unfamiliar device
>>>>>>>>> and ignore it. It seems believable.
>>>>>>>>>
>>>>>>>>> But your MCH hack overrides registers in the pci host.
>>>>>>>>
>>>>>>>> We just try to write *one* register we already confirm this is safe enough.
>>>>>>>
>>>>>>> This should go in code in form of comments:
>>>>>>> document what this register does on 440fx
>>>>>>> and why it's safe to override.
>>>>>>> We don't see what you
>>>>>>> confirmed off-line.
>>>>>>
>>>>>> That offset is one specific to IGD usage, not for i440fx common. This is why
>>>>>> we need to expose something in the host bridge. They're just introduced to
>>>>>> support IGD.
>>>>>>
>>>>>>>
>>>>>>>> Other register are read-only.
>>>>>>>
>>>>>>> Doesn't matter, need to document these as well.
>>>>>>
>>>>>> I think everything are covered in igd_pci_write()/igd_pci_write().
>>>>>>
>>>>>>>
>>>>>>>>> Are we lucky and there's nothing in these registers
>>>>>>>>> of interest to guests? This seems much more fragile.
>>>>>>>>> So please poke at the spec, and compile the list
>>>>>>>>> of registers you want to touch, figure out why they are
>>>>>>>>> safe to override, and put this all in code comments.
>>>>>>>>>
>>>>>>>>> And the same thing that applies to the isa bridge
>>>>>>>>
>>>>>>>> We just expose its own vendor/device ids here. We don't access to change
>>>>>>>> anything in the isa bridge.
>>>>>>>>
>>>>>>>>> applies here too. It should work without QEMU touching
>>>>>>>>> hosts' hardware.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> >from sysfs: device and vendor id are world readable, so just get them
>>>>>>>>>>> directly and not through xen wrappers, this way you can open the files
>>>>>>>>>>> RO and not RW.
>>>>>>>>>>> You seem to poke at revision as well, I don't see
>>>>>>>>>>> driver looking at that - strictly necessary?
>>>>>>>>>>> If yes please patch host kernel to expose that info in sysfs,
>>>>>>>>>>> though we can fall back on pci config if not there.
>>>>>>>>>>>
>>>>>>>>>>> MCH (bridge_dev) hacks in i915 are nastier.
>>>>>>>>>>> To clean them up, we really have to have an explicit driver for this
>>>>>>>>>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>>>>>>>>>> likely to extend host driver and expose the necessary information in
>>>>>>>>>>> sysfs on host kernel.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>>>>>>>>>> device, shouldn't it? So qemu still need to emulate this PCIe device
>>>>>>>>>> firstly, then set properties into sysfs.
>>>>>>>>>
>>>>>>>>> I am talking about getting host properties into qemu.
>>>>>>>>> You don't want to give qemu R/W root access to host sysfs system
>>>>>>>>> of the root bridge, that's not secure.
>>>>>>>>
>>>>>>>> igd_pci_read()
>>>>>>>> 	|
>>>>>>>> 	+ xen_host_pci_get_block()
>>>>>>>> 		|
>>>>>>>> 		+ xen_host_pci_config_read(()
>>>>>>>> 			|
>>>>>>>> 			+  pread()
>>>>>>>>
>>>>>>>> So shouldn't we already expose these information via sysfs?
>>>>>>>
>>>>>>> That's poking at sysfs of a real device, and after opening it RW.
>>>>>>
>>>>>> I don't think we can really write anything to those read-only sysfs
>>>>>> interface even we open them as RW.
>>>>>>
>>>>>> Tiejun
>>>>>>
>>>>>>>
>>>>>>>>> Avoiding read only access to filesystem is a good idea too, so it
>>>>>>>>> should be possible to pass all parameters in as
>>>>>>>>> device properties, and let whoever starts qemu
>>>>>>>>> figure out what are reasonable values.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>>>>>>>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>>>>>>>>>> this workable and consistently validated, this method shouldn't be virt
>>>>>>>>>>>> specific. Then native driver should use the same method.
>>>>>>>>>>>
>>>>>>>>>>> You mean you will be able to talk sense into hardware guys?
>>>>>>>>>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>>>>>>>>>
>>>>>>>>>> We're negotiating this, so this is just our long term solution we figure out
>>>>>>>>>> currently.
>>>>>>>>>>
>>>>>>>>>>> proper BAR, why didn't they?
>>>>>>>>>>
>>>>>>>>>> We already have no any free BAR as we mentioned previously.
>>>>>>>>>
>>>>>>>>> I thought you were talking about modifying hardware?
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>> Tiejun
>>>>>>>
>>>>>>> And they can't figure out how to stick extra info in an existing BAR?
>>>>>>> Oh well, that's hardware for you.
>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> So when xen work on
>>>>>>>>>>>> q35 PCIe machine, we can walk this way.
>>>>>>>>>>>
>>>>>>>>>>> If you are emulating MCH anyway, pick one that is close
>>>>>>>>>>> to what i915 driver expects. It would then work with existing
>>>>>>>>>>
>>>>>>>>>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>>>>>>>>>> to create a new based on i440fx just for a little change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Tiejun
>>>>>>>>>
>>>>>>>>> You can inherit it. Maybe you are lucky and this happens to
>>>>>>>>> work without conflicting with whatever other guests want to do.
>>>>>>>>> But if you ask me, you are really just piling up hacks.
>>>>>>>>> If some guest does not work on i440, you should just work on
>>>>>>>>> emulating whatever it does work on.
>>>>>>>>> That would have real value.
>>>>>>>>>
>>>>>>>>>>> devices, without new capability IDs.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Anthony,
>>>>>>>>>>>>
>>>>>>>>>>>> Any comments to address this in xen case?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Tiejun
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@lists.xen.org
>>>>>>> http://lists.xen.org/xen-devel
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/1 20:33, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 05:46:58PM +0800, Chen, Tiejun wrote:
>> On 2014/7/1 17:12, Michael S. Tsirkin wrote:
>>> On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/30 19:28, Michael S. Tsirkin wrote:
>>>>> On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/30 17:55, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>>>>> MMIO BAR.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>>>>
>>>>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>>>>
>>>>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>>>>
>>>>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>> So focus on this then. Existing guests will probably work
>>>>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>>>>> xen management tools need to do some work to support this?
>>>>>>>>> That will just give everyone more long term benefits.
>>>>>>>>>
>>>>>>>>> If instead we create a hack that does not resemble
>>>>>>>>> any existing hardware even remotely, what's the
>>>>>>>>> chance that it will not break with any future
>>>>>>>>> guest modification?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Isn't this possible with an mch chipset?
>>>>>>>>>>
>>>>>>>>>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>>>>>>>>>> MCH in xen case.
>>>>>>>>>
>>>>>>>>> q35 or a newer chipset that's closer to what guests expect.
>>>>>>>>>
>>>>>>>>>> Additionally, I think I should follow this feature after
>>>>>>>>>> q35 can work for xen scenario.
>>>>>>>>>
>>>>>>>>> What's stopping you?
>>>>>>>>
>>>>>>>> I mean if you want create an new machine based on q35, actually this is
>>>>>>>> equal to start making xen to migrate to q35 now. Right? I can't image how
>>>>>>>> much effort should be done.
>>>>>>>
>>>>>>> I don't see why you don't try. Sounds like a more robust solution to me.
>>>>>>
>>>>>> As I think this is another requirement to us. I'm not sure if I have enough
>>>>>> time to touch this currently.
>>>>>>
>>>>>>>
>>>>>>>> So this is a reason why I'm saying I'd like to follow this feature after q35
>>>>>>>> can work with xen completely.
>>>>>>>
>>>>>>> Then we'll end up with more configurations to support, and to what end?
>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> So could we do this step by step:
>>>>>>>>>>>>
>>>>>>>>>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>>>>>>>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>>>>>>>>>
>>>>>>>>>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>>>>>>>>>> So it seems simple: create a dummy device that gets device and
>>>>>>>>>>> vendor id as properties. If you really like, add an option to get values
>>>>>>>>>>
>>>>>>>>>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>>>>>>>>>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>>>>>>>>>> at 00:1f.0.
>>>>>>>>>> But you guys don't like this, and shouldn't this be just this point we
>>>>>>>>>> discussing now?
>>>>>>>>>>
>>>>>>>>>> If you guys agree that , everything is fine.
>>>>>>>>>
>>>>>>>>> Actually, this isn't what you did.
>>>>>>>>> Don't tie it to xen, and don't tie it to 1f.
>>>>>>>>> Just make it a simple stub pci device.
>>>>>>>>> Whoever wants it, creates it.
>>>>>>>>>
>>>>>>>>> The thing I worry about, is the chance this will break going forward.
>>>>>>>>> So you created a system with 2 isa bridges.
>>>>>>>>
>>>>>>>> I don't set class type to claim this is an ISA bridge, just a normal PCI
>>>>>>>> device.
>>>>>>>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>>>>>>>> *hdev)
>>>>>>>> +{
>>>>>>>> +    struct PCIDevice *dev;
>>>>>>>> +
>>>>>>>> +    char rid;
>>>>>>>> +
>>>>>>>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>>>>>>>> +     * to avoid making some confusion to BIOS and ACPI.
>>>>>>>> +     */
>>>>>>>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>>>>>>>> "pseudo-intel-pch-isa-bridge");
>>>>>>>> +
>>>>>>>> +    qdev_init_nofail(&dev->qdev);
>>>>>>>> +
>>>>>>>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>>>>>>>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>>>>>>>> +
>>>>>>>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>>>>>>>> +
>>>>>>>> +    pci_config_set_revision(dev->config, rid);
>>>>>>>> +
>>>>>>>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>>>>>>> +    return 0;
>>>>>>>> +}
>>>>>>>
>>>>>>> Then I don't see how it's supposed to work.
>>>>>>> Doesn't i915 look for an isa bridge?
>>>>>>>
>>>>>>>          /*
>>>>>>>           * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>>>>>>>           * make graphics device passthrough work easy for VMM, that only
>>>>>>>           * need to expose ISA bridge to let driver know the real hardware
>>>>>>>           * underneath. This is a requirement from virtualization team.
>>>>>>>           *
>>>>>>>           * In some virtualized environments (e.g. XEN), there is irrelevant
>>>>>>>           * ISA bridge in the system. To work reliably, we should scan trhough
>>>>>>>           * all the ISA bridge devices and check for the first match, instead
>>>>>>>           * of only checking the first one.
>>>>>>>           */
>>>>>>>          while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>>>>>                  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>>>                          unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>>>                          dev_priv->pch_id = id;
>>>>>>>
>>>>>>>                          if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>>>                                  dev_priv->pch_type = PCH_IBX;
>>>>>>>
>>>>>>> etc
>>>>>>>
>>>>>>
>>>>>> I already post this to mainline to change as follows:
>>>>>>
>>>>>> -	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>>>> +	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>>>>>> +	if (pch) {
>>>>>
>>>>> I see - responded on that mail - but I thought the point is to make
>>>>> existing guests run? In fact you said so explicitly.
>>>>>
>>>>>
>>>>>> Please refer to this,
>>>>>>
>>>>>> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
>>>>>> check class type
>>>>>>
>>>>>> Linux Native guys would like to accept this. And actually Windows always use
>>>>>> devfn to detect this.
>>>>>
>>>>> In fact I see this:
>>>>>
>>>>>      linux 2.6.35-3.9 probes the 1st IA bridge
>>>>>
>>>>>          no idea how would you fix this.
>>>>>          try changing default class for the main bridge?
>>>>>
>>>>>      linux 3.10 probes all ISA bridges
>>>>>
>>>>>          requires your stub to be the isa bridge?
>>>>>
>>>>>
>>>>> I don't see why are driver guys so willing to do crazy things.  They
>>>>> want to match specific device/vendor id pairs, why don't they do just
>>>>> that? Why poke at class, random slot numbers etc etc?
>>>>
>>>> AFAIK what they did is from our previous incorrect requirement as I
>>>> understand. So we need to correct this.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> Since we can't fix existing guests, I would say
>>
>> This shouldn't be a fix existing guest, and this is why I can send this
>> before you guys accept GFX passthrough for qemu ML.
>>
>> I think you can re-read that patch head description. 1f.0 can work under all
>> scenarios including qemu-xen-traditonal.
>>
>> And this is also expected by native Linux organically, and especially
>> Windows always use devfn to detect PCH, this is not like current Linux. So
>> here I just sync this to make sense.
>>
>> Unless you'd like to make Linux specific to this point.
>>
>> Tiejun
>
> Why don't both windows and linux drivers look device up
> by device and vendor id?

Its easy to understand because the same video device can work under 
different PCH, but we need to do different initialization based on 
different PCH.

Thanks
Tiejun

> Same applies to MCH really.
>
>
>>> get things working first, find a clean way for
>>> new driver to work next.
>>>
>>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> This is already not something that exists on real hardware.
>>>>>>>>> So it might break some guests that will get confused.
>>>>>>>>> Maybe we are lucky and most guests see an unfamiliar device
>>>>>>>>> and ignore it. It seems believable.
>>>>>>>>>
>>>>>>>>> But your MCH hack overrides registers in the pci host.
>>>>>>>>
>>>>>>>> We just try to write *one* register we already confirm this is safe enough.
>>>>>>>
>>>>>>> This should go in code in form of comments:
>>>>>>> document what this register does on 440fx
>>>>>>> and why it's safe to override.
>>>>>>> We don't see what you
>>>>>>> confirmed off-line.
>>>>>>
>>>>>> That offset is one specific to IGD usage, not for i440fx common. This is why
>>>>>> we need to expose something in the host bridge. They're just introduced to
>>>>>> support IGD.
>>>>>>
>>>>>>>
>>>>>>>> Other register are read-only.
>>>>>>>
>>>>>>> Doesn't matter, need to document these as well.
>>>>>>
>>>>>> I think everything are covered in igd_pci_write()/igd_pci_write().
>>>>>>
>>>>>>>
>>>>>>>>> Are we lucky and there's nothing in these registers
>>>>>>>>> of interest to guests? This seems much more fragile.
>>>>>>>>> So please poke at the spec, and compile the list
>>>>>>>>> of registers you want to touch, figure out why they are
>>>>>>>>> safe to override, and put this all in code comments.
>>>>>>>>>
>>>>>>>>> And the same thing that applies to the isa bridge
>>>>>>>>
>>>>>>>> We just expose its own vendor/device ids here. We don't access to change
>>>>>>>> anything in the isa bridge.
>>>>>>>>
>>>>>>>>> applies here too. It should work without QEMU touching
>>>>>>>>> hosts' hardware.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> >from sysfs: device and vendor id are world readable, so just get them
>>>>>>>>>>> directly and not through xen wrappers, this way you can open the files
>>>>>>>>>>> RO and not RW.
>>>>>>>>>>> You seem to poke at revision as well, I don't see
>>>>>>>>>>> driver looking at that - strictly necessary?
>>>>>>>>>>> If yes please patch host kernel to expose that info in sysfs,
>>>>>>>>>>> though we can fall back on pci config if not there.
>>>>>>>>>>>
>>>>>>>>>>> MCH (bridge_dev) hacks in i915 are nastier.
>>>>>>>>>>> To clean them up, we really have to have an explicit driver for this
>>>>>>>>>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>>>>>>>>>> likely to extend host driver and expose the necessary information in
>>>>>>>>>>> sysfs on host kernel.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>>>>>>>>>> device, shouldn't it? So qemu still need to emulate this PCIe device
>>>>>>>>>> firstly, then set properties into sysfs.
>>>>>>>>>
>>>>>>>>> I am talking about getting host properties into qemu.
>>>>>>>>> You don't want to give qemu R/W root access to host sysfs system
>>>>>>>>> of the root bridge, that's not secure.
>>>>>>>>
>>>>>>>> igd_pci_read()
>>>>>>>> 	|
>>>>>>>> 	+ xen_host_pci_get_block()
>>>>>>>> 		|
>>>>>>>> 		+ xen_host_pci_config_read(()
>>>>>>>> 			|
>>>>>>>> 			+  pread()
>>>>>>>>
>>>>>>>> So shouldn't we already expose these information via sysfs?
>>>>>>>
>>>>>>> That's poking at sysfs of a real device, and after opening it RW.
>>>>>>
>>>>>> I don't think we can really write anything to those read-only sysfs
>>>>>> interface even we open them as RW.
>>>>>>
>>>>>> Tiejun
>>>>>>
>>>>>>>
>>>>>>>>> Avoiding read only access to filesystem is a good idea too, so it
>>>>>>>>> should be possible to pass all parameters in as
>>>>>>>>> device properties, and let whoever starts qemu
>>>>>>>>> figure out what are reasonable values.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>>>>>>>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>>>>>>>>>> this workable and consistently validated, this method shouldn't be virt
>>>>>>>>>>>> specific. Then native driver should use the same method.
>>>>>>>>>>>
>>>>>>>>>>> You mean you will be able to talk sense into hardware guys?
>>>>>>>>>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>>>>>>>>>
>>>>>>>>>> We're negotiating this, so this is just our long term solution we figure out
>>>>>>>>>> currently.
>>>>>>>>>>
>>>>>>>>>>> proper BAR, why didn't they?
>>>>>>>>>>
>>>>>>>>>> We already have no any free BAR as we mentioned previously.
>>>>>>>>>
>>>>>>>>> I thought you were talking about modifying hardware?
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>> Tiejun
>>>>>>>
>>>>>>> And they can't figure out how to stick extra info in an existing BAR?
>>>>>>> Oh well, that's hardware for you.
>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> So when xen work on
>>>>>>>>>>>> q35 PCIe machine, we can walk this way.
>>>>>>>>>>>
>>>>>>>>>>> If you are emulating MCH anyway, pick one that is close
>>>>>>>>>>> to what i915 driver expects. It would then work with existing
>>>>>>>>>>
>>>>>>>>>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>>>>>>>>>> to create a new based on i440fx just for a little change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Tiejun
>>>>>>>>>
>>>>>>>>> You can inherit it. Maybe you are lucky and this happens to
>>>>>>>>> work without conflicting with whatever other guests want to do.
>>>>>>>>> But if you ask me, you are really just piling up hacks.
>>>>>>>>> If some guest does not work on i440, you should just work on
>>>>>>>>> emulating whatever it does work on.
>>>>>>>>> That would have real value.
>>>>>>>>>
>>>>>>>>>>> devices, without new capability IDs.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Anthony,
>>>>>>>>>>>>
>>>>>>>>>>>> Any comments to address this in xen case?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Tiejun
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@lists.xen.org
>>>>>>> http://lists.xen.org/xen-devel
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 08:59:38AM +0800, Chen, Tiejun wrote:
> On 2014/7/1 20:33, Michael S. Tsirkin wrote:
> >On Tue, Jul 01, 2014 at 05:46:58PM +0800, Chen, Tiejun wrote:
> >>On 2014/7/1 17:12, Michael S. Tsirkin wrote:
> >>>On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/30 19:28, Michael S. Tsirkin wrote:
> >>>>>On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/6/30 17:55, Michael S. Tsirkin wrote:
> >>>>>>>On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> >>>>>>>>On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >>>>>>>>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>>>>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Are you saying the config space in the video device?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>>>>>>>MMIO BAR.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>>>>>>>offset or BAR in the config space.
> >>>>>>>>>>>>
> >>>>>>>>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>>>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>>>>>>>
> >>>>>>>>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>>>>>>>q35 as a PCIe machine of xen.
> >>>>>>>>>>>
> >>>>>>>>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>>>>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>>>>>>>so you have the time to make it architecturally sound.
> >>>>>>>>>>>"Making existing guests work" would be a better motivation.
> >>>>>>>>>>
> >>>>>>>>>>Yes.
> >>>>>>>>>
> >>>>>>>>>So focus on this then. Existing guests will probably work
> >>>>>>>>>fine on a newer chipset - likely better than on i440fx.
> >>>>>>>>>xen management tools need to do some work to support this?
> >>>>>>>>>That will just give everyone more long term benefits.
> >>>>>>>>>
> >>>>>>>>>If instead we create a hack that does not resemble
> >>>>>>>>>any existing hardware even remotely, what's the
> >>>>>>>>>chance that it will not break with any future
> >>>>>>>>>guest modification?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>Isn't this possible with an mch chipset?
> >>>>>>>>>>
> >>>>>>>>>>If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> >>>>>>>>>>MCH in xen case.
> >>>>>>>>>
> >>>>>>>>>q35 or a newer chipset that's closer to what guests expect.
> >>>>>>>>>
> >>>>>>>>>>Additionally, I think I should follow this feature after
> >>>>>>>>>>q35 can work for xen scenario.
> >>>>>>>>>
> >>>>>>>>>What's stopping you?
> >>>>>>>>
> >>>>>>>>I mean if you want create an new machine based on q35, actually this is
> >>>>>>>>equal to start making xen to migrate to q35 now. Right? I can't image how
> >>>>>>>>much effort should be done.
> >>>>>>>
> >>>>>>>I don't see why you don't try. Sounds like a more robust solution to me.
> >>>>>>
> >>>>>>As I think this is another requirement to us. I'm not sure if I have enough
> >>>>>>time to touch this currently.
> >>>>>>
> >>>>>>>
> >>>>>>>>So this is a reason why I'm saying I'd like to follow this feature after q35
> >>>>>>>>can work with xen completely.
> >>>>>>>
> >>>>>>>Then we'll end up with more configurations to support, and to what end?
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>So could we do this step by step:
> >>>>>>>>>>>>
> >>>>>>>>>>>>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>>>>>>>>>>>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >>>>>>>>>>>
> >>>>>>>>>>>By the way there is no reason to put it at 00:1f.0 specifically I think.
> >>>>>>>>>>>So it seems simple: create a dummy device that gets device and
> >>>>>>>>>>>vendor id as properties. If you really like, add an option to get values
> >>>>>>>>>>
> >>>>>>>>>>Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> >>>>>>>>>>passthrough: create pseudo intel isa bridge. There, we fake this device just
> >>>>>>>>>>at 00:1f.0.
> >>>>>>>>>>But you guys don't like this, and shouldn't this be just this point we
> >>>>>>>>>>discussing now?
> >>>>>>>>>>
> >>>>>>>>>>If you guys agree that , everything is fine.
> >>>>>>>>>
> >>>>>>>>>Actually, this isn't what you did.
> >>>>>>>>>Don't tie it to xen, and don't tie it to 1f.
> >>>>>>>>>Just make it a simple stub pci device.
> >>>>>>>>>Whoever wants it, creates it.
> >>>>>>>>>
> >>>>>>>>>The thing I worry about, is the chance this will break going forward.
> >>>>>>>>>So you created a system with 2 isa bridges.
> >>>>>>>>
> >>>>>>>>I don't set class type to claim this is an ISA bridge, just a normal PCI
> >>>>>>>>device.
> >>>>>>>>+static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
> >>>>>>>>*hdev)
> >>>>>>>>+{
> >>>>>>>>+    struct PCIDevice *dev;
> >>>>>>>>+
> >>>>>>>>+    char rid;
> >>>>>>>>+
> >>>>>>>>+    /* We havt to use a simple PCI device to fake this ISA bridge
> >>>>>>>>+     * to avoid making some confusion to BIOS and ACPI.
> >>>>>>>>+     */
> >>>>>>>>+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
> >>>>>>>>"pseudo-intel-pch-isa-bridge");
> >>>>>>>>+
> >>>>>>>>+    qdev_init_nofail(&dev->qdev);
> >>>>>>>>+
> >>>>>>>>+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> >>>>>>>>+    pci_config_set_device_id(dev->config, hdev->device_id);
> >>>>>>>>+
> >>>>>>>>+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> >>>>>>>>+
> >>>>>>>>+    pci_config_set_revision(dev->config, rid);
> >>>>>>>>+
> >>>>>>>>+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> >>>>>>>>+    return 0;
> >>>>>>>>+}
> >>>>>>>
> >>>>>>>Then I don't see how it's supposed to work.
> >>>>>>>Doesn't i915 look for an isa bridge?
> >>>>>>>
> >>>>>>>         /*
> >>>>>>>          * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> >>>>>>>          * make graphics device passthrough work easy for VMM, that only
> >>>>>>>          * need to expose ISA bridge to let driver know the real hardware
> >>>>>>>          * underneath. This is a requirement from virtualization team.
> >>>>>>>          *
> >>>>>>>          * In some virtualized environments (e.g. XEN), there is irrelevant
> >>>>>>>          * ISA bridge in the system. To work reliably, we should scan trhough
> >>>>>>>          * all the ISA bridge devices and check for the first match, instead
> >>>>>>>          * of only checking the first one.
> >>>>>>>          */
> >>>>>>>         while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>>>>>>                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> >>>>>>>                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >>>>>>>                         dev_priv->pch_id = id;
> >>>>>>>
> >>>>>>>                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >>>>>>>                                 dev_priv->pch_type = PCH_IBX;
> >>>>>>>
> >>>>>>>etc
> >>>>>>>
> >>>>>>
> >>>>>>I already post this to mainline to change as follows:
> >>>>>>
> >>>>>>-	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>>>>>+	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> >>>>>>+	if (pch) {
> >>>>>
> >>>>>I see - responded on that mail - but I thought the point is to make
> >>>>>existing guests run? In fact you said so explicitly.
> >>>>>
> >>>>>
> >>>>>>Please refer to this,
> >>>>>>
> >>>>>>[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
> >>>>>>check class type
> >>>>>>
> >>>>>>Linux Native guys would like to accept this. And actually Windows always use
> >>>>>>devfn to detect this.
> >>>>>
> >>>>>In fact I see this:
> >>>>>
> >>>>>     linux 2.6.35-3.9 probes the 1st IA bridge
> >>>>>
> >>>>>         no idea how would you fix this.
> >>>>>         try changing default class for the main bridge?
> >>>>>
> >>>>>     linux 3.10 probes all ISA bridges
> >>>>>
> >>>>>         requires your stub to be the isa bridge?
> >>>>>
> >>>>>
> >>>>>I don't see why are driver guys so willing to do crazy things.  They
> >>>>>want to match specific device/vendor id pairs, why don't they do just
> >>>>>that? Why poke at class, random slot numbers etc etc?
> >>>>
> >>>>AFAIK what they did is from our previous incorrect requirement as I
> >>>>understand. So we need to correct this.
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>Since we can't fix existing guests, I would say
> >>
> >>This shouldn't be a fix existing guest, and this is why I can send this
> >>before you guys accept GFX passthrough for qemu ML.
> >>
> >>I think you can re-read that patch head description. 1f.0 can work under all
> >>scenarios including qemu-xen-traditonal.
> >>
> >>And this is also expected by native Linux organically, and especially
> >>Windows always use devfn to detect PCH, this is not like current Linux. So
> >>here I just sync this to make sense.
> >>
> >>Unless you'd like to make Linux specific to this point.
> >>
> >>Tiejun
> >
> >Why don't both windows and linux drivers look device up
> >by device and vendor id?
> 
> Its easy to understand because the same video device can work under
> different PCH, but we need to do different initialization based on different
> PCH.
> 
> Thanks
> Tiejun

Right so why don't they look up the PCH by device and vendor id?
For example, on linux use pci_get_device to iterate over all intel
devices.
I'm sure windows has a similar API as well.

This isn't a suggestion to make the change in guests right now!
Just a question.


> >Same applies to MCH really.
> >
> >
> >>>get things working first, find a clean way for
> >>>new driver to work next.
> >>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>This is already not something that exists on real hardware.
> >>>>>>>>>So it might break some guests that will get confused.
> >>>>>>>>>Maybe we are lucky and most guests see an unfamiliar device
> >>>>>>>>>and ignore it. It seems believable.
> >>>>>>>>>
> >>>>>>>>>But your MCH hack overrides registers in the pci host.
> >>>>>>>>
> >>>>>>>>We just try to write *one* register we already confirm this is safe enough.
> >>>>>>>
> >>>>>>>This should go in code in form of comments:
> >>>>>>>document what this register does on 440fx
> >>>>>>>and why it's safe to override.
> >>>>>>>We don't see what you
> >>>>>>>confirmed off-line.
> >>>>>>
> >>>>>>That offset is one specific to IGD usage, not for i440fx common. This is why
> >>>>>>we need to expose something in the host bridge. They're just introduced to
> >>>>>>support IGD.
> >>>>>>
> >>>>>>>
> >>>>>>>>Other register are read-only.
> >>>>>>>
> >>>>>>>Doesn't matter, need to document these as well.
> >>>>>>
> >>>>>>I think everything are covered in igd_pci_write()/igd_pci_write().
> >>>>>>
> >>>>>>>
> >>>>>>>>>Are we lucky and there's nothing in these registers
> >>>>>>>>>of interest to guests? This seems much more fragile.
> >>>>>>>>>So please poke at the spec, and compile the list
> >>>>>>>>>of registers you want to touch, figure out why they are
> >>>>>>>>>safe to override, and put this all in code comments.
> >>>>>>>>>
> >>>>>>>>>And the same thing that applies to the isa bridge
> >>>>>>>>
> >>>>>>>>We just expose its own vendor/device ids here. We don't access to change
> >>>>>>>>anything in the isa bridge.
> >>>>>>>>
> >>>>>>>>>applies here too. It should work without QEMU touching
> >>>>>>>>>hosts' hardware.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>from sysfs: device and vendor id are world readable, so just get them
> >>>>>>>>>>>directly and not through xen wrappers, this way you can open the files
> >>>>>>>>>>>RO and not RW.
> >>>>>>>>>>>You seem to poke at revision as well, I don't see
> >>>>>>>>>>>driver looking at that - strictly necessary?
> >>>>>>>>>>>If yes please patch host kernel to expose that info in sysfs,
> >>>>>>>>>>>though we can fall back on pci config if not there.
> >>>>>>>>>>>
> >>>>>>>>>>>MCH (bridge_dev) hacks in i915 are nastier.
> >>>>>>>>>>>To clean them up, we really have to have an explicit driver for this
> >>>>>>>>>>>bridge, not a pass-through device.  Long term, the right thing to do is
> >>>>>>>>>>>likely to extend host driver and expose the necessary information in
> >>>>>>>>>>>sysfs on host kernel.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>I'm a bit confused. Any sysfs should be filled by the associated PCIe
> >>>>>>>>>>device, shouldn't it? So qemu still need to emulate this PCIe device
> >>>>>>>>>>firstly, then set properties into sysfs.
> >>>>>>>>>
> >>>>>>>>>I am talking about getting host properties into qemu.
> >>>>>>>>>You don't want to give qemu R/W root access to host sysfs system
> >>>>>>>>>of the root bridge, that's not secure.
> >>>>>>>>
> >>>>>>>>igd_pci_read()
> >>>>>>>>	|
> >>>>>>>>	+ xen_host_pci_get_block()
> >>>>>>>>		|
> >>>>>>>>		+ xen_host_pci_config_read(()
> >>>>>>>>			|
> >>>>>>>>			+  pread()
> >>>>>>>>
> >>>>>>>>So shouldn't we already expose these information via sysfs?
> >>>>>>>
> >>>>>>>That's poking at sysfs of a real device, and after opening it RW.
> >>>>>>
> >>>>>>I don't think we can really write anything to those read-only sysfs
> >>>>>>interface even we open them as RW.
> >>>>>>
> >>>>>>Tiejun
> >>>>>>
> >>>>>>>
> >>>>>>>>>Avoiding read only access to filesystem is a good idea too, so it
> >>>>>>>>>should be possible to pass all parameters in as
> >>>>>>>>>device properties, and let whoever starts qemu
> >>>>>>>>>figure out what are reasonable values.
> >>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>>>>>>>>>>>others. To do this properly, we need to get one from PCI SIG group. To have
> >>>>>>>>>>>>this workable and consistently validated, this method shouldn't be virt
> >>>>>>>>>>>>specific. Then native driver should use the same method.
> >>>>>>>>>>>
> >>>>>>>>>>>You mean you will be able to talk sense into hardware guys?
> >>>>>>>>>>>I doubt that. If they could be convinced to make e.g. i915 base a
> >>>>>>>>>>
> >>>>>>>>>>We're negotiating this, so this is just our long term solution we figure out
> >>>>>>>>>>currently.
> >>>>>>>>>>
> >>>>>>>>>>>proper BAR, why didn't they?
> >>>>>>>>>>
> >>>>>>>>>>We already have no any free BAR as we mentioned previously.
> >>>>>>>>>
> >>>>>>>>>I thought you were talking about modifying hardware?
> >>>>>>>>
> >>>>>>>>Yes.
> >>>>>>>>
> >>>>>>>>Tiejun
> >>>>>>>
> >>>>>>>And they can't figure out how to stick extra info in an existing BAR?
> >>>>>>>Oh well, that's hardware for you.
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>So when xen work on
> >>>>>>>>>>>>q35 PCIe machine, we can walk this way.
> >>>>>>>>>>>
> >>>>>>>>>>>If you are emulating MCH anyway, pick one that is close
> >>>>>>>>>>>to what i915 driver expects. It would then work with existing
> >>>>>>>>>>
> >>>>>>>>>>Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> >>>>>>>>>>to create a new based on i440fx just for a little change?
> >>>>>>>>>>
> >>>>>>>>>>Thanks
> >>>>>>>>>>Tiejun
> >>>>>>>>>
> >>>>>>>>>You can inherit it. Maybe you are lucky and this happens to
> >>>>>>>>>work without conflicting with whatever other guests want to do.
> >>>>>>>>>But if you ask me, you are really just piling up hacks.
> >>>>>>>>>If some guest does not work on i440, you should just work on
> >>>>>>>>>emulating whatever it does work on.
> >>>>>>>>>That would have real value.
> >>>>>>>>>
> >>>>>>>>>>>devices, without new capability IDs.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>Anthony,
> >>>>>>>>>>>>
> >>>>>>>>>>>>Any comments to address this in xen case?
> >>>>>>>>>>>>
> >>>>>>>>>>>>Thanks
> >>>>>>>>>>>>Tiejun
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>_______________________________________________
> >>>>>>>Xen-devel mailing list
> >>>>>>>Xen-devel@lists.xen.org
> >>>>>>>http://lists.xen.org/xen-devel
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>>
> >

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 08:59:38AM +0800, Chen, Tiejun wrote:
> On 2014/7/1 20:33, Michael S. Tsirkin wrote:
> >On Tue, Jul 01, 2014 at 05:46:58PM +0800, Chen, Tiejun wrote:
> >>On 2014/7/1 17:12, Michael S. Tsirkin wrote:
> >>>On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/30 19:28, Michael S. Tsirkin wrote:
> >>>>>On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
> >>>>>>On 2014/6/30 17:55, Michael S. Tsirkin wrote:
> >>>>>>>On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> >>>>>>>>On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >>>>>>>>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>>>>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Are you saying the config space in the video device?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>>>>>>>MMIO BAR.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>>>>>>>offset or BAR in the config space.
> >>>>>>>>>>>>
> >>>>>>>>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>>>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>>>>>>>
> >>>>>>>>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>>>>>>>q35 as a PCIe machine of xen.
> >>>>>>>>>>>
> >>>>>>>>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>>>>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>>>>>>>so you have the time to make it architecturally sound.
> >>>>>>>>>>>"Making existing guests work" would be a better motivation.
> >>>>>>>>>>
> >>>>>>>>>>Yes.
> >>>>>>>>>
> >>>>>>>>>So focus on this then. Existing guests will probably work
> >>>>>>>>>fine on a newer chipset - likely better than on i440fx.
> >>>>>>>>>xen management tools need to do some work to support this?
> >>>>>>>>>That will just give everyone more long term benefits.
> >>>>>>>>>
> >>>>>>>>>If instead we create a hack that does not resemble
> >>>>>>>>>any existing hardware even remotely, what's the
> >>>>>>>>>chance that it will not break with any future
> >>>>>>>>>guest modification?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>Isn't this possible with an mch chipset?
> >>>>>>>>>>
> >>>>>>>>>>If you're saying q35, I mean AFAIK we have no any plan to migrate to this
> >>>>>>>>>>MCH in xen case.
> >>>>>>>>>
> >>>>>>>>>q35 or a newer chipset that's closer to what guests expect.
> >>>>>>>>>
> >>>>>>>>>>Additionally, I think I should follow this feature after
> >>>>>>>>>>q35 can work for xen scenario.
> >>>>>>>>>
> >>>>>>>>>What's stopping you?
> >>>>>>>>
> >>>>>>>>I mean if you want create an new machine based on q35, actually this is
> >>>>>>>>equal to start making xen to migrate to q35 now. Right? I can't image how
> >>>>>>>>much effort should be done.
> >>>>>>>
> >>>>>>>I don't see why you don't try. Sounds like a more robust solution to me.
> >>>>>>
> >>>>>>As I think this is another requirement to us. I'm not sure if I have enough
> >>>>>>time to touch this currently.
> >>>>>>
> >>>>>>>
> >>>>>>>>So this is a reason why I'm saying I'd like to follow this feature after q35
> >>>>>>>>can work with xen completely.
> >>>>>>>
> >>>>>>>Then we'll end up with more configurations to support, and to what end?
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>So could we do this step by step:
> >>>>>>>>>>>>
> >>>>>>>>>>>>#1 phase: We just cover current qemu-xen implementation based on i44fx, so
> >>>>>>>>>>>>still provide that pseudo ISA bridge at 00:1f.0 as we already did.
> >>>>>>>>>>>
> >>>>>>>>>>>By the way there is no reason to put it at 00:1f.0 specifically I think.
> >>>>>>>>>>>So it seems simple: create a dummy device that gets device and
> >>>>>>>>>>>vendor id as properties. If you really like, add an option to get values
> >>>>>>>>>>
> >>>>>>>>>>Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
> >>>>>>>>>>passthrough: create pseudo intel isa bridge. There, we fake this device just
> >>>>>>>>>>at 00:1f.0.
> >>>>>>>>>>But you guys don't like this, and shouldn't this be just this point we
> >>>>>>>>>>discussing now?
> >>>>>>>>>>
> >>>>>>>>>>If you guys agree that , everything is fine.
> >>>>>>>>>
> >>>>>>>>>Actually, this isn't what you did.
> >>>>>>>>>Don't tie it to xen, and don't tie it to 1f.
> >>>>>>>>>Just make it a simple stub pci device.
> >>>>>>>>>Whoever wants it, creates it.
> >>>>>>>>>
> >>>>>>>>>The thing I worry about, is the chance this will break going forward.
> >>>>>>>>>So you created a system with 2 isa bridges.
> >>>>>>>>
> >>>>>>>>I don't set class type to claim this is an ISA bridge, just a normal PCI
> >>>>>>>>device.
> >>>>>>>>+static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
> >>>>>>>>*hdev)
> >>>>>>>>+{
> >>>>>>>>+    struct PCIDevice *dev;
> >>>>>>>>+
> >>>>>>>>+    char rid;
> >>>>>>>>+
> >>>>>>>>+    /* We havt to use a simple PCI device to fake this ISA bridge
> >>>>>>>>+     * to avoid making some confusion to BIOS and ACPI.
> >>>>>>>>+     */
> >>>>>>>>+    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
> >>>>>>>>"pseudo-intel-pch-isa-bridge");
> >>>>>>>>+
> >>>>>>>>+    qdev_init_nofail(&dev->qdev);
> >>>>>>>>+
> >>>>>>>>+    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
> >>>>>>>>+    pci_config_set_device_id(dev->config, hdev->device_id);
> >>>>>>>>+
> >>>>>>>>+    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
> >>>>>>>>+
> >>>>>>>>+    pci_config_set_revision(dev->config, rid);
> >>>>>>>>+
> >>>>>>>>+    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
> >>>>>>>>+    return 0;
> >>>>>>>>+}
> >>>>>>>
> >>>>>>>Then I don't see how it's supposed to work.
> >>>>>>>Doesn't i915 look for an isa bridge?
> >>>>>>>
> >>>>>>>         /*
> >>>>>>>          * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> >>>>>>>          * make graphics device passthrough work easy for VMM, that only
> >>>>>>>          * need to expose ISA bridge to let driver know the real hardware
> >>>>>>>          * underneath. This is a requirement from virtualization team.
> >>>>>>>          *
> >>>>>>>          * In some virtualized environments (e.g. XEN), there is irrelevant
> >>>>>>>          * ISA bridge in the system. To work reliably, we should scan trhough
> >>>>>>>          * all the ISA bridge devices and check for the first match, instead
> >>>>>>>          * of only checking the first one.
> >>>>>>>          */
> >>>>>>>         while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>>>>>>                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> >>>>>>>                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >>>>>>>                         dev_priv->pch_id = id;
> >>>>>>>
> >>>>>>>                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >>>>>>>                                 dev_priv->pch_type = PCH_IBX;
> >>>>>>>
> >>>>>>>etc
> >>>>>>>
> >>>>>>
> >>>>>>I already post this to mainline to change as follows:
> >>>>>>
> >>>>>>-	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> >>>>>>+	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> >>>>>>+	if (pch) {
> >>>>>
> >>>>>I see - responded on that mail - but I thought the point is to make
> >>>>>existing guests run? In fact you said so explicitly.
> >>>>>
> >>>>>
> >>>>>>Please refer to this,
> >>>>>>
> >>>>>>[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
> >>>>>>check class type
> >>>>>>
> >>>>>>Linux Native guys would like to accept this. And actually Windows always use
> >>>>>>devfn to detect this.
> >>>>>
> >>>>>In fact I see this:
> >>>>>
> >>>>>     linux 2.6.35-3.9 probes the 1st IA bridge
> >>>>>
> >>>>>         no idea how would you fix this.
> >>>>>         try changing default class for the main bridge?
> >>>>>
> >>>>>     linux 3.10 probes all ISA bridges
> >>>>>
> >>>>>         requires your stub to be the isa bridge?
> >>>>>
> >>>>>
> >>>>>I don't see why are driver guys so willing to do crazy things.  They
> >>>>>want to match specific device/vendor id pairs, why don't they do just
> >>>>>that? Why poke at class, random slot numbers etc etc?
> >>>>
> >>>>AFAIK what they did is from our previous incorrect requirement as I
> >>>>understand. So we need to correct this.
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>
> >>>Since we can't fix existing guests, I would say
> >>
> >>This shouldn't be a fix existing guest, and this is why I can send this
> >>before you guys accept GFX passthrough for qemu ML.
> >>
> >>I think you can re-read that patch head description. 1f.0 can work under all
> >>scenarios including qemu-xen-traditonal.
> >>
> >>And this is also expected by native Linux organically, and especially
> >>Windows always use devfn to detect PCH, this is not like current Linux. So
> >>here I just sync this to make sense.
> >>
> >>Unless you'd like to make Linux specific to this point.
> >>
> >>Tiejun
> >
> >Why don't both windows and linux drivers look device up
> >by device and vendor id?
> 
> Its easy to understand because the same video device can work under
> different PCH, but we need to do different initialization based on different
> PCH.
> 
> Thanks
> Tiejun

Right so why don't they look up the PCH by device and vendor id?
For example, on linux use pci_get_device to iterate over all intel
devices.
I'm sure windows has a similar API as well.

This isn't a suggestion to make the change in guests right now!
Just a question.


> >Same applies to MCH really.
> >
> >
> >>>get things working first, find a clean way for
> >>>new driver to work next.
> >>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>This is already not something that exists on real hardware.
> >>>>>>>>>So it might break some guests that will get confused.
> >>>>>>>>>Maybe we are lucky and most guests see an unfamiliar device
> >>>>>>>>>and ignore it. It seems believable.
> >>>>>>>>>
> >>>>>>>>>But your MCH hack overrides registers in the pci host.
> >>>>>>>>
> >>>>>>>>We just try to write *one* register we already confirm this is safe enough.
> >>>>>>>
> >>>>>>>This should go in code in form of comments:
> >>>>>>>document what this register does on 440fx
> >>>>>>>and why it's safe to override.
> >>>>>>>We don't see what you
> >>>>>>>confirmed off-line.
> >>>>>>
> >>>>>>That offset is one specific to IGD usage, not for i440fx common. This is why
> >>>>>>we need to expose something in the host bridge. They're just introduced to
> >>>>>>support IGD.
> >>>>>>
> >>>>>>>
> >>>>>>>>Other register are read-only.
> >>>>>>>
> >>>>>>>Doesn't matter, need to document these as well.
> >>>>>>
> >>>>>>I think everything are covered in igd_pci_write()/igd_pci_write().
> >>>>>>
> >>>>>>>
> >>>>>>>>>Are we lucky and there's nothing in these registers
> >>>>>>>>>of interest to guests? This seems much more fragile.
> >>>>>>>>>So please poke at the spec, and compile the list
> >>>>>>>>>of registers you want to touch, figure out why they are
> >>>>>>>>>safe to override, and put this all in code comments.
> >>>>>>>>>
> >>>>>>>>>And the same thing that applies to the isa bridge
> >>>>>>>>
> >>>>>>>>We just expose its own vendor/device ids here. We don't access to change
> >>>>>>>>anything in the isa bridge.
> >>>>>>>>
> >>>>>>>>>applies here too. It should work without QEMU touching
> >>>>>>>>>hosts' hardware.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>from sysfs: device and vendor id are world readable, so just get them
> >>>>>>>>>>>directly and not through xen wrappers, this way you can open the files
> >>>>>>>>>>>RO and not RW.
> >>>>>>>>>>>You seem to poke at revision as well, I don't see
> >>>>>>>>>>>driver looking at that - strictly necessary?
> >>>>>>>>>>>If yes please patch host kernel to expose that info in sysfs,
> >>>>>>>>>>>though we can fall back on pci config if not there.
> >>>>>>>>>>>
> >>>>>>>>>>>MCH (bridge_dev) hacks in i915 are nastier.
> >>>>>>>>>>>To clean them up, we really have to have an explicit driver for this
> >>>>>>>>>>>bridge, not a pass-through device.  Long term, the right thing to do is
> >>>>>>>>>>>likely to extend host driver and expose the necessary information in
> >>>>>>>>>>>sysfs on host kernel.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>I'm a bit confused. Any sysfs should be filled by the associated PCIe
> >>>>>>>>>>device, shouldn't it? So qemu still need to emulate this PCIe device
> >>>>>>>>>>firstly, then set properties into sysfs.
> >>>>>>>>>
> >>>>>>>>>I am talking about getting host properties into qemu.
> >>>>>>>>>You don't want to give qemu R/W root access to host sysfs system
> >>>>>>>>>of the root bridge, that's not secure.
> >>>>>>>>
> >>>>>>>>igd_pci_read()
> >>>>>>>>	|
> >>>>>>>>	+ xen_host_pci_get_block()
> >>>>>>>>		|
> >>>>>>>>		+ xen_host_pci_config_read(()
> >>>>>>>>			|
> >>>>>>>>			+  pread()
> >>>>>>>>
> >>>>>>>>So shouldn't we already expose these information via sysfs?
> >>>>>>>
> >>>>>>>That's poking at sysfs of a real device, and after opening it RW.
> >>>>>>
> >>>>>>I don't think we can really write anything to those read-only sysfs
> >>>>>>interface even we open them as RW.
> >>>>>>
> >>>>>>Tiejun
> >>>>>>
> >>>>>>>
> >>>>>>>>>Avoiding read only access to filesystem is a good idea too, so it
> >>>>>>>>>should be possible to pass all parameters in as
> >>>>>>>>>device properties, and let whoever starts qemu
> >>>>>>>>>figure out what are reasonable values.
> >>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>#2 phase: Now, we will choose a capability ID that won't be conflicting with
> >>>>>>>>>>>>others. To do this properly, we need to get one from PCI SIG group. To have
> >>>>>>>>>>>>this workable and consistently validated, this method shouldn't be virt
> >>>>>>>>>>>>specific. Then native driver should use the same method.
> >>>>>>>>>>>
> >>>>>>>>>>>You mean you will be able to talk sense into hardware guys?
> >>>>>>>>>>>I doubt that. If they could be convinced to make e.g. i915 base a
> >>>>>>>>>>
> >>>>>>>>>>We're negotiating this, so this is just our long term solution we figure out
> >>>>>>>>>>currently.
> >>>>>>>>>>
> >>>>>>>>>>>proper BAR, why didn't they?
> >>>>>>>>>>
> >>>>>>>>>>We already have no any free BAR as we mentioned previously.
> >>>>>>>>>
> >>>>>>>>>I thought you were talking about modifying hardware?
> >>>>>>>>
> >>>>>>>>Yes.
> >>>>>>>>
> >>>>>>>>Tiejun
> >>>>>>>
> >>>>>>>And they can't figure out how to stick extra info in an existing BAR?
> >>>>>>>Oh well, that's hardware for you.
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>So when xen work on
> >>>>>>>>>>>>q35 PCIe machine, we can walk this way.
> >>>>>>>>>>>
> >>>>>>>>>>>If you are emulating MCH anyway, pick one that is close
> >>>>>>>>>>>to what i915 driver expects. It would then work with existing
> >>>>>>>>>>
> >>>>>>>>>>Looks you guys prefer we create a new MCH anyway, right? But is it necessary
> >>>>>>>>>>to create a new based on i440fx just for a little change?
> >>>>>>>>>>
> >>>>>>>>>>Thanks
> >>>>>>>>>>Tiejun
> >>>>>>>>>
> >>>>>>>>>You can inherit it. Maybe you are lucky and this happens to
> >>>>>>>>>work without conflicting with whatever other guests want to do.
> >>>>>>>>>But if you ask me, you are really just piling up hacks.
> >>>>>>>>>If some guest does not work on i440, you should just work on
> >>>>>>>>>emulating whatever it does work on.
> >>>>>>>>>That would have real value.
> >>>>>>>>>
> >>>>>>>>>>>devices, without new capability IDs.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>Anthony,
> >>>>>>>>>>>>
> >>>>>>>>>>>>Any comments to address this in xen case?
> >>>>>>>>>>>>
> >>>>>>>>>>>>Thanks
> >>>>>>>>>>>>Tiejun
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>_______________________________________________
> >>>>>>>Xen-devel mailing list
> >>>>>>>Xen-devel@lists.xen.org
> >>>>>>>http://lists.xen.org/xen-devel
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>>
> >

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/2 14:22, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 08:59:38AM +0800, Chen, Tiejun wrote:
>> On 2014/7/1 20:33, Michael S. Tsirkin wrote:
>>> On Tue, Jul 01, 2014 at 05:46:58PM +0800, Chen, Tiejun wrote:
>>>> On 2014/7/1 17:12, Michael S. Tsirkin wrote:
>>>>> On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/30 19:28, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/30 17:55, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>>>>>>> MMIO BAR.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes.
>>>>>>>>>>>
>>>>>>>>>>> So focus on this then. Existing guests will probably work
>>>>>>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>>>>>>> xen management tools need to do some work to support this?
>>>>>>>>>>> That will just give everyone more long term benefits.
>>>>>>>>>>>
>>>>>>>>>>> If instead we create a hack that does not resemble
>>>>>>>>>>> any existing hardware even remotely, what's the
>>>>>>>>>>> chance that it will not break with any future
>>>>>>>>>>> guest modification?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Isn't this possible with an mch chipset?
>>>>>>>>>>>>
>>>>>>>>>>>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>>>>>>>>>>>> MCH in xen case.
>>>>>>>>>>>
>>>>>>>>>>> q35 or a newer chipset that's closer to what guests expect.
>>>>>>>>>>>
>>>>>>>>>>>> Additionally, I think I should follow this feature after
>>>>>>>>>>>> q35 can work for xen scenario.
>>>>>>>>>>>
>>>>>>>>>>> What's stopping you?
>>>>>>>>>>
>>>>>>>>>> I mean if you want create an new machine based on q35, actually this is
>>>>>>>>>> equal to start making xen to migrate to q35 now. Right? I can't image how
>>>>>>>>>> much effort should be done.
>>>>>>>>>
>>>>>>>>> I don't see why you don't try. Sounds like a more robust solution to me.
>>>>>>>>
>>>>>>>> As I think this is another requirement to us. I'm not sure if I have enough
>>>>>>>> time to touch this currently.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So this is a reason why I'm saying I'd like to follow this feature after q35
>>>>>>>>>> can work with xen completely.
>>>>>>>>>
>>>>>>>>> Then we'll end up with more configurations to support, and to what end?
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So could we do this step by step:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>>>>>>>>>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>>>>>>>>>>>
>>>>>>>>>>>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>>>>>>>>>>>> So it seems simple: create a dummy device that gets device and
>>>>>>>>>>>>> vendor id as properties. If you really like, add an option to get values
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>>>>>>>>>>>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>>>>>>>>>>>> at 00:1f.0.
>>>>>>>>>>>> But you guys don't like this, and shouldn't this be just this point we
>>>>>>>>>>>> discussing now?
>>>>>>>>>>>>
>>>>>>>>>>>> If you guys agree that , everything is fine.
>>>>>>>>>>>
>>>>>>>>>>> Actually, this isn't what you did.
>>>>>>>>>>> Don't tie it to xen, and don't tie it to 1f.
>>>>>>>>>>> Just make it a simple stub pci device.
>>>>>>>>>>> Whoever wants it, creates it.
>>>>>>>>>>>
>>>>>>>>>>> The thing I worry about, is the chance this will break going forward.
>>>>>>>>>>> So you created a system with 2 isa bridges.
>>>>>>>>>>
>>>>>>>>>> I don't set class type to claim this is an ISA bridge, just a normal PCI
>>>>>>>>>> device.
>>>>>>>>>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>>>>>>>>>> *hdev)
>>>>>>>>>> +{
>>>>>>>>>> +    struct PCIDevice *dev;
>>>>>>>>>> +
>>>>>>>>>> +    char rid;
>>>>>>>>>> +
>>>>>>>>>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>>>>>>>>>> +     * to avoid making some confusion to BIOS and ACPI.
>>>>>>>>>> +     */
>>>>>>>>>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>>>>>>>>>> "pseudo-intel-pch-isa-bridge");
>>>>>>>>>> +
>>>>>>>>>> +    qdev_init_nofail(&dev->qdev);
>>>>>>>>>> +
>>>>>>>>>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>>>>>>>>>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>>>>>>>>>> +
>>>>>>>>>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>>>>>>>>>> +
>>>>>>>>>> +    pci_config_set_revision(dev->config, rid);
>>>>>>>>>> +
>>>>>>>>>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>>>>>>>>> +    return 0;
>>>>>>>>>> +}
>>>>>>>>>
>>>>>>>>> Then I don't see how it's supposed to work.
>>>>>>>>> Doesn't i915 look for an isa bridge?
>>>>>>>>>
>>>>>>>>>          /*
>>>>>>>>>           * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>>>>>>>>>           * make graphics device passthrough work easy for VMM, that only
>>>>>>>>>           * need to expose ISA bridge to let driver know the real hardware
>>>>>>>>>           * underneath. This is a requirement from virtualization team.
>>>>>>>>>           *
>>>>>>>>>           * In some virtualized environments (e.g. XEN), there is irrelevant
>>>>>>>>>           * ISA bridge in the system. To work reliably, we should scan trhough
>>>>>>>>>           * all the ISA bridge devices and check for the first match, instead
>>>>>>>>>           * of only checking the first one.
>>>>>>>>>           */
>>>>>>>>>          while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>>>>>>>                  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>>>>>                          unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>>>>>                          dev_priv->pch_id = id;
>>>>>>>>>
>>>>>>>>>                          if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>>>>>                                  dev_priv->pch_type = PCH_IBX;
>>>>>>>>>
>>>>>>>>> etc
>>>>>>>>>
>>>>>>>>
>>>>>>>> I already post this to mainline to change as follows:
>>>>>>>>
>>>>>>>> -	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>>>>>> +	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>>>>>>>> +	if (pch) {
>>>>>>>
>>>>>>> I see - responded on that mail - but I thought the point is to make
>>>>>>> existing guests run? In fact you said so explicitly.
>>>>>>>
>>>>>>>
>>>>>>>> Please refer to this,
>>>>>>>>
>>>>>>>> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
>>>>>>>> check class type
>>>>>>>>
>>>>>>>> Linux Native guys would like to accept this. And actually Windows always use
>>>>>>>> devfn to detect this.
>>>>>>>
>>>>>>> In fact I see this:
>>>>>>>
>>>>>>>      linux 2.6.35-3.9 probes the 1st IA bridge
>>>>>>>
>>>>>>>          no idea how would you fix this.
>>>>>>>          try changing default class for the main bridge?
>>>>>>>
>>>>>>>      linux 3.10 probes all ISA bridges
>>>>>>>
>>>>>>>          requires your stub to be the isa bridge?
>>>>>>>
>>>>>>>
>>>>>>> I don't see why are driver guys so willing to do crazy things.  They
>>>>>>> want to match specific device/vendor id pairs, why don't they do just
>>>>>>> that? Why poke at class, random slot numbers etc etc?
>>>>>>
>>>>>> AFAIK what they did is from our previous incorrect requirement as I
>>>>>> understand. So we need to correct this.
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>> Since we can't fix existing guests, I would say
>>>>
>>>> This shouldn't be a fix existing guest, and this is why I can send this
>>>> before you guys accept GFX passthrough for qemu ML.
>>>>
>>>> I think you can re-read that patch head description. 1f.0 can work under all
>>>> scenarios including qemu-xen-traditonal.
>>>>
>>>> And this is also expected by native Linux organically, and especially
>>>> Windows always use devfn to detect PCH, this is not like current Linux. So
>>>> here I just sync this to make sense.
>>>>
>>>> Unless you'd like to make Linux specific to this point.
>>>>
>>>> Tiejun
>>>
>>> Why don't both windows and linux drivers look device up
>>> by device and vendor id?
>>
>> Its easy to understand because the same video device can work under
>> different PCH, but we need to do different initialization based on different
>> PCH.
>>
>> Thanks
>> Tiejun
>
> Right so why don't they look up the PCH by device and vendor id?
> For example, on linux use pci_get_device to iterate over all intel
> devices.

I think this will definitely work as long as we still have a PCI device 
represented with a real vendor/device ids.

> I'm sure windows has a similar API as well.

I guess this is true as well but firstly I have to further ask native 
team guys if both native Linux and Windows are like this way to avoid 
we're missing something.

Thanks
Tiejun

>
> This isn't a suggestion to make the change in guests right now!
> Just a question.
>
>
>>> Same applies to MCH really.
>>>
>>>
>>>>> get things working first, find a clean way for
>>>>> new driver to work next.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> This is already not something that exists on real hardware.
>>>>>>>>>>> So it might break some guests that will get confused.
>>>>>>>>>>> Maybe we are lucky and most guests see an unfamiliar device
>>>>>>>>>>> and ignore it. It seems believable.
>>>>>>>>>>>
>>>>>>>>>>> But your MCH hack overrides registers in the pci host.
>>>>>>>>>>
>>>>>>>>>> We just try to write *one* register we already confirm this is safe enough.
>>>>>>>>>
>>>>>>>>> This should go in code in form of comments:
>>>>>>>>> document what this register does on 440fx
>>>>>>>>> and why it's safe to override.
>>>>>>>>> We don't see what you
>>>>>>>>> confirmed off-line.
>>>>>>>>
>>>>>>>> That offset is one specific to IGD usage, not for i440fx common. This is why
>>>>>>>> we need to expose something in the host bridge. They're just introduced to
>>>>>>>> support IGD.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Other register are read-only.
>>>>>>>>>
>>>>>>>>> Doesn't matter, need to document these as well.
>>>>>>>>
>>>>>>>> I think everything are covered in igd_pci_write()/igd_pci_write().
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Are we lucky and there's nothing in these registers
>>>>>>>>>>> of interest to guests? This seems much more fragile.
>>>>>>>>>>> So please poke at the spec, and compile the list
>>>>>>>>>>> of registers you want to touch, figure out why they are
>>>>>>>>>>> safe to override, and put this all in code comments.
>>>>>>>>>>>
>>>>>>>>>>> And the same thing that applies to the isa bridge
>>>>>>>>>>
>>>>>>>>>> We just expose its own vendor/device ids here. We don't access to change
>>>>>>>>>> anything in the isa bridge.
>>>>>>>>>>
>>>>>>>>>>> applies here too. It should work without QEMU touching
>>>>>>>>>>> hosts' hardware.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> >from sysfs: device and vendor id are world readable, so just get them
>>>>>>>>>>>>> directly and not through xen wrappers, this way you can open the files
>>>>>>>>>>>>> RO and not RW.
>>>>>>>>>>>>> You seem to poke at revision as well, I don't see
>>>>>>>>>>>>> driver looking at that - strictly necessary?
>>>>>>>>>>>>> If yes please patch host kernel to expose that info in sysfs,
>>>>>>>>>>>>> though we can fall back on pci config if not there.
>>>>>>>>>>>>>
>>>>>>>>>>>>> MCH (bridge_dev) hacks in i915 are nastier.
>>>>>>>>>>>>> To clean them up, we really have to have an explicit driver for this
>>>>>>>>>>>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>>>>>>>>>>>> likely to extend host driver and expose the necessary information in
>>>>>>>>>>>>> sysfs on host kernel.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>>>>>>>>>>>> device, shouldn't it? So qemu still need to emulate this PCIe device
>>>>>>>>>>>> firstly, then set properties into sysfs.
>>>>>>>>>>>
>>>>>>>>>>> I am talking about getting host properties into qemu.
>>>>>>>>>>> You don't want to give qemu R/W root access to host sysfs system
>>>>>>>>>>> of the root bridge, that's not secure.
>>>>>>>>>>
>>>>>>>>>> igd_pci_read()
>>>>>>>>>> 	|
>>>>>>>>>> 	+ xen_host_pci_get_block()
>>>>>>>>>> 		|
>>>>>>>>>> 		+ xen_host_pci_config_read(()
>>>>>>>>>> 			|
>>>>>>>>>> 			+  pread()
>>>>>>>>>>
>>>>>>>>>> So shouldn't we already expose these information via sysfs?
>>>>>>>>>
>>>>>>>>> That's poking at sysfs of a real device, and after opening it RW.
>>>>>>>>
>>>>>>>> I don't think we can really write anything to those read-only sysfs
>>>>>>>> interface even we open them as RW.
>>>>>>>>
>>>>>>>> Tiejun
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Avoiding read only access to filesystem is a good idea too, so it
>>>>>>>>>>> should be possible to pass all parameters in as
>>>>>>>>>>> device properties, and let whoever starts qemu
>>>>>>>>>>> figure out what are reasonable values.
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>>>>>>>>>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>>>>>>>>>>>> this workable and consistently validated, this method shouldn't be virt
>>>>>>>>>>>>>> specific. Then native driver should use the same method.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You mean you will be able to talk sense into hardware guys?
>>>>>>>>>>>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>>>>>>>>>>>
>>>>>>>>>>>> We're negotiating this, so this is just our long term solution we figure out
>>>>>>>>>>>> currently.
>>>>>>>>>>>>
>>>>>>>>>>>>> proper BAR, why didn't they?
>>>>>>>>>>>>
>>>>>>>>>>>> We already have no any free BAR as we mentioned previously.
>>>>>>>>>>>
>>>>>>>>>>> I thought you were talking about modifying hardware?
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>> Tiejun
>>>>>>>>>
>>>>>>>>> And they can't figure out how to stick extra info in an existing BAR?
>>>>>>>>> Oh well, that's hardware for you.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So when xen work on
>>>>>>>>>>>>>> q35 PCIe machine, we can walk this way.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you are emulating MCH anyway, pick one that is close
>>>>>>>>>>>>> to what i915 driver expects. It would then work with existing
>>>>>>>>>>>>
>>>>>>>>>>>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>>>>>>>>>>>> to create a new based on i440fx just for a little change?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Tiejun
>>>>>>>>>>>
>>>>>>>>>>> You can inherit it. Maybe you are lucky and this happens to
>>>>>>>>>>> work without conflicting with whatever other guests want to do.
>>>>>>>>>>> But if you ask me, you are really just piling up hacks.
>>>>>>>>>>> If some guest does not work on i440, you should just work on
>>>>>>>>>>> emulating whatever it does work on.
>>>>>>>>>>> That would have real value.
>>>>>>>>>>>
>>>>>>>>>>>>> devices, without new capability IDs.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Anthony,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any comments to address this in xen case?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Tiejun
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Xen-devel mailing list
>>>>>>>>> Xen-devel@lists.xen.org
>>>>>>>>> http://lists.xen.org/xen-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>
>

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/2 14:22, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 08:59:38AM +0800, Chen, Tiejun wrote:
>> On 2014/7/1 20:33, Michael S. Tsirkin wrote:
>>> On Tue, Jul 01, 2014 at 05:46:58PM +0800, Chen, Tiejun wrote:
>>>> On 2014/7/1 17:12, Michael S. Tsirkin wrote:
>>>>> On Tue, Jul 01, 2014 at 10:40:42AM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/30 19:28, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jun 30, 2014 at 06:20:22PM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/30 17:55, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>>>>>>> MMIO BAR.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes.
>>>>>>>>>>>
>>>>>>>>>>> So focus on this then. Existing guests will probably work
>>>>>>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>>>>>>> xen management tools need to do some work to support this?
>>>>>>>>>>> That will just give everyone more long term benefits.
>>>>>>>>>>>
>>>>>>>>>>> If instead we create a hack that does not resemble
>>>>>>>>>>> any existing hardware even remotely, what's the
>>>>>>>>>>> chance that it will not break with any future
>>>>>>>>>>> guest modification?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Isn't this possible with an mch chipset?
>>>>>>>>>>>>
>>>>>>>>>>>> If you're saying q35, I mean AFAIK we have no any plan to migrate to this
>>>>>>>>>>>> MCH in xen case.
>>>>>>>>>>>
>>>>>>>>>>> q35 or a newer chipset that's closer to what guests expect.
>>>>>>>>>>>
>>>>>>>>>>>> Additionally, I think I should follow this feature after
>>>>>>>>>>>> q35 can work for xen scenario.
>>>>>>>>>>>
>>>>>>>>>>> What's stopping you?
>>>>>>>>>>
>>>>>>>>>> I mean if you want create an new machine based on q35, actually this is
>>>>>>>>>> equal to start making xen to migrate to q35 now. Right? I can't image how
>>>>>>>>>> much effort should be done.
>>>>>>>>>
>>>>>>>>> I don't see why you don't try. Sounds like a more robust solution to me.
>>>>>>>>
>>>>>>>> As I think this is another requirement to us. I'm not sure if I have enough
>>>>>>>> time to touch this currently.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> So this is a reason why I'm saying I'd like to follow this feature after q35
>>>>>>>>>> can work with xen completely.
>>>>>>>>>
>>>>>>>>> Then we'll end up with more configurations to support, and to what end?
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So could we do this step by step:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #1 phase: We just cover current qemu-xen implementation based on i44fx, so
>>>>>>>>>>>>>> still provide that pseudo ISA bridge at 00:1f.0 as we already did.
>>>>>>>>>>>>>
>>>>>>>>>>>>> By the way there is no reason to put it at 00:1f.0 specifically I think.
>>>>>>>>>>>>> So it seems simple: create a dummy device that gets device and
>>>>>>>>>>>>> vendor id as properties. If you really like, add an option to get values
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx
>>>>>>>>>>>> passthrough: create pseudo intel isa bridge. There, we fake this device just
>>>>>>>>>>>> at 00:1f.0.
>>>>>>>>>>>> But you guys don't like this, and shouldn't this be just this point we
>>>>>>>>>>>> discussing now?
>>>>>>>>>>>>
>>>>>>>>>>>> If you guys agree that , everything is fine.
>>>>>>>>>>>
>>>>>>>>>>> Actually, this isn't what you did.
>>>>>>>>>>> Don't tie it to xen, and don't tie it to 1f.
>>>>>>>>>>> Just make it a simple stub pci device.
>>>>>>>>>>> Whoever wants it, creates it.
>>>>>>>>>>>
>>>>>>>>>>> The thing I worry about, is the chance this will break going forward.
>>>>>>>>>>> So you created a system with 2 isa bridges.
>>>>>>>>>>
>>>>>>>>>> I don't set class type to claim this is an ISA bridge, just a normal PCI
>>>>>>>>>> device.
>>>>>>>>>> +static int create_pseudo_pch_isa_bridge(PCIBus *bus, XenHostPCIDevice
>>>>>>>>>> *hdev)
>>>>>>>>>> +{
>>>>>>>>>> +    struct PCIDevice *dev;
>>>>>>>>>> +
>>>>>>>>>> +    char rid;
>>>>>>>>>> +
>>>>>>>>>> +    /* We havt to use a simple PCI device to fake this ISA bridge
>>>>>>>>>> +     * to avoid making some confusion to BIOS and ACPI.
>>>>>>>>>> +     */
>>>>>>>>>> +    dev = pci_create(bus, PCI_DEVFN(0x1f, 0),
>>>>>>>>>> "pseudo-intel-pch-isa-bridge");
>>>>>>>>>> +
>>>>>>>>>> +    qdev_init_nofail(&dev->qdev);
>>>>>>>>>> +
>>>>>>>>>> +    pci_config_set_vendor_id(dev->config, hdev->vendor_id);
>>>>>>>>>> +    pci_config_set_device_id(dev->config, hdev->device_id);
>>>>>>>>>> +
>>>>>>>>>> +    xen_host_pci_get_block(hdev, PCI_REVISION_ID, (uint8_t *)&rid, 1);
>>>>>>>>>> +
>>>>>>>>>> +    pci_config_set_revision(dev->config, rid);
>>>>>>>>>> +
>>>>>>>>>> +    XEN_PT_LOG(dev, "The pseudo Intel PCH ISA bridge created.\n");
>>>>>>>>>> +    return 0;
>>>>>>>>>> +}
>>>>>>>>>
>>>>>>>>> Then I don't see how it's supposed to work.
>>>>>>>>> Doesn't i915 look for an isa bridge?
>>>>>>>>>
>>>>>>>>>          /*
>>>>>>>>>           * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>>>>>>>>>           * make graphics device passthrough work easy for VMM, that only
>>>>>>>>>           * need to expose ISA bridge to let driver know the real hardware
>>>>>>>>>           * underneath. This is a requirement from virtualization team.
>>>>>>>>>           *
>>>>>>>>>           * In some virtualized environments (e.g. XEN), there is irrelevant
>>>>>>>>>           * ISA bridge in the system. To work reliably, we should scan trhough
>>>>>>>>>           * all the ISA bridge devices and check for the first match, instead
>>>>>>>>>           * of only checking the first one.
>>>>>>>>>           */
>>>>>>>>>          while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>>>>>>>                  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>>>>>                          unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>>>>>                          dev_priv->pch_id = id;
>>>>>>>>>
>>>>>>>>>                          if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>>>>>                                  dev_priv->pch_type = PCH_IBX;
>>>>>>>>>
>>>>>>>>> etc
>>>>>>>>>
>>>>>>>>
>>>>>>>> I already post this to mainline to change as follows:
>>>>>>>>
>>>>>>>> -	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>>>>>>>> +	pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>>>>>>>> +	if (pch) {
>>>>>>>
>>>>>>> I see - responded on that mail - but I thought the point is to make
>>>>>>> existing guests run? In fact you said so explicitly.
>>>>>>>
>>>>>>>
>>>>>>>> Please refer to this,
>>>>>>>>
>>>>>>>> [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of
>>>>>>>> check class type
>>>>>>>>
>>>>>>>> Linux Native guys would like to accept this. And actually Windows always use
>>>>>>>> devfn to detect this.
>>>>>>>
>>>>>>> In fact I see this:
>>>>>>>
>>>>>>>      linux 2.6.35-3.9 probes the 1st IA bridge
>>>>>>>
>>>>>>>          no idea how would you fix this.
>>>>>>>          try changing default class for the main bridge?
>>>>>>>
>>>>>>>      linux 3.10 probes all ISA bridges
>>>>>>>
>>>>>>>          requires your stub to be the isa bridge?
>>>>>>>
>>>>>>>
>>>>>>> I don't see why are driver guys so willing to do crazy things.  They
>>>>>>> want to match specific device/vendor id pairs, why don't they do just
>>>>>>> that? Why poke at class, random slot numbers etc etc?
>>>>>>
>>>>>> AFAIK what they did is from our previous incorrect requirement as I
>>>>>> understand. So we need to correct this.
>>>>>>
>>>>>> Thanks
>>>>>> Tiejun
>>>>>
>>>>> Since we can't fix existing guests, I would say
>>>>
>>>> This shouldn't be a fix existing guest, and this is why I can send this
>>>> before you guys accept GFX passthrough for qemu ML.
>>>>
>>>> I think you can re-read that patch head description. 1f.0 can work under all
>>>> scenarios including qemu-xen-traditonal.
>>>>
>>>> And this is also expected by native Linux organically, and especially
>>>> Windows always use devfn to detect PCH, this is not like current Linux. So
>>>> here I just sync this to make sense.
>>>>
>>>> Unless you'd like to make Linux specific to this point.
>>>>
>>>> Tiejun
>>>
>>> Why don't both windows and linux drivers look device up
>>> by device and vendor id?
>>
>> Its easy to understand because the same video device can work under
>> different PCH, but we need to do different initialization based on different
>> PCH.
>>
>> Thanks
>> Tiejun
>
> Right so why don't they look up the PCH by device and vendor id?
> For example, on linux use pci_get_device to iterate over all intel
> devices.

I think this will definitely work as long as we still have a PCI device 
represented with a real vendor/device ids.

> I'm sure windows has a similar API as well.

I guess this is true as well but firstly I have to further ask native 
team guys if both native Linux and Windows are like this way to avoid 
we're missing something.

Thanks
Tiejun

>
> This isn't a suggestion to make the change in guests right now!
> Just a question.
>
>
>>> Same applies to MCH really.
>>>
>>>
>>>>> get things working first, find a clean way for
>>>>> new driver to work next.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> This is already not something that exists on real hardware.
>>>>>>>>>>> So it might break some guests that will get confused.
>>>>>>>>>>> Maybe we are lucky and most guests see an unfamiliar device
>>>>>>>>>>> and ignore it. It seems believable.
>>>>>>>>>>>
>>>>>>>>>>> But your MCH hack overrides registers in the pci host.
>>>>>>>>>>
>>>>>>>>>> We just try to write *one* register we already confirm this is safe enough.
>>>>>>>>>
>>>>>>>>> This should go in code in form of comments:
>>>>>>>>> document what this register does on 440fx
>>>>>>>>> and why it's safe to override.
>>>>>>>>> We don't see what you
>>>>>>>>> confirmed off-line.
>>>>>>>>
>>>>>>>> That offset is one specific to IGD usage, not for i440fx common. This is why
>>>>>>>> we need to expose something in the host bridge. They're just introduced to
>>>>>>>> support IGD.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Other register are read-only.
>>>>>>>>>
>>>>>>>>> Doesn't matter, need to document these as well.
>>>>>>>>
>>>>>>>> I think everything are covered in igd_pci_write()/igd_pci_write().
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Are we lucky and there's nothing in these registers
>>>>>>>>>>> of interest to guests? This seems much more fragile.
>>>>>>>>>>> So please poke at the spec, and compile the list
>>>>>>>>>>> of registers you want to touch, figure out why they are
>>>>>>>>>>> safe to override, and put this all in code comments.
>>>>>>>>>>>
>>>>>>>>>>> And the same thing that applies to the isa bridge
>>>>>>>>>>
>>>>>>>>>> We just expose its own vendor/device ids here. We don't access to change
>>>>>>>>>> anything in the isa bridge.
>>>>>>>>>>
>>>>>>>>>>> applies here too. It should work without QEMU touching
>>>>>>>>>>> hosts' hardware.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> >from sysfs: device and vendor id are world readable, so just get them
>>>>>>>>>>>>> directly and not through xen wrappers, this way you can open the files
>>>>>>>>>>>>> RO and not RW.
>>>>>>>>>>>>> You seem to poke at revision as well, I don't see
>>>>>>>>>>>>> driver looking at that - strictly necessary?
>>>>>>>>>>>>> If yes please patch host kernel to expose that info in sysfs,
>>>>>>>>>>>>> though we can fall back on pci config if not there.
>>>>>>>>>>>>>
>>>>>>>>>>>>> MCH (bridge_dev) hacks in i915 are nastier.
>>>>>>>>>>>>> To clean them up, we really have to have an explicit driver for this
>>>>>>>>>>>>> bridge, not a pass-through device.  Long term, the right thing to do is
>>>>>>>>>>>>> likely to extend host driver and expose the necessary information in
>>>>>>>>>>>>> sysfs on host kernel.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I'm a bit confused. Any sysfs should be filled by the associated PCIe
>>>>>>>>>>>> device, shouldn't it? So qemu still need to emulate this PCIe device
>>>>>>>>>>>> firstly, then set properties into sysfs.
>>>>>>>>>>>
>>>>>>>>>>> I am talking about getting host properties into qemu.
>>>>>>>>>>> You don't want to give qemu R/W root access to host sysfs system
>>>>>>>>>>> of the root bridge, that's not secure.
>>>>>>>>>>
>>>>>>>>>> igd_pci_read()
>>>>>>>>>> 	|
>>>>>>>>>> 	+ xen_host_pci_get_block()
>>>>>>>>>> 		|
>>>>>>>>>> 		+ xen_host_pci_config_read(()
>>>>>>>>>> 			|
>>>>>>>>>> 			+  pread()
>>>>>>>>>>
>>>>>>>>>> So shouldn't we already expose these information via sysfs?
>>>>>>>>>
>>>>>>>>> That's poking at sysfs of a real device, and after opening it RW.
>>>>>>>>
>>>>>>>> I don't think we can really write anything to those read-only sysfs
>>>>>>>> interface even we open them as RW.
>>>>>>>>
>>>>>>>> Tiejun
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Avoiding read only access to filesystem is a good idea too, so it
>>>>>>>>>>> should be possible to pass all parameters in as
>>>>>>>>>>> device properties, and let whoever starts qemu
>>>>>>>>>>> figure out what are reasonable values.
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> #2 phase: Now, we will choose a capability ID that won't be conflicting with
>>>>>>>>>>>>>> others. To do this properly, we need to get one from PCI SIG group. To have
>>>>>>>>>>>>>> this workable and consistently validated, this method shouldn't be virt
>>>>>>>>>>>>>> specific. Then native driver should use the same method.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You mean you will be able to talk sense into hardware guys?
>>>>>>>>>>>>> I doubt that. If they could be convinced to make e.g. i915 base a
>>>>>>>>>>>>
>>>>>>>>>>>> We're negotiating this, so this is just our long term solution we figure out
>>>>>>>>>>>> currently.
>>>>>>>>>>>>
>>>>>>>>>>>>> proper BAR, why didn't they?
>>>>>>>>>>>>
>>>>>>>>>>>> We already have no any free BAR as we mentioned previously.
>>>>>>>>>>>
>>>>>>>>>>> I thought you were talking about modifying hardware?
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>> Tiejun
>>>>>>>>>
>>>>>>>>> And they can't figure out how to stick extra info in an existing BAR?
>>>>>>>>> Oh well, that's hardware for you.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So when xen work on
>>>>>>>>>>>>>> q35 PCIe machine, we can walk this way.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you are emulating MCH anyway, pick one that is close
>>>>>>>>>>>>> to what i915 driver expects. It would then work with existing
>>>>>>>>>>>>
>>>>>>>>>>>> Looks you guys prefer we create a new MCH anyway, right? But is it necessary
>>>>>>>>>>>> to create a new based on i440fx just for a little change?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Tiejun
>>>>>>>>>>>
>>>>>>>>>>> You can inherit it. Maybe you are lucky and this happens to
>>>>>>>>>>> work without conflicting with whatever other guests want to do.
>>>>>>>>>>> But if you ask me, you are really just piling up hacks.
>>>>>>>>>>> If some guest does not work on i440, you should just work on
>>>>>>>>>>> emulating whatever it does work on.
>>>>>>>>>>> That would have real value.
>>>>>>>>>>>
>>>>>>>>>>>>> devices, without new capability IDs.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Anthony,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any comments to address this in xen case?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Tiejun
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Xen-devel mailing list
>>>>>>>>> Xen-devel@lists.xen.org
>>>>>>>>> http://lists.xen.org/xen-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>
>

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Stefano Stabellini]

On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > >On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > >>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > >>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> > >>>>
> > >>>>>
> > >>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> > >>>>>
> > >>>>
> > >>>>Are you saying the config space in the video device?
> > >>>
> > >>>No, I am saying in a new BAR, or at some magic offset of an existing
> > >>>MMIO BAR.
> > >>>
> > >>
> > >>As I mentioned previously, the IGD guy told me we have no any unused a
> > >>offset or BAR in the config space.
> > >>
> > >>And guy who are responsible for the native driver seems not be accept to
> > >>extend some magic offset of an existing MMIO BAR.
> > >>
> > >>In addition I think in a short time its not possible to migrate i440fx to
> > >>q35 as a PCIe machine of xen.
> > >
> > >That seems like a weak motivation.  I don't see a need to get something
> > >merged upstream in a short time: this seems sure to miss 2.1,
> > >so you have the time to make it architecturally sound.
> > >"Making existing guests work" would be a better motivation.
> > 
> > Yes.
> 
> So focus on this then. Existing guests will probably work
> fine on a newer chipset - likely better than on i440fx.
> xen management tools need to do some work to support this?

Unfortunately existing Windows guests don't take well chipset changes.
Windows might request a new activation.

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Stefano Stabellini]

On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > >On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > >>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > >>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> > >>>>
> > >>>>>
> > >>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> > >>>>>
> > >>>>
> > >>>>Are you saying the config space in the video device?
> > >>>
> > >>>No, I am saying in a new BAR, or at some magic offset of an existing
> > >>>MMIO BAR.
> > >>>
> > >>
> > >>As I mentioned previously, the IGD guy told me we have no any unused a
> > >>offset or BAR in the config space.
> > >>
> > >>And guy who are responsible for the native driver seems not be accept to
> > >>extend some magic offset of an existing MMIO BAR.
> > >>
> > >>In addition I think in a short time its not possible to migrate i440fx to
> > >>q35 as a PCIe machine of xen.
> > >
> > >That seems like a weak motivation.  I don't see a need to get something
> > >merged upstream in a short time: this seems sure to miss 2.1,
> > >so you have the time to make it architecturally sound.
> > >"Making existing guests work" would be a better motivation.
> > 
> > Yes.
> 
> So focus on this then. Existing guests will probably work
> fine on a newer chipset - likely better than on i440fx.
> xen management tools need to do some work to support this?

Unfortunately existing Windows guests don't take well chipset changes.
Windows might request a new activation.

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Ross Philipson]

On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>
>>>>>>>>
>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>
>>>>>>>
>>>>>>> Are you saying the config space in the video device?
>>>>>>
>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>> MMIO BAR.
>>>>>>
>>>>>
>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>> offset or BAR in the config space.
>>>>>
>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>
>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>> q35 as a PCIe machine of xen.
>>>>
>>>> That seems like a weak motivation.  I don't see a need to get something
>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>> so you have the time to make it architecturally sound.
>>>> "Making existing guests work" would be a better motivation.
>>>
>>> Yes.
>>
>> So focus on this then. Existing guests will probably work
>> fine on a newer chipset - likely better than on i440fx.
>> xen management tools need to do some work to support this?
>
> Unfortunately existing Windows guests don't take well chipset changes.
> Windows might request a new activation.

That is a very good point. A while back I did a bunch of work to try to 
keep Windows activated between running an instance of Windows on bare 
metal and as a VM. There were numerous bits of hardware and firmware 
that went into the calculation as to whether Windows thought it was the 
same platform for activation purposes. Changing the chipset sounds like 
a likely candidate for inspection. Somewhere out there on the webs is a 
partial list of the things that are inspected - lost the URL.

>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
>


-- 
Ross Philipson

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Ross Philipson]

On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>
>>>>>>>>
>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>
>>>>>>>
>>>>>>> Are you saying the config space in the video device?
>>>>>>
>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>> MMIO BAR.
>>>>>>
>>>>>
>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>> offset or BAR in the config space.
>>>>>
>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>
>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>> q35 as a PCIe machine of xen.
>>>>
>>>> That seems like a weak motivation.  I don't see a need to get something
>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>> so you have the time to make it architecturally sound.
>>>> "Making existing guests work" would be a better motivation.
>>>
>>> Yes.
>>
>> So focus on this then. Existing guests will probably work
>> fine on a newer chipset - likely better than on i440fx.
>> xen management tools need to do some work to support this?
>
> Unfortunately existing Windows guests don't take well chipset changes.
> Windows might request a new activation.

That is a very good point. A while back I did a bunch of work to try to 
keep Windows activated between running an instance of Windows on bare 
metal and as a VM. There were numerous bits of hardware and firmware 
that went into the calculation as to whether Windows thought it was the 
same platform for activation purposes. Changing the chipset sounds like 
a likely candidate for inspection. Somewhere out there on the webs is a 
partial list of the things that are inspected - lost the URL.

>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
>


-- 
Ross Philipson

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/1 3:31, Ross Philipson wrote:
> On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
>> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host
>>>>>>>>> MCH
>>>>>>>>>
>>>>>>>>
>>>>>>>> Are you saying the config space in the video device?
>>>>>>>
>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>> MMIO BAR.
>>>>>>>
>>>>>>
>>>>>> As I mentioned previously, the IGD guy told me we have no any
>>>>>> unused a
>>>>>> offset or BAR in the config space.
>>>>>>
>>>>>> And guy who are responsible for the native driver seems not be
>>>>>> accept to
>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>
>>>>>> In addition I think in a short time its not possible to migrate
>>>>>> i440fx to
>>>>>> q35 as a PCIe machine of xen.
>>>>>
>>>>> That seems like a weak motivation.  I don't see a need to get
>>>>> something
>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>> so you have the time to make it architecturally sound.
>>>>> "Making existing guests work" would be a better motivation.
>>>>
>>>> Yes.
>>>
>>> So focus on this then. Existing guests will probably work
>>> fine on a newer chipset - likely better than on i440fx.
>>> xen management tools need to do some work to support this?
>>
>> Unfortunately existing Windows guests don't take well chipset changes.
>> Windows might request a new activation.
>
> That is a very good point. A while back I did a bunch of work to try to
> keep Windows activated between running an instance of Windows on bare
> metal and as a VM. There were numerous bits of hardware and firmware
> that went into the calculation as to whether Windows thought it was the
> same platform for activation purposes. Changing the chipset sounds like
> a likely candidate for inspection. Somewhere out there on the webs is a
> partial list of the things that are inspected - lost the URL.
>

So do this mean currently we still can't go q35?

Thanks
Tiejun

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/1 3:31, Ross Philipson wrote:
> On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
>> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host
>>>>>>>>> MCH
>>>>>>>>>
>>>>>>>>
>>>>>>>> Are you saying the config space in the video device?
>>>>>>>
>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>> MMIO BAR.
>>>>>>>
>>>>>>
>>>>>> As I mentioned previously, the IGD guy told me we have no any
>>>>>> unused a
>>>>>> offset or BAR in the config space.
>>>>>>
>>>>>> And guy who are responsible for the native driver seems not be
>>>>>> accept to
>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>
>>>>>> In addition I think in a short time its not possible to migrate
>>>>>> i440fx to
>>>>>> q35 as a PCIe machine of xen.
>>>>>
>>>>> That seems like a weak motivation.  I don't see a need to get
>>>>> something
>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>> so you have the time to make it architecturally sound.
>>>>> "Making existing guests work" would be a better motivation.
>>>>
>>>> Yes.
>>>
>>> So focus on this then. Existing guests will probably work
>>> fine on a newer chipset - likely better than on i440fx.
>>> xen management tools need to do some work to support this?
>>
>> Unfortunately existing Windows guests don't take well chipset changes.
>> Windows might request a new activation.
>
> That is a very good point. A while back I did a bunch of work to try to
> keep Windows activated between running an instance of Windows on bare
> metal and as a VM. There were numerous bits of hardware and firmware
> that went into the calculation as to whether Windows thought it was the
> same platform for activation purposes. Changing the chipset sounds like
> a likely candidate for inspection. Somewhere out there on the webs is a
> partial list of the things that are inspected - lost the URL.
>

So do this mean currently we still can't go q35?

Thanks
Tiejun

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> >On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> >>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>
> >>>>>>>
> >>>>>>>Are you saying the config space in the video device?
> >>>>>>
> >>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>MMIO BAR.
> >>>>>>
> >>>>>
> >>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>offset or BAR in the config space.
> >>>>>
> >>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>
> >>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>q35 as a PCIe machine of xen.
> >>>>
> >>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>so you have the time to make it architecturally sound.
> >>>>"Making existing guests work" would be a better motivation.
> >>>
> >>>Yes.
> >>
> >>So focus on this then. Existing guests will probably work
> >>fine on a newer chipset - likely better than on i440fx.
> >>xen management tools need to do some work to support this?
> >
> >Unfortunately existing Windows guests don't take well chipset changes.
> >Windows might request a new activation.
> 
> That is a very good point. A while back I did a bunch of work to try to keep
> Windows activated between running an instance of Windows on bare metal and
> as a VM. There were numerous bits of hardware and firmware that went into
> the calculation as to whether Windows thought it was the same platform for
> activation purposes. Changing the chipset sounds like a likely candidate for
> inspection. Somewhere out there on the webs is a partial list of the things
> that are inspected - lost the URL.

It's not hard to try it out with kvm (you just need to remember to use ide with
q35: ahci is the default there).  I did, and windows did not ask me to
re-activate.

The detailed info is not hard to find:
http://en.wikipedia.org/wiki/Microsoft_Product_Activation
links to:
http://technet.microsoft.com/en-us/library/bb457054.aspx


1
Display Adapter
00010 (5)
2
SCSI Adapter
00011 (5)
3
IDE Adapter
0011 (4)
4
Network Adapter MAC Address
1001011000 (10)
5
RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
101 (3)
6
Processor Type
011 (3)
7
Processor Serial Number
000000 (6)
8
Hard Drive Device
1101100 (7)
9
Hard Drive Volume Serial Number
1001000001 (10)
10
CD—ROM / CD-RW / DVD-ROM
010111 (6)
-
"Dockable"
0 (1)
-
Hardware Hash version (version of algorithm used)
001 (3)

So no, chipset version won't cause re-activation.



> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xen.org
> >http://lists.xen.org/xen-devel
> >
> >-----
> >No virus found in this message.
> >Checked by AVG - www.avg.com
> >Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
> >
> 
> 
> -- 
> Ross Philipson

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> >On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> >>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>
> >>>>>>>
> >>>>>>>Are you saying the config space in the video device?
> >>>>>>
> >>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>MMIO BAR.
> >>>>>>
> >>>>>
> >>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>offset or BAR in the config space.
> >>>>>
> >>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>
> >>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>q35 as a PCIe machine of xen.
> >>>>
> >>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>so you have the time to make it architecturally sound.
> >>>>"Making existing guests work" would be a better motivation.
> >>>
> >>>Yes.
> >>
> >>So focus on this then. Existing guests will probably work
> >>fine on a newer chipset - likely better than on i440fx.
> >>xen management tools need to do some work to support this?
> >
> >Unfortunately existing Windows guests don't take well chipset changes.
> >Windows might request a new activation.
> 
> That is a very good point. A while back I did a bunch of work to try to keep
> Windows activated between running an instance of Windows on bare metal and
> as a VM. There were numerous bits of hardware and firmware that went into
> the calculation as to whether Windows thought it was the same platform for
> activation purposes. Changing the chipset sounds like a likely candidate for
> inspection. Somewhere out there on the webs is a partial list of the things
> that are inspected - lost the URL.

It's not hard to try it out with kvm (you just need to remember to use ide with
q35: ahci is the default there).  I did, and windows did not ask me to
re-activate.

The detailed info is not hard to find:
http://en.wikipedia.org/wiki/Microsoft_Product_Activation
links to:
http://technet.microsoft.com/en-us/library/bb457054.aspx


1
Display Adapter
00010 (5)
2
SCSI Adapter
00011 (5)
3
IDE Adapter
0011 (4)
4
Network Adapter MAC Address
1001011000 (10)
5
RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
101 (3)
6
Processor Type
011 (3)
7
Processor Serial Number
000000 (6)
8
Hard Drive Device
1101100 (7)
9
Hard Drive Volume Serial Number
1001000001 (10)
10
CD—ROM / CD-RW / DVD-ROM
010111 (6)
-
"Dockable"
0 (1)
-
Hardware Hash version (version of algorithm used)
001 (3)

So no, chipset version won't cause re-activation.



> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xen.org
> >http://lists.xen.org/xen-devel
> >
> >-----
> >No virus found in this message.
> >Checked by AVG - www.avg.com
> >Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
> >
> 
> 
> -- 
> Ross Philipson

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]

On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> > On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> > >On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> > >>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > >>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > >>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > >>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > >>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>Are you saying the config space in the video device?
> > >>>>>>
> > >>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> > >>>>>>MMIO BAR.
> > >>>>>>
> > >>>>>
> > >>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> > >>>>>offset or BAR in the config space.
> > >>>>>
> > >>>>>And guy who are responsible for the native driver seems not be accept to
> > >>>>>extend some magic offset of an existing MMIO BAR.
> > >>>>>
> > >>>>>In addition I think in a short time its not possible to migrate i440fx to
> > >>>>>q35 as a PCIe machine of xen.
> > >>>>
> > >>>>That seems like a weak motivation.  I don't see a need to get something
> > >>>>merged upstream in a short time: this seems sure to miss 2.1,
> > >>>>so you have the time to make it architecturally sound.
> > >>>>"Making existing guests work" would be a better motivation.
> > >>>
> > >>>Yes.
> > >>
> > >>So focus on this then. Existing guests will probably work
> > >>fine on a newer chipset - likely better than on i440fx.
> > >>xen management tools need to do some work to support this?
> > >
> > >Unfortunately existing Windows guests don't take well chipset changes.
> > >Windows might request a new activation.
> > 
> > That is a very good point. A while back I did a bunch of work to try to keep
> > Windows activated between running an instance of Windows on bare metal and
> > as a VM. There were numerous bits of hardware and firmware that went into
> > the calculation as to whether Windows thought it was the same platform for
> > activation purposes. Changing the chipset sounds like a likely candidate for
> > inspection. Somewhere out there on the webs is a partial list of the things
> > that are inspected - lost the URL.
> 
> It's not hard to try it out with kvm (you just need to remember to use ide with
> q35: ahci is the default there).  I did, and windows did not ask me to
> re-activate.
> 
> The detailed info is not hard to find:
> http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> links to:
> http://technet.microsoft.com/en-us/library/bb457054.aspx
> 
> 
> 1
> Display Adapter
> 00010 (5)
> 2
> SCSI Adapter
> 00011 (5)
> 3
> IDE Adapter
> 0011 (4)
> 4
> Network Adapter MAC Address
> 1001011000 (10)
> 5
> RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> 101 (3)
> 6
> Processor Type
> 011 (3)
> 7
> Processor Serial Number
> 000000 (6)
> 8
> Hard Drive Device
> 1101100 (7)
> 9
> Hard Drive Volume Serial Number
> 1001000001 (10)
> 10
> CD—ROM / CD-RW / DVD-ROM
> 010111 (6)
> -
> "Dockable"
> 0 (1)
> -
> Hardware Hash version (version of algorithm used)
> 001 (3)
> 
> So no, chipset version won't cause re-activation.

The page you linked is about Windows XP. Newer Windows versions have
stricter activation rules.  I don't think that moving existing VM images
from piix to q35 could be done without extensive testing of all the
major existing operating system images. I certainly wouldn't rely on a
wikipedia page for this.

Also I don't like the idea of tying Tiejun's patch series, that covers a
very narrow use case, to something as important and general purpose as
upgrading chipset.

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]

On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> > On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> > >On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> > >>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > >>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > >>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > >>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > >>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>Are you saying the config space in the video device?
> > >>>>>>
> > >>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> > >>>>>>MMIO BAR.
> > >>>>>>
> > >>>>>
> > >>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> > >>>>>offset or BAR in the config space.
> > >>>>>
> > >>>>>And guy who are responsible for the native driver seems not be accept to
> > >>>>>extend some magic offset of an existing MMIO BAR.
> > >>>>>
> > >>>>>In addition I think in a short time its not possible to migrate i440fx to
> > >>>>>q35 as a PCIe machine of xen.
> > >>>>
> > >>>>That seems like a weak motivation.  I don't see a need to get something
> > >>>>merged upstream in a short time: this seems sure to miss 2.1,
> > >>>>so you have the time to make it architecturally sound.
> > >>>>"Making existing guests work" would be a better motivation.
> > >>>
> > >>>Yes.
> > >>
> > >>So focus on this then. Existing guests will probably work
> > >>fine on a newer chipset - likely better than on i440fx.
> > >>xen management tools need to do some work to support this?
> > >
> > >Unfortunately existing Windows guests don't take well chipset changes.
> > >Windows might request a new activation.
> > 
> > That is a very good point. A while back I did a bunch of work to try to keep
> > Windows activated between running an instance of Windows on bare metal and
> > as a VM. There were numerous bits of hardware and firmware that went into
> > the calculation as to whether Windows thought it was the same platform for
> > activation purposes. Changing the chipset sounds like a likely candidate for
> > inspection. Somewhere out there on the webs is a partial list of the things
> > that are inspected - lost the URL.
> 
> It's not hard to try it out with kvm (you just need to remember to use ide with
> q35: ahci is the default there).  I did, and windows did not ask me to
> re-activate.
> 
> The detailed info is not hard to find:
> http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> links to:
> http://technet.microsoft.com/en-us/library/bb457054.aspx
> 
> 
> 1
> Display Adapter
> 00010 (5)
> 2
> SCSI Adapter
> 00011 (5)
> 3
> IDE Adapter
> 0011 (4)
> 4
> Network Adapter MAC Address
> 1001011000 (10)
> 5
> RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> 101 (3)
> 6
> Processor Type
> 011 (3)
> 7
> Processor Serial Number
> 000000 (6)
> 8
> Hard Drive Device
> 1101100 (7)
> 9
> Hard Drive Volume Serial Number
> 1001000001 (10)
> 10
> CD—ROM / CD-RW / DVD-ROM
> 010111 (6)
> -
> "Dockable"
> 0 (1)
> -
> Hardware Hash version (version of algorithm used)
> 001 (3)
> 
> So no, chipset version won't cause re-activation.

The page you linked is about Windows XP. Newer Windows versions have
stricter activation rules.  I don't think that moving existing VM images
from piix to q35 could be done without extensive testing of all the
major existing operating system images. I certainly wouldn't rely on a
wikipedia page for this.

Also I don't like the idea of tying Tiejun's patch series, that covers a
very narrow use case, to something as important and general purpose as
upgrading chipset.

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> > On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> > > On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> > > >On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> > > >>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > > >>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > > >>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > > >>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > > >>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> > > >>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>Are you saying the config space in the video device?
> > > >>>>>>
> > > >>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> > > >>>>>>MMIO BAR.
> > > >>>>>>
> > > >>>>>
> > > >>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> > > >>>>>offset or BAR in the config space.
> > > >>>>>
> > > >>>>>And guy who are responsible for the native driver seems not be accept to
> > > >>>>>extend some magic offset of an existing MMIO BAR.
> > > >>>>>
> > > >>>>>In addition I think in a short time its not possible to migrate i440fx to
> > > >>>>>q35 as a PCIe machine of xen.
> > > >>>>
> > > >>>>That seems like a weak motivation.  I don't see a need to get something
> > > >>>>merged upstream in a short time: this seems sure to miss 2.1,
> > > >>>>so you have the time to make it architecturally sound.
> > > >>>>"Making existing guests work" would be a better motivation.
> > > >>>
> > > >>>Yes.
> > > >>
> > > >>So focus on this then. Existing guests will probably work
> > > >>fine on a newer chipset - likely better than on i440fx.
> > > >>xen management tools need to do some work to support this?
> > > >
> > > >Unfortunately existing Windows guests don't take well chipset changes.
> > > >Windows might request a new activation.
> > > 
> > > That is a very good point. A while back I did a bunch of work to try to keep
> > > Windows activated between running an instance of Windows on bare metal and
> > > as a VM. There were numerous bits of hardware and firmware that went into
> > > the calculation as to whether Windows thought it was the same platform for
> > > activation purposes. Changing the chipset sounds like a likely candidate for
> > > inspection. Somewhere out there on the webs is a partial list of the things
> > > that are inspected - lost the URL.
> > 
> > It's not hard to try it out with kvm (you just need to remember to use ide with
> > q35: ahci is the default there).  I did, and windows did not ask me to
> > re-activate.
> > 
> > The detailed info is not hard to find:
> > http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> > links to:
> > http://technet.microsoft.com/en-us/library/bb457054.aspx
> > 
> > 
> > 1
> > Display Adapter
> > 00010 (5)
> > 2
> > SCSI Adapter
> > 00011 (5)
> > 3
> > IDE Adapter
> > 0011 (4)
> > 4
> > Network Adapter MAC Address
> > 1001011000 (10)
> > 5
> > RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> > 101 (3)
> > 6
> > Processor Type
> > 011 (3)
> > 7
> > Processor Serial Number
> > 000000 (6)
> > 8
> > Hard Drive Device
> > 1101100 (7)
> > 9
> > Hard Drive Volume Serial Number
> > 1001000001 (10)
> > 10
> > CD—ROM / CD-RW / DVD-ROM
> > 010111 (6)
> > -
> > "Dockable"
> > 0 (1)
> > -
> > Hardware Hash version (version of algorithm used)
> > 001 (3)
> > 
> > So no, chipset version won't cause re-activation.
> 
> The page you linked is about Windows XP. Newer Windows versions have
> stricter activation rules.  I don't think that moving existing VM images
> from piix to q35 could be done without extensive testing of all the
> major existing operating system images. I certainly wouldn't rely on a
> wikipedia page for this.

So do the testing then.
You don't even need to do anything on xen - run them all on kvm.
This testing will benefit everyone.

BTW is there a chance that adding the ISA bridge or doing other
tricks that Tiejun's patches do, will trigger windows activation?
Looks like this logic can cut both ways.

> Also I don't like the idea of tying Tiejun's patch series, that covers a
> very narrow use case, to something as important and general purpose as
> upgrading chipset.

If it's true that implementing igd passthrough on top of q35 is much
cleaner architecturally, then I don't see why we should merge a stop-gap
solution that we'll need to then support indefinitely.

We are talking about upstreaming functionality that xen already has, right?
So there's no time to market concern, whoever wants a solution today
has it.  Why not do it in the cleanest possible way?

-- 
MST

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> > On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> > > On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> > > >On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> > > >>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > > >>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > > >>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > > >>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > > >>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> > > >>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>Are you saying the config space in the video device?
> > > >>>>>>
> > > >>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> > > >>>>>>MMIO BAR.
> > > >>>>>>
> > > >>>>>
> > > >>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> > > >>>>>offset or BAR in the config space.
> > > >>>>>
> > > >>>>>And guy who are responsible for the native driver seems not be accept to
> > > >>>>>extend some magic offset of an existing MMIO BAR.
> > > >>>>>
> > > >>>>>In addition I think in a short time its not possible to migrate i440fx to
> > > >>>>>q35 as a PCIe machine of xen.
> > > >>>>
> > > >>>>That seems like a weak motivation.  I don't see a need to get something
> > > >>>>merged upstream in a short time: this seems sure to miss 2.1,
> > > >>>>so you have the time to make it architecturally sound.
> > > >>>>"Making existing guests work" would be a better motivation.
> > > >>>
> > > >>>Yes.
> > > >>
> > > >>So focus on this then. Existing guests will probably work
> > > >>fine on a newer chipset - likely better than on i440fx.
> > > >>xen management tools need to do some work to support this?
> > > >
> > > >Unfortunately existing Windows guests don't take well chipset changes.
> > > >Windows might request a new activation.
> > > 
> > > That is a very good point. A while back I did a bunch of work to try to keep
> > > Windows activated between running an instance of Windows on bare metal and
> > > as a VM. There were numerous bits of hardware and firmware that went into
> > > the calculation as to whether Windows thought it was the same platform for
> > > activation purposes. Changing the chipset sounds like a likely candidate for
> > > inspection. Somewhere out there on the webs is a partial list of the things
> > > that are inspected - lost the URL.
> > 
> > It's not hard to try it out with kvm (you just need to remember to use ide with
> > q35: ahci is the default there).  I did, and windows did not ask me to
> > re-activate.
> > 
> > The detailed info is not hard to find:
> > http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> > links to:
> > http://technet.microsoft.com/en-us/library/bb457054.aspx
> > 
> > 
> > 1
> > Display Adapter
> > 00010 (5)
> > 2
> > SCSI Adapter
> > 00011 (5)
> > 3
> > IDE Adapter
> > 0011 (4)
> > 4
> > Network Adapter MAC Address
> > 1001011000 (10)
> > 5
> > RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> > 101 (3)
> > 6
> > Processor Type
> > 011 (3)
> > 7
> > Processor Serial Number
> > 000000 (6)
> > 8
> > Hard Drive Device
> > 1101100 (7)
> > 9
> > Hard Drive Volume Serial Number
> > 1001000001 (10)
> > 10
> > CD—ROM / CD-RW / DVD-ROM
> > 010111 (6)
> > -
> > "Dockable"
> > 0 (1)
> > -
> > Hardware Hash version (version of algorithm used)
> > 001 (3)
> > 
> > So no, chipset version won't cause re-activation.
> 
> The page you linked is about Windows XP. Newer Windows versions have
> stricter activation rules.  I don't think that moving existing VM images
> from piix to q35 could be done without extensive testing of all the
> major existing operating system images. I certainly wouldn't rely on a
> wikipedia page for this.

So do the testing then.
You don't even need to do anything on xen - run them all on kvm.
This testing will benefit everyone.

BTW is there a chance that adding the ISA bridge or doing other
tricks that Tiejun's patches do, will trigger windows activation?
Looks like this logic can cut both ways.

> Also I don't like the idea of tying Tiejun's patch series, that covers a
> very narrow use case, to something as important and general purpose as
> upgrading chipset.

If it's true that implementing igd passthrough on top of q35 is much
cleaner architecturally, then I don't see why we should merge a stop-gap
solution that we'll need to then support indefinitely.

We are talking about upstreaming functionality that xen already has, right?
So there's no time to market concern, whoever wants a solution today
has it.  Why not do it in the cleanest possible way?

-- 
MST

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Ross Philipson]

On 07/01/2014 01:02 PM, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
>> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
>>>> On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
>>>>> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>
>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>> MMIO BAR.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>
>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>
>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>
>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>
>>>>>>> Yes.
>>>>>>
>>>>>> So focus on this then. Existing guests will probably work
>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>> xen management tools need to do some work to support this?
>>>>>
>>>>> Unfortunately existing Windows guests don't take well chipset changes.
>>>>> Windows might request a new activation.
>>>>
>>>> That is a very good point. A while back I did a bunch of work to try to keep
>>>> Windows activated between running an instance of Windows on bare metal and
>>>> as a VM. There were numerous bits of hardware and firmware that went into
>>>> the calculation as to whether Windows thought it was the same platform for
>>>> activation purposes. Changing the chipset sounds like a likely candidate for
>>>> inspection. Somewhere out there on the webs is a partial list of the things
>>>> that are inspected - lost the URL.
>>>
>>> It's not hard to try it out with kvm (you just need to remember to use ide with
>>> q35: ahci is the default there).  I did, and windows did not ask me to
>>> re-activate.
>>>
>>> The detailed info is not hard to find:
>>> http://en.wikipedia.org/wiki/Microsoft_Product_Activation
>>> links to:
>>> http://technet.microsoft.com/en-us/library/bb457054.aspx
>>>
>>>
>>> 1
>>> Display Adapter
>>> 00010 (5)
>>> 2
>>> SCSI Adapter
>>> 00011 (5)
>>> 3
>>> IDE Adapter
>>> 0011 (4)
>>> 4
>>> Network Adapter MAC Address
>>> 1001011000 (10)
>>> 5
>>> RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
>>> 101 (3)
>>> 6
>>> Processor Type
>>> 011 (3)
>>> 7
>>> Processor Serial Number
>>> 000000 (6)
>>> 8
>>> Hard Drive Device
>>> 1101100 (7)
>>> 9
>>> Hard Drive Volume Serial Number
>>> 1001000001 (10)
>>> 10
>>> CD—ROM / CD-RW / DVD-ROM
>>> 010111 (6)
>>> -
>>> "Dockable"
>>> 0 (1)
>>> -
>>> Hardware Hash version (version of algorithm used)
>>> 001 (3)
>>>
>>> So no, chipset version won't cause re-activation.
>>
>> The page you linked is about Windows XP. Newer Windows versions have
>> stricter activation rules.  I don't think that moving existing VM images
>> from piix to q35 could be done without extensive testing of all the
>> major existing operating system images. I certainly wouldn't rely on a
>> wikipedia page for this.
>
> So do the testing then.
> You don't even need to do anything on xen - run them all on kvm.
> This testing will benefit everyone.
>
> BTW is there a chance that adding the ISA bridge or doing other
> tricks that Tiejun's patches do, will trigger windows activation?
> Looks like this logic can cut both ways.

We do IGD pass-through in our project (XenClient). The patches 
originally came from our project. We surface the same ISA bridge and 
have never had activation issues on any version of Widows from XP to 
Win8. We do not normally run server platforms so I can't say for sure there.

>
>> Also I don't like the idea of tying Tiejun's patch series, that covers a
>> very narrow use case, to something as important and general purpose as
>> upgrading chipset.
>
> If it's true that implementing igd passthrough on top of q35 is much
> cleaner architecturally, then I don't see why we should merge a stop-gap
> solution that we'll need to then support indefinitely.
>
> We are talking about upstreaming functionality that xen already has, right?
> So there's no time to market concern, whoever wants a solution today
> has it.  Why not do it in the cleanest possible way?
>


-- 
Ross Philipson

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Ross Philipson]

On 07/01/2014 01:02 PM, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
>> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
>>> On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
>>>> On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
>>>>> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>
>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>> MMIO BAR.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>
>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>
>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>
>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>
>>>>>>> Yes.
>>>>>>
>>>>>> So focus on this then. Existing guests will probably work
>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>> xen management tools need to do some work to support this?
>>>>>
>>>>> Unfortunately existing Windows guests don't take well chipset changes.
>>>>> Windows might request a new activation.
>>>>
>>>> That is a very good point. A while back I did a bunch of work to try to keep
>>>> Windows activated between running an instance of Windows on bare metal and
>>>> as a VM. There were numerous bits of hardware and firmware that went into
>>>> the calculation as to whether Windows thought it was the same platform for
>>>> activation purposes. Changing the chipset sounds like a likely candidate for
>>>> inspection. Somewhere out there on the webs is a partial list of the things
>>>> that are inspected - lost the URL.
>>>
>>> It's not hard to try it out with kvm (you just need to remember to use ide with
>>> q35: ahci is the default there).  I did, and windows did not ask me to
>>> re-activate.
>>>
>>> The detailed info is not hard to find:
>>> http://en.wikipedia.org/wiki/Microsoft_Product_Activation
>>> links to:
>>> http://technet.microsoft.com/en-us/library/bb457054.aspx
>>>
>>>
>>> 1
>>> Display Adapter
>>> 00010 (5)
>>> 2
>>> SCSI Adapter
>>> 00011 (5)
>>> 3
>>> IDE Adapter
>>> 0011 (4)
>>> 4
>>> Network Adapter MAC Address
>>> 1001011000 (10)
>>> 5
>>> RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
>>> 101 (3)
>>> 6
>>> Processor Type
>>> 011 (3)
>>> 7
>>> Processor Serial Number
>>> 000000 (6)
>>> 8
>>> Hard Drive Device
>>> 1101100 (7)
>>> 9
>>> Hard Drive Volume Serial Number
>>> 1001000001 (10)
>>> 10
>>> CD—ROM / CD-RW / DVD-ROM
>>> 010111 (6)
>>> -
>>> "Dockable"
>>> 0 (1)
>>> -
>>> Hardware Hash version (version of algorithm used)
>>> 001 (3)
>>>
>>> So no, chipset version won't cause re-activation.
>>
>> The page you linked is about Windows XP. Newer Windows versions have
>> stricter activation rules.  I don't think that moving existing VM images
>> from piix to q35 could be done without extensive testing of all the
>> major existing operating system images. I certainly wouldn't rely on a
>> wikipedia page for this.
>
> So do the testing then.
> You don't even need to do anything on xen - run them all on kvm.
> This testing will benefit everyone.
>
> BTW is there a chance that adding the ISA bridge or doing other
> tricks that Tiejun's patches do, will trigger windows activation?
> Looks like this logic can cut both ways.

We do IGD pass-through in our project (XenClient). The patches 
originally came from our project. We surface the same ISA bridge and 
have never had activation issues on any version of Widows from XP to 
Win8. We do not normally run server platforms so I can't say for sure there.

>
>> Also I don't like the idea of tying Tiejun's patch series, that covers a
>> very narrow use case, to something as important and general purpose as
>> upgrading chipset.
>
> If it's true that implementing igd passthrough on top of q35 is much
> cleaner architecturally, then I don't see why we should merge a stop-gap
> solution that we'll need to then support indefinitely.
>
> We are talking about upstreaming functionality that xen already has, right?
> So there's no time to market concern, whoever wants a solution today
> has it.  Why not do it in the cleanest possible way?
>


-- 
Ross Philipson

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote:
> On 07/01/2014 01:02 PM, Michael S. Tsirkin wrote:
> >On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
> >>On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> >>>>On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> >>>>>On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> >>>>>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>Are you saying the config space in the video device?
> >>>>>>>>>>
> >>>>>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>>>>MMIO BAR.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>>>>offset or BAR in the config space.
> >>>>>>>>>
> >>>>>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>>>>
> >>>>>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>>>>q35 as a PCIe machine of xen.
> >>>>>>>>
> >>>>>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>>>>so you have the time to make it architecturally sound.
> >>>>>>>>"Making existing guests work" would be a better motivation.
> >>>>>>>
> >>>>>>>Yes.
> >>>>>>
> >>>>>>So focus on this then. Existing guests will probably work
> >>>>>>fine on a newer chipset - likely better than on i440fx.
> >>>>>>xen management tools need to do some work to support this?
> >>>>>
> >>>>>Unfortunately existing Windows guests don't take well chipset changes.
> >>>>>Windows might request a new activation.
> >>>>
> >>>>That is a very good point. A while back I did a bunch of work to try to keep
> >>>>Windows activated between running an instance of Windows on bare metal and
> >>>>as a VM. There were numerous bits of hardware and firmware that went into
> >>>>the calculation as to whether Windows thought it was the same platform for
> >>>>activation purposes. Changing the chipset sounds like a likely candidate for
> >>>>inspection. Somewhere out there on the webs is a partial list of the things
> >>>>that are inspected - lost the URL.
> >>>
> >>>It's not hard to try it out with kvm (you just need to remember to use ide with
> >>>q35: ahci is the default there).  I did, and windows did not ask me to
> >>>re-activate.
> >>>
> >>>The detailed info is not hard to find:
> >>>http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> >>>links to:
> >>>http://technet.microsoft.com/en-us/library/bb457054.aspx
> >>>
> >>>
> >>>1
> >>>Display Adapter
> >>>00010 (5)
> >>>2
> >>>SCSI Adapter
> >>>00011 (5)
> >>>3
> >>>IDE Adapter
> >>>0011 (4)
> >>>4
> >>>Network Adapter MAC Address
> >>>1001011000 (10)
> >>>5
> >>>RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> >>>101 (3)
> >>>6
> >>>Processor Type
> >>>011 (3)
> >>>7
> >>>Processor Serial Number
> >>>000000 (6)
> >>>8
> >>>Hard Drive Device
> >>>1101100 (7)
> >>>9
> >>>Hard Drive Volume Serial Number
> >>>1001000001 (10)
> >>>10
> >>>CD—ROM / CD-RW / DVD-ROM
> >>>010111 (6)
> >>>-
> >>>"Dockable"
> >>>0 (1)
> >>>-
> >>>Hardware Hash version (version of algorithm used)
> >>>001 (3)
> >>>
> >>>So no, chipset version won't cause re-activation.
> >>
> >>The page you linked is about Windows XP. Newer Windows versions have
> >>stricter activation rules.  I don't think that moving existing VM images
> >>from piix to q35 could be done without extensive testing of all the
> >>major existing operating system images. I certainly wouldn't rely on a
> >>wikipedia page for this.
> >
> >So do the testing then.
> >You don't even need to do anything on xen - run them all on kvm.
> >This testing will benefit everyone.
> >
> >BTW is there a chance that adding the ISA bridge or doing other
> >tricks that Tiejun's patches do, will trigger windows activation?
> >Looks like this logic can cut both ways.
> 
> We do IGD pass-through in our project (XenClient). The patches originally
> came from our project. We surface the same ISA bridge and have never had
> activation issues on any version of Widows from XP to Win8. We do not
> normally run server platforms so I can't say for sure there.

What class does your ISA bridge device have?

> >
> >>Also I don't like the idea of tying Tiejun's patch series, that covers a
> >>very narrow use case, to something as important and general purpose as
> >>upgrading chipset.
> >
> >If it's true that implementing igd passthrough on top of q35 is much
> >cleaner architecturally, then I don't see why we should merge a stop-gap
> >solution that we'll need to then support indefinitely.
> >
> >We are talking about upstreaming functionality that xen already has, right?
> >So there's no time to market concern, whoever wants a solution today
> >has it.  Why not do it in the cleanest possible way?
> >
> 
> 
> -- 
> Ross Philipson

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote:
> On 07/01/2014 01:02 PM, Michael S. Tsirkin wrote:
> >On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
> >>On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> >>>>On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> >>>>>On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> >>>>>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>Are you saying the config space in the video device?
> >>>>>>>>>>
> >>>>>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>>>>MMIO BAR.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>>>>offset or BAR in the config space.
> >>>>>>>>>
> >>>>>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>>>>
> >>>>>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>>>>q35 as a PCIe machine of xen.
> >>>>>>>>
> >>>>>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>>>>so you have the time to make it architecturally sound.
> >>>>>>>>"Making existing guests work" would be a better motivation.
> >>>>>>>
> >>>>>>>Yes.
> >>>>>>
> >>>>>>So focus on this then. Existing guests will probably work
> >>>>>>fine on a newer chipset - likely better than on i440fx.
> >>>>>>xen management tools need to do some work to support this?
> >>>>>
> >>>>>Unfortunately existing Windows guests don't take well chipset changes.
> >>>>>Windows might request a new activation.
> >>>>
> >>>>That is a very good point. A while back I did a bunch of work to try to keep
> >>>>Windows activated between running an instance of Windows on bare metal and
> >>>>as a VM. There were numerous bits of hardware and firmware that went into
> >>>>the calculation as to whether Windows thought it was the same platform for
> >>>>activation purposes. Changing the chipset sounds like a likely candidate for
> >>>>inspection. Somewhere out there on the webs is a partial list of the things
> >>>>that are inspected - lost the URL.
> >>>
> >>>It's not hard to try it out with kvm (you just need to remember to use ide with
> >>>q35: ahci is the default there).  I did, and windows did not ask me to
> >>>re-activate.
> >>>
> >>>The detailed info is not hard to find:
> >>>http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> >>>links to:
> >>>http://technet.microsoft.com/en-us/library/bb457054.aspx
> >>>
> >>>
> >>>1
> >>>Display Adapter
> >>>00010 (5)
> >>>2
> >>>SCSI Adapter
> >>>00011 (5)
> >>>3
> >>>IDE Adapter
> >>>0011 (4)
> >>>4
> >>>Network Adapter MAC Address
> >>>1001011000 (10)
> >>>5
> >>>RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> >>>101 (3)
> >>>6
> >>>Processor Type
> >>>011 (3)
> >>>7
> >>>Processor Serial Number
> >>>000000 (6)
> >>>8
> >>>Hard Drive Device
> >>>1101100 (7)
> >>>9
> >>>Hard Drive Volume Serial Number
> >>>1001000001 (10)
> >>>10
> >>>CD—ROM / CD-RW / DVD-ROM
> >>>010111 (6)
> >>>-
> >>>"Dockable"
> >>>0 (1)
> >>>-
> >>>Hardware Hash version (version of algorithm used)
> >>>001 (3)
> >>>
> >>>So no, chipset version won't cause re-activation.
> >>
> >>The page you linked is about Windows XP. Newer Windows versions have
> >>stricter activation rules.  I don't think that moving existing VM images
> >>from piix to q35 could be done without extensive testing of all the
> >>major existing operating system images. I certainly wouldn't rely on a
> >>wikipedia page for this.
> >
> >So do the testing then.
> >You don't even need to do anything on xen - run them all on kvm.
> >This testing will benefit everyone.
> >
> >BTW is there a chance that adding the ISA bridge or doing other
> >tricks that Tiejun's patches do, will trigger windows activation?
> >Looks like this logic can cut both ways.
> 
> We do IGD pass-through in our project (XenClient). The patches originally
> came from our project. We surface the same ISA bridge and have never had
> activation issues on any version of Widows from XP to Win8. We do not
> normally run server platforms so I can't say for sure there.

What class does your ISA bridge device have?

> >
> >>Also I don't like the idea of tying Tiejun's patch series, that covers a
> >>very narrow use case, to something as important and general purpose as
> >>upgrading chipset.
> >
> >If it's true that implementing igd passthrough on top of q35 is much
> >cleaner architecturally, then I don't see why we should merge a stop-gap
> >solution that we'll need to then support indefinitely.
> >
> >We are talking about upstreaming functionality that xen already has, right?
> >So there's no time to market concern, whoever wants a solution today
> >has it.  Why not do it in the cleanest possible way?
> >
> 
> 
> -- 
> Ross Philipson

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Ross Philipson]

On 07/01/2014 02:06 PM, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote:

[snip]

>
> What class does your ISA bridge device have?

#define PCI_CLASS_BRIDGE_ISA             0x0601

>
>>>
>>>> Also I don't like the idea of tying Tiejun's patch series, that covers a
>>>> very narrow use case, to something as important and general purpose as
>>>> upgrading chipset.
>>>
>>> If it's true that implementing igd passthrough on top of q35 is much
>>> cleaner architecturally, then I don't see why we should merge a stop-gap
>>> solution that we'll need to then support indefinitely.
>>>
>>> We are talking about upstreaming functionality that xen already has, right?
>>> So there's no time to market concern, whoever wants a solution today
>>> has it.  Why not do it in the cleanest possible way?
>>>
>>
>>
>> --
>> Ross Philipson
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
>


-- 
Ross Philipson

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Ross Philipson]

On 07/01/2014 02:06 PM, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote:

[snip]

>
> What class does your ISA bridge device have?

#define PCI_CLASS_BRIDGE_ISA             0x0601

>
>>>
>>>> Also I don't like the idea of tying Tiejun's patch series, that covers a
>>>> very narrow use case, to something as important and general purpose as
>>>> upgrading chipset.
>>>
>>> If it's true that implementing igd passthrough on top of q35 is much
>>> cleaner architecturally, then I don't see why we should merge a stop-gap
>>> solution that we'll need to then support indefinitely.
>>>
>>> We are talking about upstreaming functionality that xen already has, right?
>>> So there's no time to market concern, whoever wants a solution today
>>> has it.  Why not do it in the cleanest possible way?
>>>
>>
>>
>> --
>> Ross Philipson
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
>


-- 
Ross Philipson

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 03:29:03PM -0400, Ross Philipson wrote:
> On 07/01/2014 02:06 PM, Michael S. Tsirkin wrote:
> >On Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote:
> 
> [snip]
> 
> >
> >What class does your ISA bridge device have?
> 
> #define PCI_CLASS_BRIDGE_ISA             0x0601

Okay I guessed so. But IIRC Tiejun's suggesting giving it a different
class. So we don't know what the effect will be on various guests
without testing.


> >
> >>>
> >>>>Also I don't like the idea of tying Tiejun's patch series, that covers a
> >>>>very narrow use case, to something as important and general purpose as
> >>>>upgrading chipset.
> >>>
> >>>If it's true that implementing igd passthrough on top of q35 is much
> >>>cleaner architecturally, then I don't see why we should merge a stop-gap
> >>>solution that we'll need to then support indefinitely.
> >>>
> >>>We are talking about upstreaming functionality that xen already has, right?
> >>>So there's no time to market concern, whoever wants a solution today
> >>>has it.  Why not do it in the cleanest possible way?
> >>>
> >>
> >>
> >>--
> >>Ross Philipson
> >
> >-----
> >No virus found in this message.
> >Checked by AVG - www.avg.com
> >Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
> >
> 
> 
> -- 
> Ross Philipson

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 03:29:03PM -0400, Ross Philipson wrote:
> On 07/01/2014 02:06 PM, Michael S. Tsirkin wrote:
> >On Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote:
> 
> [snip]
> 
> >
> >What class does your ISA bridge device have?
> 
> #define PCI_CLASS_BRIDGE_ISA             0x0601

Okay I guessed so. But IIRC Tiejun's suggesting giving it a different
class. So we don't know what the effect will be on various guests
without testing.


> >
> >>>
> >>>>Also I don't like the idea of tying Tiejun's patch series, that covers a
> >>>>very narrow use case, to something as important and general purpose as
> >>>>upgrading chipset.
> >>>
> >>>If it's true that implementing igd passthrough on top of q35 is much
> >>>cleaner architecturally, then I don't see why we should merge a stop-gap
> >>>solution that we'll need to then support indefinitely.
> >>>
> >>>We are talking about upstreaming functionality that xen already has, right?
> >>>So there's no time to market concern, whoever wants a solution today
> >>>has it.  Why not do it in the cleanest possible way?
> >>>
> >>
> >>
> >>--
> >>Ross Philipson
> >
> >-----
> >No virus found in this message.
> >Checked by AVG - www.avg.com
> >Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
> >
> 
> 
> -- 
> Ross Philipson

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/2 14:11, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 03:29:03PM -0400, Ross Philipson wrote:
>> On 07/01/2014 02:06 PM, Michael S. Tsirkin wrote:
>>> On Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote:
>>
>> [snip]
>>
>>>
>>> What class does your ISA bridge device have?
>>
>> #define PCI_CLASS_BRIDGE_ISA             0x0601
>
> Okay I guessed so. But IIRC Tiejun's suggesting giving it a different

Organically we really use this class. But Paolo said this introduce two 
ISA bridges, then something will be confused. Sorry I can't find that 
quickly since we have so long discussion, so long email thread :(

Thanks
Tiejun

> class. So we don't know what the effect will be on various guests
> without testing.
>
>
>>>
>>>>>
>>>>>> Also I don't like the idea of tying Tiejun's patch series, that covers a
>>>>>> very narrow use case, to something as important and general purpose as
>>>>>> upgrading chipset.
>>>>>
>>>>> If it's true that implementing igd passthrough on top of q35 is much
>>>>> cleaner architecturally, then I don't see why we should merge a stop-gap
>>>>> solution that we'll need to then support indefinitely.
>>>>>
>>>>> We are talking about upstreaming functionality that xen already has, right?
>>>>> So there's no time to market concern, whoever wants a solution today
>>>>> has it.  Why not do it in the cleanest possible way?
>>>>>
>>>>
>>>>
>>>> --
>>>> Ross Philipson
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
>>>
>>
>>
>> --
>> Ross Philipson
>
>

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/2 14:11, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 03:29:03PM -0400, Ross Philipson wrote:
>> On 07/01/2014 02:06 PM, Michael S. Tsirkin wrote:
>>> On Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote:
>>
>> [snip]
>>
>>>
>>> What class does your ISA bridge device have?
>>
>> #define PCI_CLASS_BRIDGE_ISA             0x0601
>
> Okay I guessed so. But IIRC Tiejun's suggesting giving it a different

Organically we really use this class. But Paolo said this introduce two 
ISA bridges, then something will be confused. Sorry I can't find that 
quickly since we have so long discussion, so long email thread :(

Thanks
Tiejun

> class. So we don't know what the effect will be on various guests
> without testing.
>
>
>>>
>>>>>
>>>>>> Also I don't like the idea of tying Tiejun's patch series, that covers a
>>>>>> very narrow use case, to something as important and general purpose as
>>>>>> upgrading chipset.
>>>>>
>>>>> If it's true that implementing igd passthrough on top of q35 is much
>>>>> cleaner architecturally, then I don't see why we should merge a stop-gap
>>>>> solution that we'll need to then support indefinitely.
>>>>>
>>>>> We are talking about upstreaming functionality that xen already has, right?
>>>>> So there's no time to market concern, whoever wants a solution today
>>>>> has it.  Why not do it in the cleanest possible way?
>>>>>
>>>>
>>>>
>>>> --
>>>> Ross Philipson
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
>>>
>>
>>
>> --
>> Ross Philipson
>
>

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 01/07/2014 19:39, Ross Philipson ha scritto:
>
> We do IGD pass-through in our project (XenClient). The patches
> originally came from our project. We surface the same ISA bridge and
> have never had activation issues on any version of Widows from XP to
> Win8. We do not normally run server platforms so I can't say for sure
> there.

The problem is not activation, the problem is that the patches are 
making assumptions on the driver and the firmware that might work today 
but are IMHO just not sane.

I would have no problem with a clean patchset that adds a new machine 
type and doesn't touch code in "-M pc", but it looks like mst disagrees. 
  Ultimately, if a patchset is too hacky for upstream, you can include 
it in your downstream XenClient (and XenServer) QEMU branch.  It happens.

Paolo

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 01/07/2014 19:39, Ross Philipson ha scritto:
>
> We do IGD pass-through in our project (XenClient). The patches
> originally came from our project. We surface the same ISA bridge and
> have never had activation issues on any version of Widows from XP to
> Win8. We do not normally run server platforms so I can't say for sure
> there.

The problem is not activation, the problem is that the patches are 
making assumptions on the driver and the firmware that might work today 
but are IMHO just not sane.

I would have no problem with a clean patchset that adds a new machine 
type and doesn't touch code in "-M pc", but it looks like mst disagrees. 
  Ultimately, if a patchset is too hacky for upstream, you can include 
it in your downstream XenClient (and XenServer) QEMU branch.  It happens.

Paolo

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> Il 01/07/2014 19:39, Ross Philipson ha scritto:
> >
> >We do IGD pass-through in our project (XenClient). The patches
> >originally came from our project. We surface the same ISA bridge and
> >have never had activation issues on any version of Widows from XP to
> >Win8. We do not normally run server platforms so I can't say for sure
> >there.
> 
> The problem is not activation, the problem is that the patches are making
> assumptions on the driver and the firmware that might work today but are
> IMHO just not sane.
> 
> I would have no problem with a clean patchset that adds a new machine type
> and doesn't touch code in "-M pc", but it looks like mst disagrees.
> Ultimately, if a patchset is too hacky for upstream, you can include it in
> your downstream XenClient (and XenServer) QEMU branch.  It happens.

And then this discussion will come back again in a year when folks
rebase and ask: Why hasn't this been done upstream.

Then the discussion resumes ..

With this long thread I lost a bit context about the challenges
that exists. But let me try summarizing it here - which will hopefully
get some consensus.

1). Fix IGD hardware to not use Southbridge magic addresses.
    We can moan and moan but I doubt it is going to change.

2). Since we need the Southbridge magic addresses, we can expose
    an bridge. [I think everybody agrees that we need to do
    that since 1) is no go).

3). What kind of bridge. We can do:

     a) Two bridges - one 'passthrough' and the legacy ISA bridge
        that QEMU emulates. Both Linux and Windows are OK with
        two bridges (even thought it is pretty weird).

     b) One bridge - the one that QEMU emulates - and lets emulate
        more of the registers (by emulate - I mean for some get the
        data from the real hardware).

           b1). We can't use the legacy because the registers are
                above 256 (is that correct? Did I miss something?)

           b2)  We would need to use the Q35.
                b2a). If we need Q35, that needs to be exposed in
                      for Xen guests. That means exposing the 
                      MMCONFIG and restructing the E820 to fit that
                      in.
                      Problem:
                        - Migration is not working with Q35.
                          (But for v1 you wouldn't migrate, however
                           later hardware will surely have SR-IOV so
                           we will need to migrate).

                        - There are no developers who have an OK
                          from their management to focus on this.
                           (Potential solution: Poke Intel management to see
                            if they can get more developers on it)
                          

4). Code does a bit of sysfs that could use some refacturing with
    the KVM code.
    Problem: More time needed to do the code restructing.


Is that about correct?

What are folks timezones and the best days next week to talk about
this on either Google Hangout or the phone?

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> Il 01/07/2014 19:39, Ross Philipson ha scritto:
> >
> >We do IGD pass-through in our project (XenClient). The patches
> >originally came from our project. We surface the same ISA bridge and
> >have never had activation issues on any version of Widows from XP to
> >Win8. We do not normally run server platforms so I can't say for sure
> >there.
> 
> The problem is not activation, the problem is that the patches are making
> assumptions on the driver and the firmware that might work today but are
> IMHO just not sane.
> 
> I would have no problem with a clean patchset that adds a new machine type
> and doesn't touch code in "-M pc", but it looks like mst disagrees.
> Ultimately, if a patchset is too hacky for upstream, you can include it in
> your downstream XenClient (and XenServer) QEMU branch.  It happens.

And then this discussion will come back again in a year when folks
rebase and ask: Why hasn't this been done upstream.

Then the discussion resumes ..

With this long thread I lost a bit context about the challenges
that exists. But let me try summarizing it here - which will hopefully
get some consensus.

1). Fix IGD hardware to not use Southbridge magic addresses.
    We can moan and moan but I doubt it is going to change.

2). Since we need the Southbridge magic addresses, we can expose
    an bridge. [I think everybody agrees that we need to do
    that since 1) is no go).

3). What kind of bridge. We can do:

     a) Two bridges - one 'passthrough' and the legacy ISA bridge
        that QEMU emulates. Both Linux and Windows are OK with
        two bridges (even thought it is pretty weird).

     b) One bridge - the one that QEMU emulates - and lets emulate
        more of the registers (by emulate - I mean for some get the
        data from the real hardware).

           b1). We can't use the legacy because the registers are
                above 256 (is that correct? Did I miss something?)

           b2)  We would need to use the Q35.
                b2a). If we need Q35, that needs to be exposed in
                      for Xen guests. That means exposing the 
                      MMCONFIG and restructing the E820 to fit that
                      in.
                      Problem:
                        - Migration is not working with Q35.
                          (But for v1 you wouldn't migrate, however
                           later hardware will surely have SR-IOV so
                           we will need to migrate).

                        - There are no developers who have an OK
                          from their management to focus on this.
                           (Potential solution: Poke Intel management to see
                            if they can get more developers on it)
                          

4). Code does a bit of sysfs that could use some refacturing with
    the KVM code.
    Problem: More time needed to do the code restructing.


Is that about correct?

What are folks timezones and the best days next week to talk about
this on either Google Hangout or the phone?

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Stefano Stabellini]

On Wed, 2 Jul 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > >
> > >We do IGD pass-through in our project (XenClient). The patches
> > >originally came from our project. We surface the same ISA bridge and
> > >have never had activation issues on any version of Widows from XP to
> > >Win8. We do not normally run server platforms so I can't say for sure
> > >there.
> > 
> > The problem is not activation, the problem is that the patches are making
> > assumptions on the driver and the firmware that might work today but are
> > IMHO just not sane.
> > 
> > I would have no problem with a clean patchset that adds a new machine type
> > and doesn't touch code in "-M pc", but it looks like mst disagrees.
> > Ultimately, if a patchset is too hacky for upstream, you can include it in
> > your downstream XenClient (and XenServer) QEMU branch.  It happens.
> 
> And then this discussion will come back again in a year when folks
> rebase and ask: Why hasn't this been done upstream.
> 
> Then the discussion resumes ..
> 
> With this long thread I lost a bit context about the challenges
> that exists. But let me try summarizing it here - which will hopefully
> get some consensus.
> 
> 1). Fix IGD hardware to not use Southbridge magic addresses.
>     We can moan and moan but I doubt it is going to change.
> 
> 2). Since we need the Southbridge magic addresses, we can expose
>     an bridge. [I think everybody agrees that we need to do
>     that since 1) is no go).
> 
> 3). What kind of bridge. We can do:
> 
>      a) Two bridges - one 'passthrough' and the legacy ISA bridge
>         that QEMU emulates. Both Linux and Windows are OK with
>         two bridges (even thought it is pretty weird).
> 
>      b) One bridge - the one that QEMU emulates - and lets emulate
>         more of the registers (by emulate - I mean for some get the
>         data from the real hardware).
> 
>            b1). We can't use the legacy because the registers are
>                 above 256 (is that correct? Did I miss something?)
> 
>            b2)  We would need to use the Q35.
>                 b2a). If we need Q35, that needs to be exposed in
>                       for Xen guests. That means exposing the 
>                       MMCONFIG and restructing the E820 to fit that
>                       in.
>                       Problem:
>                         - Migration is not working with Q35.
>                           (But for v1 you wouldn't migrate, however
>                            later hardware will surely have SR-IOV so
>                            we will need to migrate).
> 
>                         - There are no developers who have an OK
>                           from their management to focus on this.
>                            (Potential solution: Poke Intel management to see
>                             if they can get more developers on it)

- need to test compatibility with current Xen VM images


> 
> 4). Code does a bit of sysfs that could use some refacturing with
>     the KVM code.
>     Problem: More time needed to do the code restructing.
> 
> 
> Is that about correct?
> 
> What are folks timezones and the best days next week to talk about
> this on either Google Hangout or the phone?

UK timezone. Maybe Friday afternoon so that afterwards we can go have
enough beers to forget about all this.

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Stefano Stabellini]

On Wed, 2 Jul 2014, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > >
> > >We do IGD pass-through in our project (XenClient). The patches
> > >originally came from our project. We surface the same ISA bridge and
> > >have never had activation issues on any version of Widows from XP to
> > >Win8. We do not normally run server platforms so I can't say for sure
> > >there.
> > 
> > The problem is not activation, the problem is that the patches are making
> > assumptions on the driver and the firmware that might work today but are
> > IMHO just not sane.
> > 
> > I would have no problem with a clean patchset that adds a new machine type
> > and doesn't touch code in "-M pc", but it looks like mst disagrees.
> > Ultimately, if a patchset is too hacky for upstream, you can include it in
> > your downstream XenClient (and XenServer) QEMU branch.  It happens.
> 
> And then this discussion will come back again in a year when folks
> rebase and ask: Why hasn't this been done upstream.
> 
> Then the discussion resumes ..
> 
> With this long thread I lost a bit context about the challenges
> that exists. But let me try summarizing it here - which will hopefully
> get some consensus.
> 
> 1). Fix IGD hardware to not use Southbridge magic addresses.
>     We can moan and moan but I doubt it is going to change.
> 
> 2). Since we need the Southbridge magic addresses, we can expose
>     an bridge. [I think everybody agrees that we need to do
>     that since 1) is no go).
> 
> 3). What kind of bridge. We can do:
> 
>      a) Two bridges - one 'passthrough' and the legacy ISA bridge
>         that QEMU emulates. Both Linux and Windows are OK with
>         two bridges (even thought it is pretty weird).
> 
>      b) One bridge - the one that QEMU emulates - and lets emulate
>         more of the registers (by emulate - I mean for some get the
>         data from the real hardware).
> 
>            b1). We can't use the legacy because the registers are
>                 above 256 (is that correct? Did I miss something?)
> 
>            b2)  We would need to use the Q35.
>                 b2a). If we need Q35, that needs to be exposed in
>                       for Xen guests. That means exposing the 
>                       MMCONFIG and restructing the E820 to fit that
>                       in.
>                       Problem:
>                         - Migration is not working with Q35.
>                           (But for v1 you wouldn't migrate, however
>                            later hardware will surely have SR-IOV so
>                            we will need to migrate).
> 
>                         - There are no developers who have an OK
>                           from their management to focus on this.
>                            (Potential solution: Poke Intel management to see
>                             if they can get more developers on it)

- need to test compatibility with current Xen VM images


> 
> 4). Code does a bit of sysfs that could use some refacturing with
>     the KVM code.
>     Problem: More time needed to do the code restructing.
> 
> 
> Is that about correct?
> 
> What are folks timezones and the best days next week to talk about
> this on either Google Hangout or the phone?

UK timezone. Maybe Friday afternoon so that afterwards we can go have
enough beers to forget about all this.

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

>>
>> Is that about correct?
>>
>> What are folks timezones and the best days next week to talk about
>> this on either Google Hangout or the phone?
>
> UK timezone. Maybe Friday afternoon so that afterwards we can go have
> enough beers to forget about all this.
>

Is this determined formally?

I mean I can ask if someone in Intel can attend this talk, and then they 
maybe answer your questions for GFX, Linux native driver, Windows driver.

Tiejun

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

>>
>> Is that about correct?
>>
>> What are folks timezones and the best days next week to talk about
>> this on either Google Hangout or the phone?
>
> UK timezone. Maybe Friday afternoon so that afterwards we can go have
> enough beers to forget about all this.
>

Is this determined formally?

I mean I can ask if someone in Intel can attend this talk, and then they 
maybe answer your questions for GFX, Linux native driver, Windows driver.

Tiejun

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Thu, Jul 03, 2014 at 11:00:37AM +0800, Chen, Tiejun wrote:
> >>
> >>Is that about correct?
> >>
> >>What are folks timezones and the best days next week to talk about
> >>this on either Google Hangout or the phone?
> >
> >UK timezone. Maybe Friday afternoon so that afterwards we can go have
> >enough beers to forget about all this.
> >
> 
> Is this determined formally?

Not sure what you mean, but I am just polling times and days so we all
can talk.
> 
> I mean I can ask if someone in Intel can attend this talk, and then
> they maybe answer your questions for GFX, Linux native driver,
> Windows driver.

Yes of course. That would be fantastic!
> 
> Tiejun

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Thu, Jul 03, 2014 at 11:00:37AM +0800, Chen, Tiejun wrote:
> >>
> >>Is that about correct?
> >>
> >>What are folks timezones and the best days next week to talk about
> >>this on either Google Hangout or the phone?
> >
> >UK timezone. Maybe Friday afternoon so that afterwards we can go have
> >enough beers to forget about all this.
> >
> 
> Is this determined formally?

Not sure what you mean, but I am just polling times and days so we all
can talk.
> 
> I mean I can ask if someone in Intel can attend this talk, and then
> they maybe answer your questions for GFX, Linux native driver,
> Windows driver.

Yes of course. That would be fantastic!
> 
> Tiejun

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > >
> > >We do IGD pass-through in our project (XenClient). The patches
> > >originally came from our project. We surface the same ISA bridge and
> > >have never had activation issues on any version of Widows from XP to
> > >Win8. We do not normally run server platforms so I can't say for sure
> > >there.
> > 
> > The problem is not activation, the problem is that the patches are making
> > assumptions on the driver and the firmware that might work today but are
> > IMHO just not sane.
> > 
> > I would have no problem with a clean patchset that adds a new machine type
> > and doesn't touch code in "-M pc", but it looks like mst disagrees.
> > Ultimately, if a patchset is too hacky for upstream, you can include it in
> > your downstream XenClient (and XenServer) QEMU branch.  It happens.
> 
> And then this discussion will come back again in a year when folks
> rebase and ask: Why hasn't this been done upstream.
> 
> Then the discussion resumes ..
> 
> With this long thread I lost a bit context about the challenges
> that exists. But let me try summarizing it here - which will hopefully
> get some consensus.

Before I answer could you clarify please:
by Southbridge do you mean the PCH at slot 1f or the MCH at slot 0 or both?

> 1). Fix IGD hardware to not use Southbridge magic addresses.
>     We can moan and moan but I doubt it is going to change.
> 
> 2). Since we need the Southbridge magic addresses, we can expose
>     an bridge. [I think everybody agrees that we need to do
>     that since 1) is no go).
> 
> 3). What kind of bridge. We can do:
> 
>      a) Two bridges - one 'passthrough' and the legacy ISA bridge
>         that QEMU emulates. Both Linux and Windows are OK with
>         two bridges (even thought it is pretty weird).
> 
>      b) One bridge - the one that QEMU emulates - and lets emulate
>         more of the registers (by emulate - I mean for some get the
>         data from the real hardware).
> 
>            b1). We can't use the legacy because the registers are
>                 above 256 (is that correct? Did I miss something?)
> 
>            b2)  We would need to use the Q35.
>                 b2a). If we need Q35, that needs to be exposed in
>                       for Xen guests. That means exposing the 
>                       MMCONFIG and restructing the E820 to fit that
>                       in.
>                       Problem:
>                         - Migration is not working with Q35.
>                           (But for v1 you wouldn't migrate, however
>                            later hardware will surely have SR-IOV so
>                            we will need to migrate).
> 
>                         - There are no developers who have an OK
>                           from their management to focus on this.
>                            (Potential solution: Poke Intel management to see
>                             if they can get more developers on it)
>                           
> 
> 4). Code does a bit of sysfs that could use some refacturing with
>     the KVM code.
>     Problem: More time needed to do the code restructing.
> 
> 
> Is that about correct?
> 
> What are folks timezones and the best days next week to talk about
> this on either Google Hangout or the phone?

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > >
> > >We do IGD pass-through in our project (XenClient). The patches
> > >originally came from our project. We surface the same ISA bridge and
> > >have never had activation issues on any version of Widows from XP to
> > >Win8. We do not normally run server platforms so I can't say for sure
> > >there.
> > 
> > The problem is not activation, the problem is that the patches are making
> > assumptions on the driver and the firmware that might work today but are
> > IMHO just not sane.
> > 
> > I would have no problem with a clean patchset that adds a new machine type
> > and doesn't touch code in "-M pc", but it looks like mst disagrees.
> > Ultimately, if a patchset is too hacky for upstream, you can include it in
> > your downstream XenClient (and XenServer) QEMU branch.  It happens.
> 
> And then this discussion will come back again in a year when folks
> rebase and ask: Why hasn't this been done upstream.
> 
> Then the discussion resumes ..
> 
> With this long thread I lost a bit context about the challenges
> that exists. But let me try summarizing it here - which will hopefully
> get some consensus.

Before I answer could you clarify please:
by Southbridge do you mean the PCH at slot 1f or the MCH at slot 0 or both?

> 1). Fix IGD hardware to not use Southbridge magic addresses.
>     We can moan and moan but I doubt it is going to change.
> 
> 2). Since we need the Southbridge magic addresses, we can expose
>     an bridge. [I think everybody agrees that we need to do
>     that since 1) is no go).
> 
> 3). What kind of bridge. We can do:
> 
>      a) Two bridges - one 'passthrough' and the legacy ISA bridge
>         that QEMU emulates. Both Linux and Windows are OK with
>         two bridges (even thought it is pretty weird).
> 
>      b) One bridge - the one that QEMU emulates - and lets emulate
>         more of the registers (by emulate - I mean for some get the
>         data from the real hardware).
> 
>            b1). We can't use the legacy because the registers are
>                 above 256 (is that correct? Did I miss something?)
> 
>            b2)  We would need to use the Q35.
>                 b2a). If we need Q35, that needs to be exposed in
>                       for Xen guests. That means exposing the 
>                       MMCONFIG and restructing the E820 to fit that
>                       in.
>                       Problem:
>                         - Migration is not working with Q35.
>                           (But for v1 you wouldn't migrate, however
>                            later hardware will surely have SR-IOV so
>                            we will need to migrate).
> 
>                         - There are no developers who have an OK
>                           from their management to focus on this.
>                            (Potential solution: Poke Intel management to see
>                             if they can get more developers on it)
>                           
> 
> 4). Code does a bit of sysfs that could use some refacturing with
>     the KVM code.
>     Problem: More time needed to do the code restructing.
> 
> 
> Is that about correct?
> 
> What are folks timezones and the best days next week to talk about
> this on either Google Hangout or the phone?

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > > >
> > > >We do IGD pass-through in our project (XenClient). The patches
> > > >originally came from our project. We surface the same ISA bridge and
> > > >have never had activation issues on any version of Widows from XP to
> > > >Win8. We do not normally run server platforms so I can't say for sure
> > > >there.
> > > 
> > > The problem is not activation, the problem is that the patches are making
> > > assumptions on the driver and the firmware that might work today but are
> > > IMHO just not sane.
> > > 
> > > I would have no problem with a clean patchset that adds a new machine type
> > > and doesn't touch code in "-M pc", but it looks like mst disagrees.
> > > Ultimately, if a patchset is too hacky for upstream, you can include it in
> > > your downstream XenClient (and XenServer) QEMU branch.  It happens.
> > 
> > And then this discussion will come back again in a year when folks
> > rebase and ask: Why hasn't this been done upstream.
> > 
> > Then the discussion resumes ..
> > 
> > With this long thread I lost a bit context about the challenges
> > that exists. But let me try summarizing it here - which will hopefully
> > get some consensus.
> 
> Before I answer could you clarify please:
> by Southbridge do you mean the PCH at slot 1f or the MCH at slot 0 or both?

MCH slot. We read/write from this (see intel_setup_mchbar) from couple of
registers (0x44 and 0x48 if gen >= 4, otherwise 0x54). It is hard-coded
in the i915_get_bridge_dev (see ec2a4c3fdc8e82fe82a25d800e85c1ea06b74372)
as 0:0.0 BDF.

The PCH (does not matter where it sits) we only use the model:vendor id
to figure out the pch_type (see intel_detect_pch).

I don't see why that model:vendor_id can't be exposed via checking the
type of device:vendor_id of the IGD itself. CC-ing some Intel i915 authors.

So for the discussion here, when I say Southbridge I mean MCH.
> 
> > 1). Fix IGD hardware to not use Southbridge magic addresses.
> >     We can moan and moan but I doubt it is going to change.
> > 
> > 2). Since we need the Southbridge magic addresses, we can expose
> >     an bridge. [I think everybody agrees that we need to do
> >     that since 1) is no go).
> > 
> > 3). What kind of bridge. We can do:
> > 
> >      a) Two bridges - one 'passthrough' and the legacy ISA bridge
> >         that QEMU emulates. Both Linux and Windows are OK with
> >         two bridges (even thought it is pretty weird).
> > 
> >      b) One bridge - the one that QEMU emulates - and lets emulate
> >         more of the registers (by emulate - I mean for some get the
> >         data from the real hardware).
> > 
> >            b1). We can't use the legacy because the registers are
> >                 above 256 (is that correct? Did I miss something?)
> > 
> >            b2)  We would need to use the Q35.
> >                 b2a). If we need Q35, that needs to be exposed in
> >                       for Xen guests. That means exposing the 
> >                       MMCONFIG and restructing the E820 to fit that
> >                       in.
> >                       Problem:
> >                         - Migration is not working with Q35.
> >                           (But for v1 you wouldn't migrate, however
> >                            later hardware will surely have SR-IOV so
> >                            we will need to migrate).
> > 
> >                         - There are no developers who have an OK
> >                           from their management to focus on this.
> >                            (Potential solution: Poke Intel management to see
> >                             if they can get more developers on it)
> >                           
> > 
> > 4). Code does a bit of sysfs that could use some refacturing with
> >     the KVM code.
> >     Problem: More time needed to do the code restructing.
> > 
> > 
> > Is that about correct?
> > 
> > What are folks timezones and the best days next week to talk about
> > this on either Google Hangout or the phone?

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > > >
> > > >We do IGD pass-through in our project (XenClient). The patches
> > > >originally came from our project. We surface the same ISA bridge and
> > > >have never had activation issues on any version of Widows from XP to
> > > >Win8. We do not normally run server platforms so I can't say for sure
> > > >there.
> > > 
> > > The problem is not activation, the problem is that the patches are making
> > > assumptions on the driver and the firmware that might work today but are
> > > IMHO just not sane.
> > > 
> > > I would have no problem with a clean patchset that adds a new machine type
> > > and doesn't touch code in "-M pc", but it looks like mst disagrees.
> > > Ultimately, if a patchset is too hacky for upstream, you can include it in
> > > your downstream XenClient (and XenServer) QEMU branch.  It happens.
> > 
> > And then this discussion will come back again in a year when folks
> > rebase and ask: Why hasn't this been done upstream.
> > 
> > Then the discussion resumes ..
> > 
> > With this long thread I lost a bit context about the challenges
> > that exists. But let me try summarizing it here - which will hopefully
> > get some consensus.
> 
> Before I answer could you clarify please:
> by Southbridge do you mean the PCH at slot 1f or the MCH at slot 0 or both?

MCH slot. We read/write from this (see intel_setup_mchbar) from couple of
registers (0x44 and 0x48 if gen >= 4, otherwise 0x54). It is hard-coded
in the i915_get_bridge_dev (see ec2a4c3fdc8e82fe82a25d800e85c1ea06b74372)
as 0:0.0 BDF.

The PCH (does not matter where it sits) we only use the model:vendor id
to figure out the pch_type (see intel_detect_pch).

I don't see why that model:vendor_id can't be exposed via checking the
type of device:vendor_id of the IGD itself. CC-ing some Intel i915 authors.

So for the discussion here, when I say Southbridge I mean MCH.
> 
> > 1). Fix IGD hardware to not use Southbridge magic addresses.
> >     We can moan and moan but I doubt it is going to change.
> > 
> > 2). Since we need the Southbridge magic addresses, we can expose
> >     an bridge. [I think everybody agrees that we need to do
> >     that since 1) is no go).
> > 
> > 3). What kind of bridge. We can do:
> > 
> >      a) Two bridges - one 'passthrough' and the legacy ISA bridge
> >         that QEMU emulates. Both Linux and Windows are OK with
> >         two bridges (even thought it is pretty weird).
> > 
> >      b) One bridge - the one that QEMU emulates - and lets emulate
> >         more of the registers (by emulate - I mean for some get the
> >         data from the real hardware).
> > 
> >            b1). We can't use the legacy because the registers are
> >                 above 256 (is that correct? Did I miss something?)
> > 
> >            b2)  We would need to use the Q35.
> >                 b2a). If we need Q35, that needs to be exposed in
> >                       for Xen guests. That means exposing the 
> >                       MMCONFIG and restructing the E820 to fit that
> >                       in.
> >                       Problem:
> >                         - Migration is not working with Q35.
> >                           (But for v1 you wouldn't migrate, however
> >                            later hardware will surely have SR-IOV so
> >                            we will need to migrate).
> > 
> >                         - There are no developers who have an OK
> >                           from their management to focus on this.
> >                            (Potential solution: Poke Intel management to see
> >                             if they can get more developers on it)
> >                           
> > 
> > 4). Code does a bit of sysfs that could use some refacturing with
> >     the KVM code.
> >     Problem: More time needed to do the code restructing.
> > 
> > 
> > Is that about correct?
> > 
> > What are folks timezones and the best days next week to talk about
> > this on either Google Hangout or the phone?

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 12:05:27PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > > > >
> > > > >We do IGD pass-through in our project (XenClient). The patches
> > > > >originally came from our project. We surface the same ISA bridge and
> > > > >have never had activation issues on any version of Widows from XP to
> > > > >Win8. We do not normally run server platforms so I can't say for sure
> > > > >there.
> > > > 
> > > > The problem is not activation, the problem is that the patches are making
> > > > assumptions on the driver and the firmware that might work today but are
> > > > IMHO just not sane.
> > > > 
> > > > I would have no problem with a clean patchset that adds a new machine type
> > > > and doesn't touch code in "-M pc", but it looks like mst disagrees.
> > > > Ultimately, if a patchset is too hacky for upstream, you can include it in
> > > > your downstream XenClient (and XenServer) QEMU branch.  It happens.
> > > 
> > > And then this discussion will come back again in a year when folks
> > > rebase and ask: Why hasn't this been done upstream.
> > > 
> > > Then the discussion resumes ..
> > > 
> > > With this long thread I lost a bit context about the challenges
> > > that exists. But let me try summarizing it here - which will hopefully
> > > get some consensus.
> > 
> > Before I answer could you clarify please:
> > by Southbridge do you mean the PCH at slot 1f or the MCH at slot 0 or both?
> 
> MCH slot. We read/write from this (see intel_setup_mchbar) from couple of
> registers (0x44 and 0x48 if gen >= 4, otherwise 0x54). It is hard-coded
> in the i915_get_bridge_dev (see ec2a4c3fdc8e82fe82a25d800e85c1ea06b74372)
> as 0:0.0 BDF.
> 
> The PCH (does not matter where it sits) we only use the model:vendor id
> to figure out the pch_type (see intel_detect_pch).
> 
> I don't see why that model:vendor_id can't be exposed via checking the
> type of device:vendor_id of the IGD itself. CC-ing some Intel i915 authors.
> 
> So for the discussion here, when I say Southbridge I mean MCH.

OK so PIIX spec says:

0x10-4F reserved.

So far so good, it is likely harmless to stick something at 0x44 and
0x48 most guests will very likely just keep ticking.

0x54-0x57 deal with RAM though.

Maybe we can just stick to emulating gen >= 4 for now:
detect it on host and fail assignment.
How old is gen 4?





> > 
> > > 1). Fix IGD hardware to not use Southbridge magic addresses.
> > >     We can moan and moan but I doubt it is going to change.
> > > 
> > > 2). Since we need the Southbridge magic addresses, we can expose
> > >     an bridge. [I think everybody agrees that we need to do
> > >     that since 1) is no go).
> > > 
> > > 3). What kind of bridge. We can do:
> > > 
> > >      a) Two bridges - one 'passthrough' and the legacy ISA bridge
> > >         that QEMU emulates. Both Linux and Windows are OK with
> > >         two bridges (even thought it is pretty weird).
> > > 
> > >      b) One bridge - the one that QEMU emulates - and lets emulate
> > >         more of the registers (by emulate - I mean for some get the
> > >         data from the real hardware).
> > > 
> > >            b1). We can't use the legacy because the registers are
> > >                 above 256 (is that correct? Did I miss something?)
> > > 
> > >            b2)  We would need to use the Q35.
> > >                 b2a). If we need Q35, that needs to be exposed in
> > >                       for Xen guests. That means exposing the 
> > >                       MMCONFIG and restructing the E820 to fit that
> > >                       in.
> > >                       Problem:
> > >                         - Migration is not working with Q35.
> > >                           (But for v1 you wouldn't migrate, however
> > >                            later hardware will surely have SR-IOV so
> > >                            we will need to migrate).
> > > 
> > >                         - There are no developers who have an OK
> > >                           from their management to focus on this.
> > >                            (Potential solution: Poke Intel management to see
> > >                             if they can get more developers on it)
> > >                           
> > > 
> > > 4). Code does a bit of sysfs that could use some refacturing with
> > >     the KVM code.
> > >     Problem: More time needed to do the code restructing.
> > > 
> > > 
> > > Is that about correct?
> > > 
> > > What are folks timezones and the best days next week to talk about
> > > this on either Google Hangout or the phone?

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 12:05:27PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > > > >
> > > > >We do IGD pass-through in our project (XenClient). The patches
> > > > >originally came from our project. We surface the same ISA bridge and
> > > > >have never had activation issues on any version of Widows from XP to
> > > > >Win8. We do not normally run server platforms so I can't say for sure
> > > > >there.
> > > > 
> > > > The problem is not activation, the problem is that the patches are making
> > > > assumptions on the driver and the firmware that might work today but are
> > > > IMHO just not sane.
> > > > 
> > > > I would have no problem with a clean patchset that adds a new machine type
> > > > and doesn't touch code in "-M pc", but it looks like mst disagrees.
> > > > Ultimately, if a patchset is too hacky for upstream, you can include it in
> > > > your downstream XenClient (and XenServer) QEMU branch.  It happens.
> > > 
> > > And then this discussion will come back again in a year when folks
> > > rebase and ask: Why hasn't this been done upstream.
> > > 
> > > Then the discussion resumes ..
> > > 
> > > With this long thread I lost a bit context about the challenges
> > > that exists. But let me try summarizing it here - which will hopefully
> > > get some consensus.
> > 
> > Before I answer could you clarify please:
> > by Southbridge do you mean the PCH at slot 1f or the MCH at slot 0 or both?
> 
> MCH slot. We read/write from this (see intel_setup_mchbar) from couple of
> registers (0x44 and 0x48 if gen >= 4, otherwise 0x54). It is hard-coded
> in the i915_get_bridge_dev (see ec2a4c3fdc8e82fe82a25d800e85c1ea06b74372)
> as 0:0.0 BDF.
> 
> The PCH (does not matter where it sits) we only use the model:vendor id
> to figure out the pch_type (see intel_detect_pch).
> 
> I don't see why that model:vendor_id can't be exposed via checking the
> type of device:vendor_id of the IGD itself. CC-ing some Intel i915 authors.
> 
> So for the discussion here, when I say Southbridge I mean MCH.

OK so PIIX spec says:

0x10-4F reserved.

So far so good, it is likely harmless to stick something at 0x44 and
0x48 most guests will very likely just keep ticking.

0x54-0x57 deal with RAM though.

Maybe we can just stick to emulating gen >= 4 for now:
detect it on host and fail assignment.
How old is gen 4?





> > 
> > > 1). Fix IGD hardware to not use Southbridge magic addresses.
> > >     We can moan and moan but I doubt it is going to change.
> > > 
> > > 2). Since we need the Southbridge magic addresses, we can expose
> > >     an bridge. [I think everybody agrees that we need to do
> > >     that since 1) is no go).
> > > 
> > > 3). What kind of bridge. We can do:
> > > 
> > >      a) Two bridges - one 'passthrough' and the legacy ISA bridge
> > >         that QEMU emulates. Both Linux and Windows are OK with
> > >         two bridges (even thought it is pretty weird).
> > > 
> > >      b) One bridge - the one that QEMU emulates - and lets emulate
> > >         more of the registers (by emulate - I mean for some get the
> > >         data from the real hardware).
> > > 
> > >            b1). We can't use the legacy because the registers are
> > >                 above 256 (is that correct? Did I miss something?)
> > > 
> > >            b2)  We would need to use the Q35.
> > >                 b2a). If we need Q35, that needs to be exposed in
> > >                       for Xen guests. That means exposing the 
> > >                       MMCONFIG and restructing the E820 to fit that
> > >                       in.
> > >                       Problem:
> > >                         - Migration is not working with Q35.
> > >                           (But for v1 you wouldn't migrate, however
> > >                            later hardware will surely have SR-IOV so
> > >                            we will need to migrate).
> > > 
> > >                         - There are no developers who have an OK
> > >                           from their management to focus on this.
> > >                            (Potential solution: Poke Intel management to see
> > >                             if they can get more developers on it)
> > >                           
> > > 
> > > 4). Code does a bit of sysfs that could use some refacturing with
> > >     the KVM code.
> > >     Problem: More time needed to do the code restructing.
> > > 
> > > 
> > > Is that about correct?
> > > 
> > > What are folks timezones and the best days next week to talk about
> > > this on either Google Hangout or the phone?

[Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> With this long thread I lost a bit context about the challenges
> that exists. But let me try summarizing it here - which will hopefully
> get some consensus.
>
> 1). Fix IGD hardware to not use Southbridge magic addresses.
>     We can moan and moan but I doubt it is going to change.

There are two problems:

- Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses

- Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions 
of the driver identify it by class, some versions identify it by slot 
(1f.0).

To solve the first, make a new machine type, PIIX4-based, and pass 
through the registers you need.  The patch must document _exactly_ why 
the registers are safe to pass.  If they are not reserved on PIIX4, the 
patch must document what the same offsets mean on PIIX4, and why it's 
sensible to assume that firmware for virtual machine will not read/write 
them.  Bonus point for also documenting the same for Q35.

Regarding the second, fixing IGD hardware to not rely on chipset magic 
is a no-go, I agree.  I disagree that it's a no-go to define a 
"backdoor" that lets a hypervisor pass the right information to the 
driver without hacking the chipset device model.

The hardware folks would have to give us a place for a pair of registers 
(something like data/address), and a bit somewhere else that would be 
always 0 on hardware and always 1 if the hypervisor is implementing the 
pair of registers.  This is similar to CPUID, which has the HYPERVISOR 
bit + hypervisor-defined leaves at 0x40000000.

The data/address pair could be in a BAR, in configuration space, in the 
low VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in 
the same place or somewhere else---again, whatever is convenient for the 
hardware folks.  We just need *one bit* that is known-zero on all 
hardware, and 8 bytes in a reserved area.  I don't think it's too hard 
to find this space, and I really, really would like Intel to follow up 
on a paravirtualized backdoor.

That said, we have the problem of existing guests, so I agree something 
else is needed.

>      a) Two bridges - one 'passthrough' and the legacy ISA bridge
>         that QEMU emulates. Both Linux and Windows are OK with
>         two bridges (even thought it is pretty weird).

This is pretty much the only solution for existing Linux guests that 
look up the southbridge by class.

The proposed solution here is to define a new "pci stub" device in QEMU 
that lets you define a do-nothing device with your desired vendor ID, 
device ID, class and optionally subsystem IDs.

The new machine type (the one that instantiates the special 
IGD-passthrough-enabled northbridge) can then instantiate this stub 
device at 1f.0 with the desired vendor ID, device ID and class ID.

If we cannot get the paravirtualized backdoor, it would also make sense to:

- have drivers standardize on a single way to probe the southbridge

- make this be neither by class (because the firmware wants to 
distinguish the actual ISA bridge from the stub, and it can do so by 
looking up the class), nor by slot (because this conflicts with the Q35 
chipset model that has the southbridge at 1f.0).

mst's proposal was to probe by subsystem id.  I'm not sure I understood 
the details exactly, but I trust him. :)  However, in case it wasn't 
clear I think a paravirtualized backdoor would still be better.

>      b) One bridge - the one that QEMU emulates - and lets emulate
>         more of the registers (by emulate - I mean for some get the
>         data from the real hardware).
>
>            b1). We can't use the legacy because the registers are
>                 above 256 (is that correct? Did I miss something?)

As I understand it, mst brought up Q35 because the northbridge 
configuration space layout might be more similar to what the driver 
expects than for PIIX4.  But I don't think anyone really said whether 
this is true or false.

I think Q35 is absolutely not a requirement for IGD passthrough, 
especially until this statement is either proved or disproved.

> 4). Code does a bit of sysfs that could use some refacturing with
>     the KVM code.
>     Problem: More time needed to do the code restructing.

FWIW, I don't really care about code sharing with KVM.  That's a 
separate problem and it's not necessary to bring it up and make waters 
even more muddy.

Paolo

ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> With this long thread I lost a bit context about the challenges
> that exists. But let me try summarizing it here - which will hopefully
> get some consensus.
>
> 1). Fix IGD hardware to not use Southbridge magic addresses.
>     We can moan and moan but I doubt it is going to change.

There are two problems:

- Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses

- Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions 
of the driver identify it by class, some versions identify it by slot 
(1f.0).

To solve the first, make a new machine type, PIIX4-based, and pass 
through the registers you need.  The patch must document _exactly_ why 
the registers are safe to pass.  If they are not reserved on PIIX4, the 
patch must document what the same offsets mean on PIIX4, and why it's 
sensible to assume that firmware for virtual machine will not read/write 
them.  Bonus point for also documenting the same for Q35.

Regarding the second, fixing IGD hardware to not rely on chipset magic 
is a no-go, I agree.  I disagree that it's a no-go to define a 
"backdoor" that lets a hypervisor pass the right information to the 
driver without hacking the chipset device model.

The hardware folks would have to give us a place for a pair of registers 
(something like data/address), and a bit somewhere else that would be 
always 0 on hardware and always 1 if the hypervisor is implementing the 
pair of registers.  This is similar to CPUID, which has the HYPERVISOR 
bit + hypervisor-defined leaves at 0x40000000.

The data/address pair could be in a BAR, in configuration space, in the 
low VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in 
the same place or somewhere else---again, whatever is convenient for the 
hardware folks.  We just need *one bit* that is known-zero on all 
hardware, and 8 bytes in a reserved area.  I don't think it's too hard 
to find this space, and I really, really would like Intel to follow up 
on a paravirtualized backdoor.

That said, we have the problem of existing guests, so I agree something 
else is needed.

>      a) Two bridges - one 'passthrough' and the legacy ISA bridge
>         that QEMU emulates. Both Linux and Windows are OK with
>         two bridges (even thought it is pretty weird).

This is pretty much the only solution for existing Linux guests that 
look up the southbridge by class.

The proposed solution here is to define a new "pci stub" device in QEMU 
that lets you define a do-nothing device with your desired vendor ID, 
device ID, class and optionally subsystem IDs.

The new machine type (the one that instantiates the special 
IGD-passthrough-enabled northbridge) can then instantiate this stub 
device at 1f.0 with the desired vendor ID, device ID and class ID.

If we cannot get the paravirtualized backdoor, it would also make sense to:

- have drivers standardize on a single way to probe the southbridge

- make this be neither by class (because the firmware wants to 
distinguish the actual ISA bridge from the stub, and it can do so by 
looking up the class), nor by slot (because this conflicts with the Q35 
chipset model that has the southbridge at 1f.0).

mst's proposal was to probe by subsystem id.  I'm not sure I understood 
the details exactly, but I trust him. :)  However, in case it wasn't 
clear I think a paravirtualized backdoor would still be better.

>      b) One bridge - the one that QEMU emulates - and lets emulate
>         more of the registers (by emulate - I mean for some get the
>         data from the real hardware).
>
>            b1). We can't use the legacy because the registers are
>                 above 256 (is that correct? Did I miss something?)

As I understand it, mst brought up Q35 because the northbridge 
configuration space layout might be more similar to what the driver 
expects than for PIIX4.  But I don't think anyone really said whether 
this is true or false.

I think Q35 is absolutely not a requirement for IGD passthrough, 
especially until this statement is either proved or disproved.

> 4). Code does a bit of sysfs that could use some refacturing with
>     the KVM code.
>     Problem: More time needed to do the code restructing.

FWIW, I don't really care about code sharing with KVM.  That's a 
separate problem and it's not necessary to bring it up and make waters 
even more muddy.

Paolo

Re: [Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> >With this long thread I lost a bit context about the challenges
> >that exists. But let me try summarizing it here - which will hopefully
> >get some consensus.
> >
> >1). Fix IGD hardware to not use Southbridge magic addresses.
> >    We can moan and moan but I doubt it is going to change.
> 
> There are two problems:
> 
> - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> 
> - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> the driver identify it by class, some versions identify it by slot (1f.0).
> 
> To solve the first, make a new machine type, PIIX4-based, and pass through
> the registers you need.  The patch must document _exactly_ why the registers
> are safe to pass.  If they are not reserved on PIIX4, the patch must
> document what the same offsets mean on PIIX4, and why it's sensible to
> assume that firmware for virtual machine will not read/write them.  Bonus
> point for also documenting the same for Q35.
> 
> Regarding the second, fixing IGD hardware to not rely on chipset magic is a
> no-go, I agree.  I disagree that it's a no-go to define a "backdoor" that
> lets a hypervisor pass the right information to the driver without hacking
> the chipset device model.
> 
> The hardware folks would have to give us a place for a pair of registers
> (something like data/address), and a bit somewhere else that would be always
> 0 on hardware and always 1 if the hypervisor is implementing the pair of
> registers.  This is similar to CPUID, which has the HYPERVISOR bit +
> hypervisor-defined leaves at 0x40000000.
> 
> The data/address pair could be in a BAR, in configuration space, in the low
> VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in the same
> place or somewhere else---again, whatever is convenient for the hardware
> folks.  We just need *one bit* that is known-zero on all hardware, and 8
> bytes in a reserved area.  I don't think it's too hard to find this space,
> and I really, really would like Intel to follow up on a paravirtualized
> backdoor.
> 
> That said, we have the problem of existing guests, so I agree something else
> is needed.
> 
> >     a) Two bridges - one 'passthrough' and the legacy ISA bridge
> >        that QEMU emulates. Both Linux and Windows are OK with
> >        two bridges (even thought it is pretty weird).
> 
> This is pretty much the only solution for existing Linux guests that look up
> the southbridge by class.
> 
> The proposed solution here is to define a new "pci stub" device in QEMU that
> lets you define a do-nothing device with your desired vendor ID, device ID,
> class and optionally subsystem IDs.
> 
> The new machine type (the one that instantiates the special
> IGD-passthrough-enabled northbridge) can then instantiate this stub device
> at 1f.0 with the desired vendor ID, device ID and class ID.
> 
> If we cannot get the paravirtualized backdoor, it would also make sense to:
> 
> - have drivers standardize on a single way to probe the southbridge
> 
> - make this be neither by class (because the firmware wants to distinguish
> the actual ISA bridge from the stub, and it can do so by looking up the
> class), nor by slot (because this conflicts with the Q35 chipset model that
> has the southbridge at 1f.0).
> 
> mst's proposal was to probe by subsystem id.  I'm not sure I understood the
> details exactly, but I trust him. :)  However, in case it wasn't clear I
> think a paravirtualized backdoor would still be better.

This was a paravirtualized idea actually.
Since ISA bridge is just needed for type
identification, stick this info in subsystem device id.
guest could do
	if subsystem vendor id == xen then
		get type from subsystem device id

does not address pci host registers.


> >     b) One bridge - the one that QEMU emulates - and lets emulate
> >        more of the registers (by emulate - I mean for some get the
> >        data from the real hardware).
> >
> >           b1). We can't use the legacy because the registers are
> >                above 256 (is that correct? Did I miss something?)
> 
> As I understand it, mst brought up Q35 because the northbridge configuration
> space layout might be more similar to what the driver expects than for
> PIIX4.  But I don't think anyone really said whether this is true or false.
> 
> I think Q35 is absolutely not a requirement for IGD passthrough, especially
> until this statement is either proved or disproved.


I kept saying MCH/PCH, people keep hearing Q35.

There is actually c:


c) the ideal solution, clearly superior to the above set of hacks (a)
and (b), is to actually emulate the chipsets that include the necessary
cards.

For example, if you want to support Lynxpoint cards,
emulate Z87.

Q35 codebase could be a good starting point in that work.


> >4). Code does a bit of sysfs that could use some refacturing with
> >    the KVM code.
> >    Problem: More time needed to do the code restructing.
> 
> FWIW, I don't really care about code sharing with KVM.  That's a separate
> problem and it's not necessary to bring it up and make waters even more
> muddy.
> 
> Paolo

I agree here.
I would like to see everything passed to these fake devices through
properties though.
xen could populate these properties from sysfs, kvm
could later do its own thing whatever it will be.

-- 
MST

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> >With this long thread I lost a bit context about the challenges
> >that exists. But let me try summarizing it here - which will hopefully
> >get some consensus.
> >
> >1). Fix IGD hardware to not use Southbridge magic addresses.
> >    We can moan and moan but I doubt it is going to change.
> 
> There are two problems:
> 
> - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> 
> - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> the driver identify it by class, some versions identify it by slot (1f.0).
> 
> To solve the first, make a new machine type, PIIX4-based, and pass through
> the registers you need.  The patch must document _exactly_ why the registers
> are safe to pass.  If they are not reserved on PIIX4, the patch must
> document what the same offsets mean on PIIX4, and why it's sensible to
> assume that firmware for virtual machine will not read/write them.  Bonus
> point for also documenting the same for Q35.
> 
> Regarding the second, fixing IGD hardware to not rely on chipset magic is a
> no-go, I agree.  I disagree that it's a no-go to define a "backdoor" that
> lets a hypervisor pass the right information to the driver without hacking
> the chipset device model.
> 
> The hardware folks would have to give us a place for a pair of registers
> (something like data/address), and a bit somewhere else that would be always
> 0 on hardware and always 1 if the hypervisor is implementing the pair of
> registers.  This is similar to CPUID, which has the HYPERVISOR bit +
> hypervisor-defined leaves at 0x40000000.
> 
> The data/address pair could be in a BAR, in configuration space, in the low
> VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in the same
> place or somewhere else---again, whatever is convenient for the hardware
> folks.  We just need *one bit* that is known-zero on all hardware, and 8
> bytes in a reserved area.  I don't think it's too hard to find this space,
> and I really, really would like Intel to follow up on a paravirtualized
> backdoor.
> 
> That said, we have the problem of existing guests, so I agree something else
> is needed.
> 
> >     a) Two bridges - one 'passthrough' and the legacy ISA bridge
> >        that QEMU emulates. Both Linux and Windows are OK with
> >        two bridges (even thought it is pretty weird).
> 
> This is pretty much the only solution for existing Linux guests that look up
> the southbridge by class.
> 
> The proposed solution here is to define a new "pci stub" device in QEMU that
> lets you define a do-nothing device with your desired vendor ID, device ID,
> class and optionally subsystem IDs.
> 
> The new machine type (the one that instantiates the special
> IGD-passthrough-enabled northbridge) can then instantiate this stub device
> at 1f.0 with the desired vendor ID, device ID and class ID.
> 
> If we cannot get the paravirtualized backdoor, it would also make sense to:
> 
> - have drivers standardize on a single way to probe the southbridge
> 
> - make this be neither by class (because the firmware wants to distinguish
> the actual ISA bridge from the stub, and it can do so by looking up the
> class), nor by slot (because this conflicts with the Q35 chipset model that
> has the southbridge at 1f.0).
> 
> mst's proposal was to probe by subsystem id.  I'm not sure I understood the
> details exactly, but I trust him. :)  However, in case it wasn't clear I
> think a paravirtualized backdoor would still be better.

This was a paravirtualized idea actually.
Since ISA bridge is just needed for type
identification, stick this info in subsystem device id.
guest could do
	if subsystem vendor id == xen then
		get type from subsystem device id

does not address pci host registers.


> >     b) One bridge - the one that QEMU emulates - and lets emulate
> >        more of the registers (by emulate - I mean for some get the
> >        data from the real hardware).
> >
> >           b1). We can't use the legacy because the registers are
> >                above 256 (is that correct? Did I miss something?)
> 
> As I understand it, mst brought up Q35 because the northbridge configuration
> space layout might be more similar to what the driver expects than for
> PIIX4.  But I don't think anyone really said whether this is true or false.
> 
> I think Q35 is absolutely not a requirement for IGD passthrough, especially
> until this statement is either proved or disproved.


I kept saying MCH/PCH, people keep hearing Q35.

There is actually c:


c) the ideal solution, clearly superior to the above set of hacks (a)
and (b), is to actually emulate the chipsets that include the necessary
cards.

For example, if you want to support Lynxpoint cards,
emulate Z87.

Q35 codebase could be a good starting point in that work.


> >4). Code does a bit of sysfs that could use some refacturing with
> >    the KVM code.
> >    Problem: More time needed to do the code restructing.
> 
> FWIW, I don't really care about code sharing with KVM.  That's a separate
> problem and it's not necessary to bring it up and make waters even more
> muddy.
> 
> Paolo

I agree here.
I would like to see everything passed to these fake devices through
properties though.
xen could populate these properties from sysfs, kvm
could later do its own thing whatever it will be.

-- 
MST

Re: [Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Alex Williamson]

On Wed, 2014-07-02 at 18:12 +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > >With this long thread I lost a bit context about the challenges
> > >that exists. But let me try summarizing it here - which will hopefully
> > >get some consensus.
> > >
> > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > >    We can moan and moan but I doubt it is going to change.
> > 
> > There are two problems:
> > 
> > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> > 
> > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > the driver identify it by class, some versions identify it by slot (1f.0).
> > 
> > To solve the first, make a new machine type, PIIX4-based, and pass through
> > the registers you need.  The patch must document _exactly_ why the registers
> > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > document what the same offsets mean on PIIX4, and why it's sensible to
> > assume that firmware for virtual machine will not read/write them.  Bonus
> > point for also documenting the same for Q35.
> > 
> > Regarding the second, fixing IGD hardware to not rely on chipset magic is a
> > no-go, I agree.  I disagree that it's a no-go to define a "backdoor" that
> > lets a hypervisor pass the right information to the driver without hacking
> > the chipset device model.
> > 
> > The hardware folks would have to give us a place for a pair of registers
> > (something like data/address), and a bit somewhere else that would be always
> > 0 on hardware and always 1 if the hypervisor is implementing the pair of
> > registers.  This is similar to CPUID, which has the HYPERVISOR bit +
> > hypervisor-defined leaves at 0x40000000.
> > 
> > The data/address pair could be in a BAR, in configuration space, in the low
> > VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in the same

This all looks like wishful thinking to me.  Just look though the i915
driver, hardware seems to arbitrarily change between chips and I expect
the drivers have a hard enough time supporting real hardware.  I would
like to see a concise document/comment from Intel listing which
registers, opregions, gtt mappings are required to be mirrored to the
guest and what needs write access through to the host per device
generation though.  The dependency on MCH/PCH IDs is only part of the
story.  Things like opregions and gtt mappings may require identity
mapping to the host and therefore require reserved memory regions and
guest access.  In order to provide that access, we need to know exactly
what we're providing access to and whether it compromises the host
isolation.

I do want to note that we should not add any dependency on VGA space if
we do go the path of a paravirt interface.  VGA routing is a nightmare
and for a VFIO path forward, I think we'll want to rely on legacy-free
UEFI drivers.

> > place or somewhere else---again, whatever is convenient for the hardware
> > folks.  We just need *one bit* that is known-zero on all hardware, and 8
> > bytes in a reserved area.  I don't think it's too hard to find this space,
> > and I really, really would like Intel to follow up on a paravirtualized
> > backdoor.
> > 
> > That said, we have the problem of existing guests, so I agree something else
> > is needed.
> > 
> > >     a) Two bridges - one 'passthrough' and the legacy ISA bridge
> > >        that QEMU emulates. Both Linux and Windows are OK with
> > >        two bridges (even thought it is pretty weird).
> > 
> > This is pretty much the only solution for existing Linux guests that look up
> > the southbridge by class.
> > 
> > The proposed solution here is to define a new "pci stub" device in QEMU that
> > lets you define a do-nothing device with your desired vendor ID, device ID,
> > class and optionally subsystem IDs.
> > 
> > The new machine type (the one that instantiates the special
> > IGD-passthrough-enabled northbridge) can then instantiate this stub device
> > at 1f.0 with the desired vendor ID, device ID and class ID.
> > 
> > If we cannot get the paravirtualized backdoor, it would also make sense to:
> > 
> > - have drivers standardize on a single way to probe the southbridge
> > 
> > - make this be neither by class (because the firmware wants to distinguish
> > the actual ISA bridge from the stub, and it can do so by looking up the
> > class), nor by slot (because this conflicts with the Q35 chipset model that
> > has the southbridge at 1f.0).
> > 
> > mst's proposal was to probe by subsystem id.  I'm not sure I understood the
> > details exactly, but I trust him. :)  However, in case it wasn't clear I
> > think a paravirtualized backdoor would still be better.
> 
> This was a paravirtualized idea actually.
> Since ISA bridge is just needed for type
> identification, stick this info in subsystem device id.
> guest could do
> 	if subsystem vendor id == xen then
> 		get type from subsystem device id
> 
> does not address pci host registers.
> 
> 
> > >     b) One bridge - the one that QEMU emulates - and lets emulate
> > >        more of the registers (by emulate - I mean for some get the
> > >        data from the real hardware).
> > >
> > >           b1). We can't use the legacy because the registers are
> > >                above 256 (is that correct? Did I miss something?)
> > 
> > As I understand it, mst brought up Q35 because the northbridge configuration
> > space layout might be more similar to what the driver expects than for
> > PIIX4.  But I don't think anyone really said whether this is true or false.
> > 
> > I think Q35 is absolutely not a requirement for IGD passthrough, especially
> > until this statement is either proved or disproved.
> 
> 
> I kept saying MCH/PCH, people keep hearing Q35.
> 
> There is actually c:
> 
> 
> c) the ideal solution, clearly superior to the above set of hacks (a)
> and (b), is to actually emulate the chipsets that include the necessary
> cards.
> 
> For example, if you want to support Lynxpoint cards,
> emulate Z87.
> 
> Q35 codebase could be a good starting point in that work.

This would only guarantee that QEMU never supports the latest hardware.
Also, is it really sufficient to have a virtual implementation of the
host chipset or do we also still need to populate registers in that
virtual chipset with host values?  At least we'd know that the
passthrough registers don't conflict, but that may be the only problem
it solves.

> > >4). Code does a bit of sysfs that could use some refacturing with
> > >    the KVM code.
> > >    Problem: More time needed to do the code restructing.
> > 
> > FWIW, I don't really care about code sharing with KVM.  That's a separate
> > problem and it's not necessary to bring it up and make waters even more
> > muddy.
> > 
> > Paolo
> 
> I agree here.
> I would like to see everything passed to these fake devices through
> properties though.
> xen could populate these properties from sysfs, kvm
> could later do its own thing whatever it will be.

I expect that a VFIO solution would also want to populate from sysfs.  I
think we'll need a new "device specific" VFIO region to provide access
to non-PCI resources of IGD, but I don't want that to include random
registers on other devices.  It would really throw a wrench in the
isolation of a guest if IGD passthrough were to require write access to
registers or config space on the MCH/PCH though.  Thanks,

Alex

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Alex Williamson]

On Wed, 2014-07-02 at 18:12 +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > >With this long thread I lost a bit context about the challenges
> > >that exists. But let me try summarizing it here - which will hopefully
> > >get some consensus.
> > >
> > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > >    We can moan and moan but I doubt it is going to change.
> > 
> > There are two problems:
> > 
> > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> > 
> > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > the driver identify it by class, some versions identify it by slot (1f.0).
> > 
> > To solve the first, make a new machine type, PIIX4-based, and pass through
> > the registers you need.  The patch must document _exactly_ why the registers
> > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > document what the same offsets mean on PIIX4, and why it's sensible to
> > assume that firmware for virtual machine will not read/write them.  Bonus
> > point for also documenting the same for Q35.
> > 
> > Regarding the second, fixing IGD hardware to not rely on chipset magic is a
> > no-go, I agree.  I disagree that it's a no-go to define a "backdoor" that
> > lets a hypervisor pass the right information to the driver without hacking
> > the chipset device model.
> > 
> > The hardware folks would have to give us a place for a pair of registers
> > (something like data/address), and a bit somewhere else that would be always
> > 0 on hardware and always 1 if the hypervisor is implementing the pair of
> > registers.  This is similar to CPUID, which has the HYPERVISOR bit +
> > hypervisor-defined leaves at 0x40000000.
> > 
> > The data/address pair could be in a BAR, in configuration space, in the low
> > VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in the same

This all looks like wishful thinking to me.  Just look though the i915
driver, hardware seems to arbitrarily change between chips and I expect
the drivers have a hard enough time supporting real hardware.  I would
like to see a concise document/comment from Intel listing which
registers, opregions, gtt mappings are required to be mirrored to the
guest and what needs write access through to the host per device
generation though.  The dependency on MCH/PCH IDs is only part of the
story.  Things like opregions and gtt mappings may require identity
mapping to the host and therefore require reserved memory regions and
guest access.  In order to provide that access, we need to know exactly
what we're providing access to and whether it compromises the host
isolation.

I do want to note that we should not add any dependency on VGA space if
we do go the path of a paravirt interface.  VGA routing is a nightmare
and for a VFIO path forward, I think we'll want to rely on legacy-free
UEFI drivers.

> > place or somewhere else---again, whatever is convenient for the hardware
> > folks.  We just need *one bit* that is known-zero on all hardware, and 8
> > bytes in a reserved area.  I don't think it's too hard to find this space,
> > and I really, really would like Intel to follow up on a paravirtualized
> > backdoor.
> > 
> > That said, we have the problem of existing guests, so I agree something else
> > is needed.
> > 
> > >     a) Two bridges - one 'passthrough' and the legacy ISA bridge
> > >        that QEMU emulates. Both Linux and Windows are OK with
> > >        two bridges (even thought it is pretty weird).
> > 
> > This is pretty much the only solution for existing Linux guests that look up
> > the southbridge by class.
> > 
> > The proposed solution here is to define a new "pci stub" device in QEMU that
> > lets you define a do-nothing device with your desired vendor ID, device ID,
> > class and optionally subsystem IDs.
> > 
> > The new machine type (the one that instantiates the special
> > IGD-passthrough-enabled northbridge) can then instantiate this stub device
> > at 1f.0 with the desired vendor ID, device ID and class ID.
> > 
> > If we cannot get the paravirtualized backdoor, it would also make sense to:
> > 
> > - have drivers standardize on a single way to probe the southbridge
> > 
> > - make this be neither by class (because the firmware wants to distinguish
> > the actual ISA bridge from the stub, and it can do so by looking up the
> > class), nor by slot (because this conflicts with the Q35 chipset model that
> > has the southbridge at 1f.0).
> > 
> > mst's proposal was to probe by subsystem id.  I'm not sure I understood the
> > details exactly, but I trust him. :)  However, in case it wasn't clear I
> > think a paravirtualized backdoor would still be better.
> 
> This was a paravirtualized idea actually.
> Since ISA bridge is just needed for type
> identification, stick this info in subsystem device id.
> guest could do
> 	if subsystem vendor id == xen then
> 		get type from subsystem device id
> 
> does not address pci host registers.
> 
> 
> > >     b) One bridge - the one that QEMU emulates - and lets emulate
> > >        more of the registers (by emulate - I mean for some get the
> > >        data from the real hardware).
> > >
> > >           b1). We can't use the legacy because the registers are
> > >                above 256 (is that correct? Did I miss something?)
> > 
> > As I understand it, mst brought up Q35 because the northbridge configuration
> > space layout might be more similar to what the driver expects than for
> > PIIX4.  But I don't think anyone really said whether this is true or false.
> > 
> > I think Q35 is absolutely not a requirement for IGD passthrough, especially
> > until this statement is either proved or disproved.
> 
> 
> I kept saying MCH/PCH, people keep hearing Q35.
> 
> There is actually c:
> 
> 
> c) the ideal solution, clearly superior to the above set of hacks (a)
> and (b), is to actually emulate the chipsets that include the necessary
> cards.
> 
> For example, if you want to support Lynxpoint cards,
> emulate Z87.
> 
> Q35 codebase could be a good starting point in that work.

This would only guarantee that QEMU never supports the latest hardware.
Also, is it really sufficient to have a virtual implementation of the
host chipset or do we also still need to populate registers in that
virtual chipset with host values?  At least we'd know that the
passthrough registers don't conflict, but that may be the only problem
it solves.

> > >4). Code does a bit of sysfs that could use some refacturing with
> > >    the KVM code.
> > >    Problem: More time needed to do the code restructing.
> > 
> > FWIW, I don't really care about code sharing with KVM.  That's a separate
> > problem and it's not necessary to bring it up and make waters even more
> > muddy.
> > 
> > Paolo
> 
> I agree here.
> I would like to see everything passed to these fake devices through
> properties though.
> xen could populate these properties from sysfs, kvm
> could later do its own thing whatever it will be.

I expect that a VFIO solution would also want to populate from sysfs.  I
think we'll need a new "device specific" VFIO region to provide access
to non-PCI resources of IGD, but I don't want that to include random
registers on other devices.  It would really throw a wrench in the
isolation of a guest if IGD passthrough were to require write access to
registers or config space on the MCH/PCH though.  Thanks,

Alex

Re: [Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> >With this long thread I lost a bit context about the challenges
> >that exists. But let me try summarizing it here - which will hopefully
> >get some consensus.
> >
> >1). Fix IGD hardware to not use Southbridge magic addresses.
> >    We can moan and moan but I doubt it is going to change.
> 
> There are two problems:
> 
> - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses

Right. So in  drivers/gpu/drm/i915/i915_dma.c:
1135 #define MCHBAR_I915 0x44                                                        
1136 #define MCHBAR_I965 0x48                     

1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
1152         if (INTEL_INFO(dev)->gen >= 4)                                          
1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                

and

1139 #define DEVEN_REG 0x54                                                          

1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
1205         } else {                                                                
1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
1207                 enabled = temp & 1;                                             
1208         }                                                
> 
> - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> the driver identify it by class, some versions identify it by slot (1f.0).

Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
which sets the pch_type based on :

 432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
 433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
 434                         dev_priv->pch_id = id;                                  
 435                                                                                 
 436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 

It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> 
> To solve the first, make a new machine type, PIIX4-based, and pass through
> the registers you need.  The patch must document _exactly_ why the registers
> are safe to pass.  If they are not reserved on PIIX4, the patch must
> document what the same offsets mean on PIIX4, and why it's sensible to
> assume that firmware for virtual machine will not read/write them.  Bonus
> point for also documenting the same for Q35.

OK. They look to be related to setting up an MBAR , but I don't understand
why it is needed. Hopefully some of the i915 folks CC-ed here can answer.

> 
> Regarding the second, fixing IGD hardware to not rely on chipset magic is a
> no-go, I agree.  I disagree that it's a no-go to define a "backdoor" that
> lets a hypervisor pass the right information to the driver without hacking
> the chipset device model.
> 
> The hardware folks would have to give us a place for a pair of registers
> (something like data/address), and a bit somewhere else that would be always
> 0 on hardware and always 1 if the hypervisor is implementing the pair of
> registers.  This is similar to CPUID, which has the HYPERVISOR bit +
> hypervisor-defined leaves at 0x40000000.
> 
> The data/address pair could be in a BAR, in configuration space, in the low
> VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in the same
> place or somewhere else---again, whatever is convenient for the hardware
> folks.  We just need *one bit* that is known-zero on all hardware, and 8
> bytes in a reserved area.  I don't think it's too hard to find this space,
> and I really, really would like Intel to follow up on a paravirtualized
> backdoor.
> 
> That said, we have the problem of existing guests, so I agree something else
> is needed.
> 
> >     a) Two bridges - one 'passthrough' and the legacy ISA bridge
> >        that QEMU emulates. Both Linux and Windows are OK with
> >        two bridges (even thought it is pretty weird).
> 
> This is pretty much the only solution for existing Linux guests that look up
> the southbridge by class.

Right.
> 
> The proposed solution here is to define a new "pci stub" device in QEMU that
> lets you define a do-nothing device with your desired vendor ID, device ID,
> class and optionally subsystem IDs.

<nods>
> 
> The new machine type (the one that instantiates the special
> IGD-passthrough-enabled northbridge) can then instantiate this stub device
> at 1f.0 with the desired vendor ID, device ID and class ID.

Which is kind of neat because you can use a different type of device ID with 
(say make it look like Ibex Peak) and pair it up with an IGD that is found
only on LynxPoint. Oh fun!
> 
> If we cannot get the paravirtualized backdoor, it would also make sense to:
> 
> - have drivers standardize on a single way to probe the southbridge
> 
> - make this be neither by class (because the firmware wants to distinguish
> the actual ISA bridge from the stub, and it can do so by looking up the
> class), nor by slot (because this conflicts with the Q35 chipset model that
> has the southbridge at 1f.0).
> 
> mst's proposal was to probe by subsystem id.  I'm not sure I understood the
> details exactly, but I trust him. :)  However, in case it wasn't clear I
> think a paravirtualized backdoor would still be better.

OK, like this:


diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 651e65e..03f2829 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_device *dev)
 			unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
 			dev_priv->pch_id = id;
 
+			if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
+				id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
 			if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
 				dev_priv->pch_type = PCH_IBX;
 				DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> 
> >     b) One bridge - the one that QEMU emulates - and lets emulate
> >        more of the registers (by emulate - I mean for some get the
> >        data from the real hardware).
> >
> >           b1). We can't use the legacy because the registers are
> >                above 256 (is that correct? Did I miss something?)
> 
> As I understand it, mst brought up Q35 because the northbridge configuration
> space layout might be more similar to what the driver expects than for
> PIIX4.  But I don't think anyone really said whether this is true or false.
> 
> I think Q35 is absolutely not a requirement for IGD passthrough, especially
> until this statement is either proved or disproved.

OK, so lets drop that.
> 
> >4). Code does a bit of sysfs that could use some refacturing with
> >    the KVM code.
> >    Problem: More time needed to do the code restructing.
> 
> FWIW, I don't really care about code sharing with KVM.  That's a separate
> problem and it's not necessary to bring it up and make waters even more
> muddy.
> 

OK, lets drop that for now.
> Paolo

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> >With this long thread I lost a bit context about the challenges
> >that exists. But let me try summarizing it here - which will hopefully
> >get some consensus.
> >
> >1). Fix IGD hardware to not use Southbridge magic addresses.
> >    We can moan and moan but I doubt it is going to change.
> 
> There are two problems:
> 
> - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses

Right. So in  drivers/gpu/drm/i915/i915_dma.c:
1135 #define MCHBAR_I915 0x44                                                        
1136 #define MCHBAR_I965 0x48                     

1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
1152         if (INTEL_INFO(dev)->gen >= 4)                                          
1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                

and

1139 #define DEVEN_REG 0x54                                                          

1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
1205         } else {                                                                
1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
1207                 enabled = temp & 1;                                             
1208         }                                                
> 
> - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> the driver identify it by class, some versions identify it by slot (1f.0).

Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
which sets the pch_type based on :

 432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
 433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
 434                         dev_priv->pch_id = id;                                  
 435                                                                                 
 436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 

It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> 
> To solve the first, make a new machine type, PIIX4-based, and pass through
> the registers you need.  The patch must document _exactly_ why the registers
> are safe to pass.  If they are not reserved on PIIX4, the patch must
> document what the same offsets mean on PIIX4, and why it's sensible to
> assume that firmware for virtual machine will not read/write them.  Bonus
> point for also documenting the same for Q35.

OK. They look to be related to setting up an MBAR , but I don't understand
why it is needed. Hopefully some of the i915 folks CC-ed here can answer.

> 
> Regarding the second, fixing IGD hardware to not rely on chipset magic is a
> no-go, I agree.  I disagree that it's a no-go to define a "backdoor" that
> lets a hypervisor pass the right information to the driver without hacking
> the chipset device model.
> 
> The hardware folks would have to give us a place for a pair of registers
> (something like data/address), and a bit somewhere else that would be always
> 0 on hardware and always 1 if the hypervisor is implementing the pair of
> registers.  This is similar to CPUID, which has the HYPERVISOR bit +
> hypervisor-defined leaves at 0x40000000.
> 
> The data/address pair could be in a BAR, in configuration space, in the low
> VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in the same
> place or somewhere else---again, whatever is convenient for the hardware
> folks.  We just need *one bit* that is known-zero on all hardware, and 8
> bytes in a reserved area.  I don't think it's too hard to find this space,
> and I really, really would like Intel to follow up on a paravirtualized
> backdoor.
> 
> That said, we have the problem of existing guests, so I agree something else
> is needed.
> 
> >     a) Two bridges - one 'passthrough' and the legacy ISA bridge
> >        that QEMU emulates. Both Linux and Windows are OK with
> >        two bridges (even thought it is pretty weird).
> 
> This is pretty much the only solution for existing Linux guests that look up
> the southbridge by class.

Right.
> 
> The proposed solution here is to define a new "pci stub" device in QEMU that
> lets you define a do-nothing device with your desired vendor ID, device ID,
> class and optionally subsystem IDs.

<nods>
> 
> The new machine type (the one that instantiates the special
> IGD-passthrough-enabled northbridge) can then instantiate this stub device
> at 1f.0 with the desired vendor ID, device ID and class ID.

Which is kind of neat because you can use a different type of device ID with 
(say make it look like Ibex Peak) and pair it up with an IGD that is found
only on LynxPoint. Oh fun!
> 
> If we cannot get the paravirtualized backdoor, it would also make sense to:
> 
> - have drivers standardize on a single way to probe the southbridge
> 
> - make this be neither by class (because the firmware wants to distinguish
> the actual ISA bridge from the stub, and it can do so by looking up the
> class), nor by slot (because this conflicts with the Q35 chipset model that
> has the southbridge at 1f.0).
> 
> mst's proposal was to probe by subsystem id.  I'm not sure I understood the
> details exactly, but I trust him. :)  However, in case it wasn't clear I
> think a paravirtualized backdoor would still be better.

OK, like this:


diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 651e65e..03f2829 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_device *dev)
 			unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
 			dev_priv->pch_id = id;
 
+			if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
+				id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
 			if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
 				dev_priv->pch_type = PCH_IBX;
 				DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> 
> >     b) One bridge - the one that QEMU emulates - and lets emulate
> >        more of the registers (by emulate - I mean for some get the
> >        data from the real hardware).
> >
> >           b1). We can't use the legacy because the registers are
> >                above 256 (is that correct? Did I miss something?)
> 
> As I understand it, mst brought up Q35 because the northbridge configuration
> space layout might be more similar to what the driver expects than for
> PIIX4.  But I don't think anyone really said whether this is true or false.
> 
> I think Q35 is absolutely not a requirement for IGD passthrough, especially
> until this statement is either proved or disproved.

OK, so lets drop that.
> 
> >4). Code does a bit of sysfs that could use some refacturing with
> >    the KVM code.
> >    Problem: More time needed to do the code restructing.
> 
> FWIW, I don't really care about code sharing with KVM.  That's a separate
> problem and it's not necessary to bring it up and make waters even more
> muddy.
> 

OK, lets drop that for now.
> Paolo

Re: [Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 02/07/2014 18:23, Konrad Rzeszutek Wilk ha scritto:
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 651e65e..03f2829 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_device *dev)
>  			unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  			dev_priv->pch_id = id;
>
> +			if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
> +				id = pch->device & INTEL_PCH_DEVICE_ID_MASK;

Actually you could look at *dev*'s subsystem IDs and skip the pch lookup 
completely.

Paolo

>  			if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>  				dev_priv->pch_type = PCH_IBX;
>  				DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
>> >

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 02/07/2014 18:23, Konrad Rzeszutek Wilk ha scritto:
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 651e65e..03f2829 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_device *dev)
>  			unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  			dev_priv->pch_id = id;
>
> +			if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
> +				id = pch->device & INTEL_PCH_DEVICE_ID_MASK;

Actually you could look at *dev*'s subsystem IDs and skip the pch lookup 
completely.

Paolo

>  			if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>  				dev_priv->pch_type = PCH_IBX;
>  				DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
>> >

Re: [Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > >With this long thread I lost a bit context about the challenges
> > >that exists. But let me try summarizing it here - which will hopefully
> > >get some consensus.
> > >
> > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > >    We can moan and moan but I doubt it is going to change.
> > 
> > There are two problems:
> > 
> > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> 
> Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> 1135 #define MCHBAR_I915 0x44                                                        
> 1136 #define MCHBAR_I965 0x48                     
> 
> 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> 
> and
> 
> 1139 #define DEVEN_REG 0x54                                                          
> 
> 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> 1205         } else {                                                                
> 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> 1207                 enabled = temp & 1;                                             
> 1208         }                                                
> > 
> > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > the driver identify it by class, some versions identify it by slot (1f.0).
> 
> Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> which sets the pch_type based on :
> 
>  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
>  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  434                         dev_priv->pch_id = id;                                  
>  435                                                                                 
>  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> 
> It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > 
> > To solve the first, make a new machine type, PIIX4-based, and pass through
> > the registers you need.  The patch must document _exactly_ why the registers
> > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > document what the same offsets mean on PIIX4, and why it's sensible to
> > assume that firmware for virtual machine will not read/write them.  Bonus
> > point for also documenting the same for Q35.
> 
> OK. They look to be related to setting up an MBAR , but I don't understand
> why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> 
> > 
> > Regarding the second, fixing IGD hardware to not rely on chipset magic is a
> > no-go, I agree.  I disagree that it's a no-go to define a "backdoor" that
> > lets a hypervisor pass the right information to the driver without hacking
> > the chipset device model.
> > 
> > The hardware folks would have to give us a place for a pair of registers
> > (something like data/address), and a bit somewhere else that would be always
> > 0 on hardware and always 1 if the hypervisor is implementing the pair of
> > registers.  This is similar to CPUID, which has the HYPERVISOR bit +
> > hypervisor-defined leaves at 0x40000000.
> > 
> > The data/address pair could be in a BAR, in configuration space, in the low
> > VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in the same
> > place or somewhere else---again, whatever is convenient for the hardware
> > folks.  We just need *one bit* that is known-zero on all hardware, and 8
> > bytes in a reserved area.  I don't think it's too hard to find this space,
> > and I really, really would like Intel to follow up on a paravirtualized
> > backdoor.
> > 
> > That said, we have the problem of existing guests, so I agree something else
> > is needed.
> > 
> > >     a) Two bridges - one 'passthrough' and the legacy ISA bridge
> > >        that QEMU emulates. Both Linux and Windows are OK with
> > >        two bridges (even thought it is pretty weird).
> > 
> > This is pretty much the only solution for existing Linux guests that look up
> > the southbridge by class.
> 
> Right.
> > 
> > The proposed solution here is to define a new "pci stub" device in QEMU that
> > lets you define a do-nothing device with your desired vendor ID, device ID,
> > class and optionally subsystem IDs.
> 
> <nods>
> > 
> > The new machine type (the one that instantiates the special
> > IGD-passthrough-enabled northbridge) can then instantiate this stub device
> > at 1f.0 with the desired vendor ID, device ID and class ID.
> 
> Which is kind of neat because you can use a different type of device ID with 
> (say make it look like Ibex Peak) and pair it up with an IGD that is found
> only on LynxPoint. Oh fun!
> > 
> > If we cannot get the paravirtualized backdoor, it would also make sense to:
> > 
> > - have drivers standardize on a single way to probe the southbridge
> > 
> > - make this be neither by class (because the firmware wants to distinguish
> > the actual ISA bridge from the stub, and it can do so by looking up the
> > class), nor by slot (because this conflicts with the Q35 chipset model that
> > has the southbridge at 1f.0).
> > 
> > mst's proposal was to probe by subsystem id.  I'm not sure I understood the
> > details exactly, but I trust him. :)  However, in case it wasn't clear I
> > think a paravirtualized backdoor would still be better.
> 
> OK, like this:
> 
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 651e65e..03f2829 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_device *dev)
>  			unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  			dev_priv->pch_id = id;
>  
> +			if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
> +				id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  			if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>  				dev_priv->pch_type = PCH_IBX;
>  				DRM_DEBUG_KMS("Found Ibex Peak PCH\n");

No!
The point is to avoid looking at PCH at all, only look at
the card itself.

> > 
> > >     b) One bridge - the one that QEMU emulates - and lets emulate
> > >        more of the registers (by emulate - I mean for some get the
> > >        data from the real hardware).
> > >
> > >           b1). We can't use the legacy because the registers are
> > >                above 256 (is that correct? Did I miss something?)
> > 
> > As I understand it, mst brought up Q35 because the northbridge configuration
> > space layout might be more similar to what the driver expects than for
> > PIIX4.  But I don't think anyone really said whether this is true or false.
> > 
> > I think Q35 is absolutely not a requirement for IGD passthrough, especially
> > until this statement is either proved or disproved.
> 
> OK, so lets drop that.
> > 
> > >4). Code does a bit of sysfs that could use some refacturing with
> > >    the KVM code.
> > >    Problem: More time needed to do the code restructing.
> > 
> > FWIW, I don't really care about code sharing with KVM.  That's a separate
> > problem and it's not necessary to bring it up and make waters even more
> > muddy.
> > 
> 
> OK, lets drop that for now.
> > Paolo

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > >With this long thread I lost a bit context about the challenges
> > >that exists. But let me try summarizing it here - which will hopefully
> > >get some consensus.
> > >
> > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > >    We can moan and moan but I doubt it is going to change.
> > 
> > There are two problems:
> > 
> > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> 
> Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> 1135 #define MCHBAR_I915 0x44                                                        
> 1136 #define MCHBAR_I965 0x48                     
> 
> 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> 
> and
> 
> 1139 #define DEVEN_REG 0x54                                                          
> 
> 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> 1205         } else {                                                                
> 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> 1207                 enabled = temp & 1;                                             
> 1208         }                                                
> > 
> > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > the driver identify it by class, some versions identify it by slot (1f.0).
> 
> Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> which sets the pch_type based on :
> 
>  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
>  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  434                         dev_priv->pch_id = id;                                  
>  435                                                                                 
>  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> 
> It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > 
> > To solve the first, make a new machine type, PIIX4-based, and pass through
> > the registers you need.  The patch must document _exactly_ why the registers
> > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > document what the same offsets mean on PIIX4, and why it's sensible to
> > assume that firmware for virtual machine will not read/write them.  Bonus
> > point for also documenting the same for Q35.
> 
> OK. They look to be related to setting up an MBAR , but I don't understand
> why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> 
> > 
> > Regarding the second, fixing IGD hardware to not rely on chipset magic is a
> > no-go, I agree.  I disagree that it's a no-go to define a "backdoor" that
> > lets a hypervisor pass the right information to the driver without hacking
> > the chipset device model.
> > 
> > The hardware folks would have to give us a place for a pair of registers
> > (something like data/address), and a bit somewhere else that would be always
> > 0 on hardware and always 1 if the hypervisor is implementing the pair of
> > registers.  This is similar to CPUID, which has the HYPERVISOR bit +
> > hypervisor-defined leaves at 0x40000000.
> > 
> > The data/address pair could be in a BAR, in configuration space, in the low
> > VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in the same
> > place or somewhere else---again, whatever is convenient for the hardware
> > folks.  We just need *one bit* that is known-zero on all hardware, and 8
> > bytes in a reserved area.  I don't think it's too hard to find this space,
> > and I really, really would like Intel to follow up on a paravirtualized
> > backdoor.
> > 
> > That said, we have the problem of existing guests, so I agree something else
> > is needed.
> > 
> > >     a) Two bridges - one 'passthrough' and the legacy ISA bridge
> > >        that QEMU emulates. Both Linux and Windows are OK with
> > >        two bridges (even thought it is pretty weird).
> > 
> > This is pretty much the only solution for existing Linux guests that look up
> > the southbridge by class.
> 
> Right.
> > 
> > The proposed solution here is to define a new "pci stub" device in QEMU that
> > lets you define a do-nothing device with your desired vendor ID, device ID,
> > class and optionally subsystem IDs.
> 
> <nods>
> > 
> > The new machine type (the one that instantiates the special
> > IGD-passthrough-enabled northbridge) can then instantiate this stub device
> > at 1f.0 with the desired vendor ID, device ID and class ID.
> 
> Which is kind of neat because you can use a different type of device ID with 
> (say make it look like Ibex Peak) and pair it up with an IGD that is found
> only on LynxPoint. Oh fun!
> > 
> > If we cannot get the paravirtualized backdoor, it would also make sense to:
> > 
> > - have drivers standardize on a single way to probe the southbridge
> > 
> > - make this be neither by class (because the firmware wants to distinguish
> > the actual ISA bridge from the stub, and it can do so by looking up the
> > class), nor by slot (because this conflicts with the Q35 chipset model that
> > has the southbridge at 1f.0).
> > 
> > mst's proposal was to probe by subsystem id.  I'm not sure I understood the
> > details exactly, but I trust him. :)  However, in case it wasn't clear I
> > think a paravirtualized backdoor would still be better.
> 
> OK, like this:
> 
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 651e65e..03f2829 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_device *dev)
>  			unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  			dev_priv->pch_id = id;
>  
> +			if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
> +				id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  			if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>  				dev_priv->pch_type = PCH_IBX;
>  				DRM_DEBUG_KMS("Found Ibex Peak PCH\n");

No!
The point is to avoid looking at PCH at all, only look at
the card itself.

> > 
> > >     b) One bridge - the one that QEMU emulates - and lets emulate
> > >        more of the registers (by emulate - I mean for some get the
> > >        data from the real hardware).
> > >
> > >           b1). We can't use the legacy because the registers are
> > >                above 256 (is that correct? Did I miss something?)
> > 
> > As I understand it, mst brought up Q35 because the northbridge configuration
> > space layout might be more similar to what the driver expects than for
> > PIIX4.  But I don't think anyone really said whether this is true or false.
> > 
> > I think Q35 is absolutely not a requirement for IGD passthrough, especially
> > until this statement is either proved or disproved.
> 
> OK, so lets drop that.
> > 
> > >4). Code does a bit of sysfs that could use some refacturing with
> > >    the KVM code.
> > >    Problem: More time needed to do the code restructing.
> > 
> > FWIW, I don't really care about code sharing with KVM.  That's a separate
> > problem and it's not necessary to bring it up and make waters even more
> > muddy.
> > 
> 
> OK, lets drop that for now.
> > Paolo

Re: [Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > >With this long thread I lost a bit context about the challenges
> > >that exists. But let me try summarizing it here - which will hopefully
> > >get some consensus.
> > >
> > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > >    We can moan and moan but I doubt it is going to change.
> > 
> > There are two problems:
> > 
> > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> 
> Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> 1135 #define MCHBAR_I915 0x44                                                        
> 1136 #define MCHBAR_I965 0x48                     
> 
> 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> 
> and
> 
> 1139 #define DEVEN_REG 0x54                                                          
> 
> 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> 1205         } else {                                                                
> 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> 1207                 enabled = temp & 1;                                             
> 1208         }                                                
> > 
> > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > the driver identify it by class, some versions identify it by slot (1f.0).
> 
> Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> which sets the pch_type based on :
> 
>  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
>  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  434                         dev_priv->pch_id = id;                                  
>  435                                                                                 
>  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> 
> It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > 
> > To solve the first, make a new machine type, PIIX4-based, and pass through
> > the registers you need.  The patch must document _exactly_ why the registers
> > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > document what the same offsets mean on PIIX4, and why it's sensible to
> > assume that firmware for virtual machine will not read/write them.  Bonus
> > point for also documenting the same for Q35.
> 
> OK. They look to be related to setting up an MBAR , but I don't understand
> why it is needed. Hopefully some of the i915 folks CC-ed here can answer.

In particular, I think setting up MBAR should move out of i915 and become
the bridge driver tweak on linux and windows.
It would then run on the priveledged host
and we won't need to deal with it in QEMU.


> > 
> > Regarding the second, fixing IGD hardware to not rely on chipset magic is a
> > no-go, I agree.  I disagree that it's a no-go to define a "backdoor" that
> > lets a hypervisor pass the right information to the driver without hacking
> > the chipset device model.
> > 
> > The hardware folks would have to give us a place for a pair of registers
> > (something like data/address), and a bit somewhere else that would be always
> > 0 on hardware and always 1 if the hypervisor is implementing the pair of
> > registers.  This is similar to CPUID, which has the HYPERVISOR bit +
> > hypervisor-defined leaves at 0x40000000.
> > 
> > The data/address pair could be in a BAR, in configuration space, in the low
> > VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in the same
> > place or somewhere else---again, whatever is convenient for the hardware
> > folks.  We just need *one bit* that is known-zero on all hardware, and 8
> > bytes in a reserved area.  I don't think it's too hard to find this space,
> > and I really, really would like Intel to follow up on a paravirtualized
> > backdoor.
> > 
> > That said, we have the problem of existing guests, so I agree something else
> > is needed.
> > 
> > >     a) Two bridges - one 'passthrough' and the legacy ISA bridge
> > >        that QEMU emulates. Both Linux and Windows are OK with
> > >        two bridges (even thought it is pretty weird).
> > 
> > This is pretty much the only solution for existing Linux guests that look up
> > the southbridge by class.
> 
> Right.
> > 
> > The proposed solution here is to define a new "pci stub" device in QEMU that
> > lets you define a do-nothing device with your desired vendor ID, device ID,
> > class and optionally subsystem IDs.
> 
> <nods>
> > 
> > The new machine type (the one that instantiates the special
> > IGD-passthrough-enabled northbridge) can then instantiate this stub device
> > at 1f.0 with the desired vendor ID, device ID and class ID.
> 
> Which is kind of neat because you can use a different type of device ID with 
> (say make it look like Ibex Peak) and pair it up with an IGD that is found
> only on LynxPoint. Oh fun!
> > 
> > If we cannot get the paravirtualized backdoor, it would also make sense to:
> > 
> > - have drivers standardize on a single way to probe the southbridge
> > 
> > - make this be neither by class (because the firmware wants to distinguish
> > the actual ISA bridge from the stub, and it can do so by looking up the
> > class), nor by slot (because this conflicts with the Q35 chipset model that
> > has the southbridge at 1f.0).
> > 
> > mst's proposal was to probe by subsystem id.  I'm not sure I understood the
> > details exactly, but I trust him. :)  However, in case it wasn't clear I
> > think a paravirtualized backdoor would still be better.
> 
> OK, like this:
> 
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 651e65e..03f2829 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_device *dev)
>  			unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  			dev_priv->pch_id = id;
>  
> +			if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
> +				id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  			if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>  				dev_priv->pch_type = PCH_IBX;
>  				DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> > 
> > >     b) One bridge - the one that QEMU emulates - and lets emulate
> > >        more of the registers (by emulate - I mean for some get the
> > >        data from the real hardware).
> > >
> > >           b1). We can't use the legacy because the registers are
> > >                above 256 (is that correct? Did I miss something?)
> > 
> > As I understand it, mst brought up Q35 because the northbridge configuration
> > space layout might be more similar to what the driver expects than for
> > PIIX4.  But I don't think anyone really said whether this is true or false.
> > 
> > I think Q35 is absolutely not a requirement for IGD passthrough, especially
> > until this statement is either proved or disproved.
> 
> OK, so lets drop that.
> > 
> > >4). Code does a bit of sysfs that could use some refacturing with
> > >    the KVM code.
> > >    Problem: More time needed to do the code restructing.
> > 
> > FWIW, I don't really care about code sharing with KVM.  That's a separate
> > problem and it's not necessary to bring it up and make waters even more
> > muddy.
> > 
> 
> OK, lets drop that for now.
> > Paolo

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > >With this long thread I lost a bit context about the challenges
> > >that exists. But let me try summarizing it here - which will hopefully
> > >get some consensus.
> > >
> > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > >    We can moan and moan but I doubt it is going to change.
> > 
> > There are two problems:
> > 
> > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> 
> Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> 1135 #define MCHBAR_I915 0x44                                                        
> 1136 #define MCHBAR_I965 0x48                     
> 
> 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> 
> and
> 
> 1139 #define DEVEN_REG 0x54                                                          
> 
> 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> 1205         } else {                                                                
> 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> 1207                 enabled = temp & 1;                                             
> 1208         }                                                
> > 
> > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > the driver identify it by class, some versions identify it by slot (1f.0).
> 
> Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> which sets the pch_type based on :
> 
>  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
>  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  434                         dev_priv->pch_id = id;                                  
>  435                                                                                 
>  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> 
> It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > 
> > To solve the first, make a new machine type, PIIX4-based, and pass through
> > the registers you need.  The patch must document _exactly_ why the registers
> > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > document what the same offsets mean on PIIX4, and why it's sensible to
> > assume that firmware for virtual machine will not read/write them.  Bonus
> > point for also documenting the same for Q35.
> 
> OK. They look to be related to setting up an MBAR , but I don't understand
> why it is needed. Hopefully some of the i915 folks CC-ed here can answer.

In particular, I think setting up MBAR should move out of i915 and become
the bridge driver tweak on linux and windows.
It would then run on the priveledged host
and we won't need to deal with it in QEMU.


> > 
> > Regarding the second, fixing IGD hardware to not rely on chipset magic is a
> > no-go, I agree.  I disagree that it's a no-go to define a "backdoor" that
> > lets a hypervisor pass the right information to the driver without hacking
> > the chipset device model.
> > 
> > The hardware folks would have to give us a place for a pair of registers
> > (something like data/address), and a bit somewhere else that would be always
> > 0 on hardware and always 1 if the hypervisor is implementing the pair of
> > registers.  This is similar to CPUID, which has the HYPERVISOR bit +
> > hypervisor-defined leaves at 0x40000000.
> > 
> > The data/address pair could be in a BAR, in configuration space, in the low
> > VGA ports at 0x3c0-0x3df, wherever.  The hypervisor bit can be in the same
> > place or somewhere else---again, whatever is convenient for the hardware
> > folks.  We just need *one bit* that is known-zero on all hardware, and 8
> > bytes in a reserved area.  I don't think it's too hard to find this space,
> > and I really, really would like Intel to follow up on a paravirtualized
> > backdoor.
> > 
> > That said, we have the problem of existing guests, so I agree something else
> > is needed.
> > 
> > >     a) Two bridges - one 'passthrough' and the legacy ISA bridge
> > >        that QEMU emulates. Both Linux and Windows are OK with
> > >        two bridges (even thought it is pretty weird).
> > 
> > This is pretty much the only solution for existing Linux guests that look up
> > the southbridge by class.
> 
> Right.
> > 
> > The proposed solution here is to define a new "pci stub" device in QEMU that
> > lets you define a do-nothing device with your desired vendor ID, device ID,
> > class and optionally subsystem IDs.
> 
> <nods>
> > 
> > The new machine type (the one that instantiates the special
> > IGD-passthrough-enabled northbridge) can then instantiate this stub device
> > at 1f.0 with the desired vendor ID, device ID and class ID.
> 
> Which is kind of neat because you can use a different type of device ID with 
> (say make it look like Ibex Peak) and pair it up with an IGD that is found
> only on LynxPoint. Oh fun!
> > 
> > If we cannot get the paravirtualized backdoor, it would also make sense to:
> > 
> > - have drivers standardize on a single way to probe the southbridge
> > 
> > - make this be neither by class (because the firmware wants to distinguish
> > the actual ISA bridge from the stub, and it can do so by looking up the
> > class), nor by slot (because this conflicts with the Q35 chipset model that
> > has the southbridge at 1f.0).
> > 
> > mst's proposal was to probe by subsystem id.  I'm not sure I understood the
> > details exactly, but I trust him. :)  However, in case it wasn't clear I
> > think a paravirtualized backdoor would still be better.
> 
> OK, like this:
> 
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 651e65e..03f2829 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_device *dev)
>  			unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  			dev_priv->pch_id = id;
>  
> +			if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
> +				id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>  			if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>  				dev_priv->pch_type = PCH_IBX;
>  				DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> > 
> > >     b) One bridge - the one that QEMU emulates - and lets emulate
> > >        more of the registers (by emulate - I mean for some get the
> > >        data from the real hardware).
> > >
> > >           b1). We can't use the legacy because the registers are
> > >                above 256 (is that correct? Did I miss something?)
> > 
> > As I understand it, mst brought up Q35 because the northbridge configuration
> > space layout might be more similar to what the driver expects than for
> > PIIX4.  But I don't think anyone really said whether this is true or false.
> > 
> > I think Q35 is absolutely not a requirement for IGD passthrough, especially
> > until this statement is either proved or disproved.
> 
> OK, so lets drop that.
> > 
> > >4). Code does a bit of sysfs that could use some refacturing with
> > >    the KVM code.
> > >    Problem: More time needed to do the code restructing.
> > 
> > FWIW, I don't really care about code sharing with KVM.  That's a separate
> > problem and it's not necessary to bring it up and make waters even more
> > muddy.
> > 
> 
> OK, lets drop that for now.
> > Paolo

Re: [Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > >With this long thread I lost a bit context about the challenges
> > > >that exists. But let me try summarizing it here - which will hopefully
> > > >get some consensus.
> > > >
> > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > >    We can moan and moan but I doubt it is going to change.
> > > 
> > > There are two problems:
> > > 
> > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> > 
> > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > 1135 #define MCHBAR_I915 0x44                                                        
> > 1136 #define MCHBAR_I965 0x48                     
> > 
> > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > 
> > and
> > 
> > 1139 #define DEVEN_REG 0x54                                                          
> > 
> > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > 1205         } else {                                                                
> > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > 1207                 enabled = temp & 1;                                             
> > 1208         }                                                
> > > 
> > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > > the driver identify it by class, some versions identify it by slot (1f.0).
> > 
> > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> > which sets the pch_type based on :
> > 
> >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >  434                         dev_priv->pch_id = id;                                  
> >  435                                                                                 
> >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > 
> > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > 
> > > To solve the first, make a new machine type, PIIX4-based, and pass through
> > > the registers you need.  The patch must document _exactly_ why the registers
> > > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > > document what the same offsets mean on PIIX4, and why it's sensible to
> > > assume that firmware for virtual machine will not read/write them.  Bonus
> > > point for also documenting the same for Q35.
> > 
> > OK. They look to be related to setting up an MBAR , but I don't understand
> > why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> 
> In particular, I think setting up MBAR should move out of i915 and become
> the bridge driver tweak on linux and windows.

That is an excellent idea.

However I am still curious to _why_ it has to be done in the first place.

> It would then run on the priveledged host
> and we won't need to deal with it in QEMU.

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > >With this long thread I lost a bit context about the challenges
> > > >that exists. But let me try summarizing it here - which will hopefully
> > > >get some consensus.
> > > >
> > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > >    We can moan and moan but I doubt it is going to change.
> > > 
> > > There are two problems:
> > > 
> > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> > 
> > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > 1135 #define MCHBAR_I915 0x44                                                        
> > 1136 #define MCHBAR_I965 0x48                     
> > 
> > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > 
> > and
> > 
> > 1139 #define DEVEN_REG 0x54                                                          
> > 
> > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > 1205         } else {                                                                
> > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > 1207                 enabled = temp & 1;                                             
> > 1208         }                                                
> > > 
> > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > > the driver identify it by class, some versions identify it by slot (1f.0).
> > 
> > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> > which sets the pch_type based on :
> > 
> >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >  434                         dev_priv->pch_id = id;                                  
> >  435                                                                                 
> >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > 
> > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > 
> > > To solve the first, make a new machine type, PIIX4-based, and pass through
> > > the registers you need.  The patch must document _exactly_ why the registers
> > > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > > document what the same offsets mean on PIIX4, and why it's sensible to
> > > assume that firmware for virtual machine will not read/write them.  Bonus
> > > point for also documenting the same for Q35.
> > 
> > OK. They look to be related to setting up an MBAR , but I don't understand
> > why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> 
> In particular, I think setting up MBAR should move out of i915 and become
> the bridge driver tweak on linux and windows.

That is an excellent idea.

However I am still curious to _why_ it has to be done in the first place.

> It would then run on the priveledged host
> and we won't need to deal with it in QEMU.

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Jesse Barnes]

On Thu, 3 Jul 2014 14:26:12 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > >With this long thread I lost a bit context about the challenges
> > > > >that exists. But let me try summarizing it here - which will hopefully
> > > > >get some consensus.
> > > > >
> > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > >    We can moan and moan but I doubt it is going to change.
> > > > 
> > > > There are two problems:
> > > > 
> > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> > > 
> > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > 1135 #define MCHBAR_I915 0x44                                                        
> > > 1136 #define MCHBAR_I965 0x48                     
> > > 
> > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > 
> > > and
> > > 
> > > 1139 #define DEVEN_REG 0x54                                                          
> > > 
> > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > 1205         } else {                                                                
> > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > 1207                 enabled = temp & 1;                                             
> > > 1208         }                                                
> > > > 
> > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > > > the driver identify it by class, some versions identify it by slot (1f.0).
> > > 
> > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> > > which sets the pch_type based on :
> > > 
> > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > >  434                         dev_priv->pch_id = id;                                  
> > >  435                                                                                 
> > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > 
> > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > 
> > > > To solve the first, make a new machine type, PIIX4-based, and pass through
> > > > the registers you need.  The patch must document _exactly_ why the registers
> > > > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > > > document what the same offsets mean on PIIX4, and why it's sensible to
> > > > assume that firmware for virtual machine will not read/write them.  Bonus
> > > > point for also documenting the same for Q35.
> > > 
> > > OK. They look to be related to setting up an MBAR , but I don't understand
> > > why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > 
> > In particular, I think setting up MBAR should move out of i915 and become
> > the bridge driver tweak on linux and windows.
> 
> That is an excellent idea.
> 
> However I am still curious to _why_ it has to be done in the first place.

The display part of the GPU is partly on the PCH, and it's possible to
mix & match them a bit, so we have this detection code to figure things
out.  In some cases, the PCH display portion may not even be present,
so we look for that too.

Practically speaking, we could probably assume specific CPU/PCH combos,
as I don't think they're generally mixed across generations, though SNB
and IVB did have compatible sockets, so there is the possibility of
mixing CPT and PPT PCHs, but those are register identical as far as the
graphics driver is concerned, so even that should be safe.

Beyond that, the other MCH data we need to look at is mirrored into the
GPU's MMIO space on current gens.  On older gens, we do need to poke at
the memory controller a bit to get some info (see
intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
we only short circuit that on VLV though; we could probably do it on
SNB+.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Jesse Barnes]

On Thu, 3 Jul 2014 14:26:12 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > >With this long thread I lost a bit context about the challenges
> > > > >that exists. But let me try summarizing it here - which will hopefully
> > > > >get some consensus.
> > > > >
> > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > >    We can moan and moan but I doubt it is going to change.
> > > > 
> > > > There are two problems:
> > > > 
> > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> > > 
> > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > 1135 #define MCHBAR_I915 0x44                                                        
> > > 1136 #define MCHBAR_I965 0x48                     
> > > 
> > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > 
> > > and
> > > 
> > > 1139 #define DEVEN_REG 0x54                                                          
> > > 
> > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > 1205         } else {                                                                
> > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > 1207                 enabled = temp & 1;                                             
> > > 1208         }                                                
> > > > 
> > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > > > the driver identify it by class, some versions identify it by slot (1f.0).
> > > 
> > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> > > which sets the pch_type based on :
> > > 
> > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > >  434                         dev_priv->pch_id = id;                                  
> > >  435                                                                                 
> > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > 
> > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > 
> > > > To solve the first, make a new machine type, PIIX4-based, and pass through
> > > > the registers you need.  The patch must document _exactly_ why the registers
> > > > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > > > document what the same offsets mean on PIIX4, and why it's sensible to
> > > > assume that firmware for virtual machine will not read/write them.  Bonus
> > > > point for also documenting the same for Q35.
> > > 
> > > OK. They look to be related to setting up an MBAR , but I don't understand
> > > why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > 
> > In particular, I think setting up MBAR should move out of i915 and become
> > the bridge driver tweak on linux and windows.
> 
> That is an excellent idea.
> 
> However I am still curious to _why_ it has to be done in the first place.

The display part of the GPU is partly on the PCH, and it's possible to
mix & match them a bit, so we have this detection code to figure things
out.  In some cases, the PCH display portion may not even be present,
so we look for that too.

Practically speaking, we could probably assume specific CPU/PCH combos,
as I don't think they're generally mixed across generations, though SNB
and IVB did have compatible sockets, so there is the possibility of
mixing CPT and PPT PCHs, but those are register identical as far as the
graphics driver is concerned, so even that should be safe.

Beyond that, the other MCH data we need to look at is mirrored into the
GPU's MMIO space on current gens.  On older gens, we do need to poke at
the memory controller a bit to get some info (see
intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
we only short circuit that on VLV though; we could probably do it on
SNB+.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> On Thu, 3 Jul 2014 14:26:12 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > >With this long thread I lost a bit context about the challenges
> > > > > >that exists. But let me try summarizing it here - which will hopefully
> > > > > >get some consensus.
> > > > > >
> > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > 
> > > > > There are two problems:
> > > > > 
> > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> > > > 
> > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > 1136 #define MCHBAR_I965 0x48                     
> > > > 
> > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > 
> > > > and
> > > > 
> > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > 
> > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > 1205         } else {                                                                
> > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > 1207                 enabled = temp & 1;                                             
> > > > 1208         }                                                
> > > > > 
> > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > > > > the driver identify it by class, some versions identify it by slot (1f.0).
> > > > 
> > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> > > > which sets the pch_type based on :
> > > > 
> > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > >  434                         dev_priv->pch_id = id;                                  
> > > >  435                                                                                 
> > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > 
> > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > 
> > > > > To solve the first, make a new machine type, PIIX4-based, and pass through
> > > > > the registers you need.  The patch must document _exactly_ why the registers
> > > > > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > > > > document what the same offsets mean on PIIX4, and why it's sensible to
> > > > > assume that firmware for virtual machine will not read/write them.  Bonus
> > > > > point for also documenting the same for Q35.
> > > > 
> > > > OK. They look to be related to setting up an MBAR , but I don't understand
> > > > why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > 
> > > In particular, I think setting up MBAR should move out of i915 and become
> > > the bridge driver tweak on linux and windows.
> > 
> > That is an excellent idea.
> > 
> > However I am still curious to _why_ it has to be done in the first place.
> 
> The display part of the GPU is partly on the PCH, and it's possible to
> mix & match them a bit, so we have this detection code to figure things
> out.  In some cases, the PCH display portion may not even be present,
> so we look for that too.
> 
> Practically speaking, we could probably assume specific CPU/PCH combos,
> as I don't think they're generally mixed across generations, though SNB
> and IVB did have compatible sockets, so there is the possibility of
> mixing CPT and PPT PCHs, but those are register identical as far as the
> graphics driver is concerned, so even that should be safe.
> 
> Beyond that, the other MCH data we need to look at is mirrored into the
> GPU's MMIO space on current gens.  On older gens, we do need to poke at
> the memory controller a bit to get some info (see
> intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
> we only short circuit that on VLV though; we could probably do it on
> SNB+.

That sounds great. Tiejun could you confirm that with
windows driver guys too?

> -- 
> Jesse Barnes, Intel Open Source Technology Center

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> On Thu, 3 Jul 2014 14:26:12 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > >With this long thread I lost a bit context about the challenges
> > > > > >that exists. But let me try summarizing it here - which will hopefully
> > > > > >get some consensus.
> > > > > >
> > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > 
> > > > > There are two problems:
> > > > > 
> > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> > > > 
> > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > 1136 #define MCHBAR_I965 0x48                     
> > > > 
> > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > 
> > > > and
> > > > 
> > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > 
> > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > 1205         } else {                                                                
> > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > 1207                 enabled = temp & 1;                                             
> > > > 1208         }                                                
> > > > > 
> > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > > > > the driver identify it by class, some versions identify it by slot (1f.0).
> > > > 
> > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> > > > which sets the pch_type based on :
> > > > 
> > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > >  434                         dev_priv->pch_id = id;                                  
> > > >  435                                                                                 
> > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > 
> > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > 
> > > > > To solve the first, make a new machine type, PIIX4-based, and pass through
> > > > > the registers you need.  The patch must document _exactly_ why the registers
> > > > > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > > > > document what the same offsets mean on PIIX4, and why it's sensible to
> > > > > assume that firmware for virtual machine will not read/write them.  Bonus
> > > > > point for also documenting the same for Q35.
> > > > 
> > > > OK. They look to be related to setting up an MBAR , but I don't understand
> > > > why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > 
> > > In particular, I think setting up MBAR should move out of i915 and become
> > > the bridge driver tweak on linux and windows.
> > 
> > That is an excellent idea.
> > 
> > However I am still curious to _why_ it has to be done in the first place.
> 
> The display part of the GPU is partly on the PCH, and it's possible to
> mix & match them a bit, so we have this detection code to figure things
> out.  In some cases, the PCH display portion may not even be present,
> so we look for that too.
> 
> Practically speaking, we could probably assume specific CPU/PCH combos,
> as I don't think they're generally mixed across generations, though SNB
> and IVB did have compatible sockets, so there is the possibility of
> mixing CPT and PPT PCHs, but those are register identical as far as the
> graphics driver is concerned, so even that should be safe.
> 
> Beyond that, the other MCH data we need to look at is mirrored into the
> GPU's MMIO space on current gens.  On older gens, we do need to poke at
> the memory controller a bit to get some info (see
> intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
> we only short circuit that on VLV though; we could probably do it on
> SNB+.

That sounds great. Tiejun could you confirm that with
windows driver guys too?

> -- 
> Jesse Barnes, Intel Open Source Technology Center

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Thu, Jul 03, 2014 at 11:27:40PM +0300, Michael S. Tsirkin wrote:
> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 14:26:12 -0400
> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 
> > > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > > >With this long thread I lost a bit context about the challenges
> > > > > > >that exists. But let me try summarizing it here - which will hopefully
> > > > > > >get some consensus.
> > > > > > >
> > > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > > 
> > > > > > There are two problems:
> > > > > > 
> > > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> > > > > 
> > > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > > 1136 #define MCHBAR_I965 0x48                     
> > > > > 
> > > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > > 
> > > > > and
> > > > > 
> > > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > > 
> > > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > > 1205         } else {                                                                
> > > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > > 1207                 enabled = temp & 1;                                             
> > > > > 1208         }                                                
> > > > > > 
> > > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > > > > > the driver identify it by class, some versions identify it by slot (1f.0).
> > > > > 
> > > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> > > > > which sets the pch_type based on :
> > > > > 
> > > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > > >  434                         dev_priv->pch_id = id;                                  
> > > > >  435                                                                                 
> > > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > > 
> > > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > > 
> > > > > > To solve the first, make a new machine type, PIIX4-based, and pass through
> > > > > > the registers you need.  The patch must document _exactly_ why the registers
> > > > > > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > > > > > document what the same offsets mean on PIIX4, and why it's sensible to
> > > > > > assume that firmware for virtual machine will not read/write them.  Bonus
> > > > > > point for also documenting the same for Q35.
> > > > > 
> > > > > OK. They look to be related to setting up an MBAR , but I don't understand
> > > > > why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > > 
> > > > In particular, I think setting up MBAR should move out of i915 and become
> > > > the bridge driver tweak on linux and windows.
> > > 
> > > That is an excellent idea.
> > > 
> > > However I am still curious to _why_ it has to be done in the first place.
> > 
> > The display part of the GPU is partly on the PCH, and it's possible to
> > mix & match them a bit, so we have this detection code to figure things
> > out.  In some cases, the PCH display portion may not even be present,
> > so we look for that too.
> > 
> > Practically speaking, we could probably assume specific CPU/PCH combos,
> > as I don't think they're generally mixed across generations, though SNB
> > and IVB did have compatible sockets, so there is the possibility of
> > mixing CPT and PPT PCHs, but those are register identical as far as the
> > graphics driver is concerned, so even that should be safe.
> > 
> > Beyond that, the other MCH data we need to look at is mirrored into the
> > GPU's MMIO space on current gens.  On older gens, we do need to poke at
> > the memory controller a bit to get some info (see
> > intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
> > we only short circuit that on VLV though; we could probably do it on
> > SNB+.
> 
> That sounds great. Tiejun could you confirm that with
> windows driver guys too?

ping?
> 
> > -- 
> > Jesse Barnes, Intel Open Source Technology Center

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Thu, Jul 03, 2014 at 11:27:40PM +0300, Michael S. Tsirkin wrote:
> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 14:26:12 -0400
> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 
> > > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > > >With this long thread I lost a bit context about the challenges
> > > > > > >that exists. But let me try summarizing it here - which will hopefully
> > > > > > >get some consensus.
> > > > > > >
> > > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > > 
> > > > > > There are two problems:
> > > > > > 
> > > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
> > > > > 
> > > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > > 1136 #define MCHBAR_I965 0x48                     
> > > > > 
> > > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > > 
> > > > > and
> > > > > 
> > > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > > 
> > > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > > 1205         } else {                                                                
> > > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > > 1207                 enabled = temp & 1;                                             
> > > > > 1208         }                                                
> > > > > > 
> > > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
> > > > > > the driver identify it by class, some versions identify it by slot (1f.0).
> > > > > 
> > > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
> > > > > which sets the pch_type based on :
> > > > > 
> > > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > > >  434                         dev_priv->pch_id = id;                                  
> > > > >  435                                                                                 
> > > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > > 
> > > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > > 
> > > > > > To solve the first, make a new machine type, PIIX4-based, and pass through
> > > > > > the registers you need.  The patch must document _exactly_ why the registers
> > > > > > are safe to pass.  If they are not reserved on PIIX4, the patch must
> > > > > > document what the same offsets mean on PIIX4, and why it's sensible to
> > > > > > assume that firmware for virtual machine will not read/write them.  Bonus
> > > > > > point for also documenting the same for Q35.
> > > > > 
> > > > > OK. They look to be related to setting up an MBAR , but I don't understand
> > > > > why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > > 
> > > > In particular, I think setting up MBAR should move out of i915 and become
> > > > the bridge driver tweak on linux and windows.
> > > 
> > > That is an excellent idea.
> > > 
> > > However I am still curious to _why_ it has to be done in the first place.
> > 
> > The display part of the GPU is partly on the PCH, and it's possible to
> > mix & match them a bit, so we have this detection code to figure things
> > out.  In some cases, the PCH display portion may not even be present,
> > so we look for that too.
> > 
> > Practically speaking, we could probably assume specific CPU/PCH combos,
> > as I don't think they're generally mixed across generations, though SNB
> > and IVB did have compatible sockets, so there is the possibility of
> > mixing CPT and PPT PCHs, but those are register identical as far as the
> > graphics driver is concerned, so even that should be safe.
> > 
> > Beyond that, the other MCH data we need to look at is mirrored into the
> > GPU's MMIO space on current gens.  On older gens, we do need to poke at
> > the memory controller a bit to get some info (see
> > intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
> > we only short circuit that on VLV though; we could probably do it on
> > SNB+.
> 
> That sounds great. Tiejun could you confirm that with
> windows driver guys too?

ping?
> 
> > -- 
> > Jesse Barnes, Intel Open Source Technology Center

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/16 22:20, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 03, 2014 at 11:27:40PM +0300, Michael S. Tsirkin wrote:
>> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
>>> On Thu, 3 Jul 2014 14:26:12 -0400
>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>>
>>>> On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
>>>>> On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
>>>>>> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
>>>>>>> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
>>>>>>>> With this long thread I lost a bit context about the challenges
>>>>>>>> that exists. But let me try summarizing it here - which will hopefully
>>>>>>>> get some consensus.
>>>>>>>>
>>>>>>>> 1). Fix IGD hardware to not use Southbridge magic addresses.
>>>>>>>>     We can moan and moan but I doubt it is going to change.
>>>>>>>
>>>>>>> There are two problems:
>>>>>>>
>>>>>>> - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
>>>>>>
>>>>>> Right. So in  drivers/gpu/drm/i915/i915_dma.c:
>>>>>> 1135 #define MCHBAR_I915 0x44
>>>>>> 1136 #define MCHBAR_I965 0x48
>>>>>>
>>>>>> 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>> 1152         if (INTEL_INFO(dev)->gen >= 4)
>>>>>> 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi);
>>>>>> 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);
>>>>>> 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
>>>>>>
>>>>>> and
>>>>>>
>>>>>> 1139 #define DEVEN_REG 0x54
>>>>>>
>>>>>> 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>> 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {
>>>>>> 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
>>>>>> 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);
>>>>>> 1205         } else {
>>>>>> 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
>>>>>> 1207                 enabled = temp & 1;
>>>>>> 1208         }
>>>>>>>
>>>>>>> - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
>>>>>>> the driver identify it by class, some versions identify it by slot (1f.0).
>>>>>>
>>>>>> Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
>>>>>> which sets the pch_type based on :
>>>>>>
>>>>>>   432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>>   433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>>   434                         dev_priv->pch_id = id;
>>>>>>   435
>>>>>>   436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>>
>>>>>> It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
>>>>>> The INTEL_PCH_DEVICE_ID_MASK is 0xff00
>>>>>>>
>>>>>>> To solve the first, make a new machine type, PIIX4-based, and pass through
>>>>>>> the registers you need.  The patch must document _exactly_ why the registers
>>>>>>> are safe to pass.  If they are not reserved on PIIX4, the patch must
>>>>>>> document what the same offsets mean on PIIX4, and why it's sensible to
>>>>>>> assume that firmware for virtual machine will not read/write them.  Bonus
>>>>>>> point for also documenting the same for Q35.
>>>>>>
>>>>>> OK. They look to be related to setting up an MBAR , but I don't understand
>>>>>> why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
>>>>>
>>>>> In particular, I think setting up MBAR should move out of i915 and become
>>>>> the bridge driver tweak on linux and windows.
>>>>
>>>> That is an excellent idea.
>>>>
>>>> However I am still curious to _why_ it has to be done in the first place.
>>>
>>> The display part of the GPU is partly on the PCH, and it's possible to
>>> mix & match them a bit, so we have this detection code to figure things
>>> out.  In some cases, the PCH display portion may not even be present,
>>> so we look for that too.
>>>
>>> Practically speaking, we could probably assume specific CPU/PCH combos,
>>> as I don't think they're generally mixed across generations, though SNB
>>> and IVB did have compatible sockets, so there is the possibility of
>>> mixing CPT and PPT PCHs, but those are register identical as far as the
>>> graphics driver is concerned, so even that should be safe.
>>>
>>> Beyond that, the other MCH data we need to look at is mirrored into the
>>> GPU's MMIO space on current gens.  On older gens, we do need to poke at
>>> the memory controller a bit to get some info (see
>>> intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
>>> we only short circuit that on VLV though; we could probably do it on
>>> SNB+.
>>
>> That sounds great. Tiejun could you confirm that with
>> windows driver guys too?
>
> ping?

Allen,

Could you reply this?

Thanks
Tiejun

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/16 22:20, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 03, 2014 at 11:27:40PM +0300, Michael S. Tsirkin wrote:
>> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
>>> On Thu, 3 Jul 2014 14:26:12 -0400
>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>>
>>>> On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
>>>>> On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
>>>>>> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
>>>>>>> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
>>>>>>>> With this long thread I lost a bit context about the challenges
>>>>>>>> that exists. But let me try summarizing it here - which will hopefully
>>>>>>>> get some consensus.
>>>>>>>>
>>>>>>>> 1). Fix IGD hardware to not use Southbridge magic addresses.
>>>>>>>>     We can moan and moan but I doubt it is going to change.
>>>>>>>
>>>>>>> There are two problems:
>>>>>>>
>>>>>>> - Northbridge (i.e. MCH i.e. PCI host bridge) configuration space addresses
>>>>>>
>>>>>> Right. So in  drivers/gpu/drm/i915/i915_dma.c:
>>>>>> 1135 #define MCHBAR_I915 0x44
>>>>>> 1136 #define MCHBAR_I965 0x48
>>>>>>
>>>>>> 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>> 1152         if (INTEL_INFO(dev)->gen >= 4)
>>>>>> 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi);
>>>>>> 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);
>>>>>> 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
>>>>>>
>>>>>> and
>>>>>>
>>>>>> 1139 #define DEVEN_REG 0x54
>>>>>>
>>>>>> 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>> 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {
>>>>>> 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
>>>>>> 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);
>>>>>> 1205         } else {
>>>>>> 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
>>>>>> 1207                 enabled = temp & 1;
>>>>>> 1208         }
>>>>>>>
>>>>>>> - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; some versions of
>>>>>>> the driver identify it by class, some versions identify it by slot (1f.0).
>>>>>>
>>>>>> Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant intel_detect_pch
>>>>>> which sets the pch_type based on :
>>>>>>
>>>>>>   432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>>   433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>>   434                         dev_priv->pch_id = id;
>>>>>>   435
>>>>>>   436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>>
>>>>>> It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
>>>>>> The INTEL_PCH_DEVICE_ID_MASK is 0xff00
>>>>>>>
>>>>>>> To solve the first, make a new machine type, PIIX4-based, and pass through
>>>>>>> the registers you need.  The patch must document _exactly_ why the registers
>>>>>>> are safe to pass.  If they are not reserved on PIIX4, the patch must
>>>>>>> document what the same offsets mean on PIIX4, and why it's sensible to
>>>>>>> assume that firmware for virtual machine will not read/write them.  Bonus
>>>>>>> point for also documenting the same for Q35.
>>>>>>
>>>>>> OK. They look to be related to setting up an MBAR , but I don't understand
>>>>>> why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
>>>>>
>>>>> In particular, I think setting up MBAR should move out of i915 and become
>>>>> the bridge driver tweak on linux and windows.
>>>>
>>>> That is an excellent idea.
>>>>
>>>> However I am still curious to _why_ it has to be done in the first place.
>>>
>>> The display part of the GPU is partly on the PCH, and it's possible to
>>> mix & match them a bit, so we have this detection code to figure things
>>> out.  In some cases, the PCH display portion may not even be present,
>>> so we look for that too.
>>>
>>> Practically speaking, we could probably assume specific CPU/PCH combos,
>>> as I don't think they're generally mixed across generations, though SNB
>>> and IVB did have compatible sockets, so there is the possibility of
>>> mixing CPT and PPT PCHs, but those are register identical as far as the
>>> graphics driver is concerned, so even that should be safe.
>>>
>>> Beyond that, the other MCH data we need to look at is mirrored into the
>>> GPU's MMIO space on current gens.  On older gens, we do need to poke at
>>> the memory controller a bit to get some info (see
>>> intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
>>> we only short circuit that on VLV though; we could probably do it on
>>> SNB+.
>>
>> That sounds great. Tiejun could you confirm that with
>> windows driver guys too?
>
> ping?

Allen,

Could you reply this?

Thanks
Tiejun

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Kay, Allen M]

> That sounds great. Tiejun could you confirm that with windows driver guys too?

I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.

I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.

Allen

-----Original Message-----
From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Michael S. Tsirkin
Sent: Thursday, July 03, 2014 1:28 PM
To: Jesse Barnes
Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> On Thu, 3 Jul 2014 14:26:12 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > >With this long thread I lost a bit context about the 
> > > > > >challenges that exists. But let me try summarizing it here - 
> > > > > >which will hopefully get some consensus.
> > > > > >
> > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > 
> > > > > There are two problems:
> > > > > 
> > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
> > > > > space addresses
> > > > 
> > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > 1136 #define MCHBAR_I965 0x48                     
> > > > 
> > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > 
> > > > and
> > > > 
> > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > 
> > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > 1205         } else {                                                                
> > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > 1207                 enabled = temp & 1;                                             
> > > > 1208         }                                                
> > > > > 
> > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; 
> > > > > some versions of the driver identify it by class, some versions identify it by slot (1f.0).
> > > > 
> > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant 
> > > > intel_detect_pch which sets the pch_type based on :
> > > > 
> > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > >  434                         dev_priv->pch_id = id;                                  
> > > >  435                                                                                 
> > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > 
> > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > 
> > > > > To solve the first, make a new machine type, PIIX4-based, and 
> > > > > pass through the registers you need.  The patch must document 
> > > > > _exactly_ why the registers are safe to pass.  If they are not 
> > > > > reserved on PIIX4, the patch must document what the same 
> > > > > offsets mean on PIIX4, and why it's sensible to assume that 
> > > > > firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
> > > > 
> > > > OK. They look to be related to setting up an MBAR , but I don't 
> > > > understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > 
> > > In particular, I think setting up MBAR should move out of i915 and 
> > > become the bridge driver tweak on linux and windows.
> > 
> > That is an excellent idea.
> > 
> > However I am still curious to _why_ it has to be done in the first place.
> 
> The display part of the GPU is partly on the PCH, and it's possible to 
> mix & match them a bit, so we have this detection code to figure 
> things out.  In some cases, the PCH display portion may not even be 
> present, so we look for that too.
> 
> Practically speaking, we could probably assume specific CPU/PCH 
> combos, as I don't think they're generally mixed across generations, 
> though SNB and IVB did have compatible sockets, so there is the 
> possibility of mixing CPT and PPT PCHs, but those are register 
> identical as far as the graphics driver is concerned, so even that should be safe.
> 
> Beyond that, the other MCH data we need to look at is mirrored into 
> the GPU's MMIO space on current gens.  On older gens, we do need to 
> poke at the memory controller a bit to get some info (see 
> intel_setup_mchbar()), but that's not true of newer stuff.  Looks like 
> we only short circuit that on VLV though; we could probably do it on
> SNB+.

That sounds great. Tiejun could you confirm that with windows driver guys too?

> --
> Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Kay, Allen M]

> That sounds great. Tiejun could you confirm that with windows driver guys too?

I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.

I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.

Allen

-----Original Message-----
From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Michael S. Tsirkin
Sent: Thursday, July 03, 2014 1:28 PM
To: Jesse Barnes
Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> On Thu, 3 Jul 2014 14:26:12 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > >With this long thread I lost a bit context about the 
> > > > > >challenges that exists. But let me try summarizing it here - 
> > > > > >which will hopefully get some consensus.
> > > > > >
> > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > 
> > > > > There are two problems:
> > > > > 
> > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
> > > > > space addresses
> > > > 
> > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > 1136 #define MCHBAR_I965 0x48                     
> > > > 
> > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > 
> > > > and
> > > > 
> > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > 
> > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > 1205         } else {                                                                
> > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > 1207                 enabled = temp & 1;                                             
> > > > 1208         }                                                
> > > > > 
> > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; 
> > > > > some versions of the driver identify it by class, some versions identify it by slot (1f.0).
> > > > 
> > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant 
> > > > intel_detect_pch which sets the pch_type based on :
> > > > 
> > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > >  434                         dev_priv->pch_id = id;                                  
> > > >  435                                                                                 
> > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > 
> > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > 
> > > > > To solve the first, make a new machine type, PIIX4-based, and 
> > > > > pass through the registers you need.  The patch must document 
> > > > > _exactly_ why the registers are safe to pass.  If they are not 
> > > > > reserved on PIIX4, the patch must document what the same 
> > > > > offsets mean on PIIX4, and why it's sensible to assume that 
> > > > > firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
> > > > 
> > > > OK. They look to be related to setting up an MBAR , but I don't 
> > > > understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > 
> > > In particular, I think setting up MBAR should move out of i915 and 
> > > become the bridge driver tweak on linux and windows.
> > 
> > That is an excellent idea.
> > 
> > However I am still curious to _why_ it has to be done in the first place.
> 
> The display part of the GPU is partly on the PCH, and it's possible to 
> mix & match them a bit, so we have this detection code to figure 
> things out.  In some cases, the PCH display portion may not even be 
> present, so we look for that too.
> 
> Practically speaking, we could probably assume specific CPU/PCH 
> combos, as I don't think they're generally mixed across generations, 
> though SNB and IVB did have compatible sockets, so there is the 
> possibility of mixing CPT and PPT PCHs, but those are register 
> identical as far as the graphics driver is concerned, so even that should be safe.
> 
> Beyond that, the other MCH data we need to look at is mirrored into 
> the GPU's MMIO space on current gens.  On older gens, we do need to 
> poke at the memory controller a bit to get some info (see 
> intel_setup_mchbar()), but that's not true of newer stuff.  Looks like 
> we only short circuit that on VLV though; we could probably do it on
> SNB+.

That sounds great. Tiejun could you confirm that with windows driver guys too?

> --
> Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
> > That sounds great. Tiejun could you confirm that with windows driver guys too?
> 
> I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
> 
> I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
> 

For the MCH PCI registers that do need to be read - can you tell us which
ones those are?

Thank you!
> Allen
> 
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Michael S. Tsirkin
> Sent: Thursday, July 03, 2014 1:28 PM
> To: Jesse Barnes
> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
> 
> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 14:26:12 -0400
> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 
> > > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > > >With this long thread I lost a bit context about the 
> > > > > > >challenges that exists. But let me try summarizing it here - 
> > > > > > >which will hopefully get some consensus.
> > > > > > >
> > > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > > 
> > > > > > There are two problems:
> > > > > > 
> > > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
> > > > > > space addresses
> > > > > 
> > > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > > 1136 #define MCHBAR_I965 0x48                     
> > > > > 
> > > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > > 
> > > > > and
> > > > > 
> > > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > > 
> > > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > > 1205         } else {                                                                
> > > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > > 1207                 enabled = temp & 1;                                             
> > > > > 1208         }                                                
> > > > > > 
> > > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; 
> > > > > > some versions of the driver identify it by class, some versions identify it by slot (1f.0).
> > > > > 
> > > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant 
> > > > > intel_detect_pch which sets the pch_type based on :
> > > > > 
> > > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > > >  434                         dev_priv->pch_id = id;                                  
> > > > >  435                                                                                 
> > > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > > 
> > > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > > 
> > > > > > To solve the first, make a new machine type, PIIX4-based, and 
> > > > > > pass through the registers you need.  The patch must document 
> > > > > > _exactly_ why the registers are safe to pass.  If they are not 
> > > > > > reserved on PIIX4, the patch must document what the same 
> > > > > > offsets mean on PIIX4, and why it's sensible to assume that 
> > > > > > firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
> > > > > 
> > > > > OK. They look to be related to setting up an MBAR , but I don't 
> > > > > understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > > 
> > > > In particular, I think setting up MBAR should move out of i915 and 
> > > > become the bridge driver tweak on linux and windows.
> > > 
> > > That is an excellent idea.
> > > 
> > > However I am still curious to _why_ it has to be done in the first place.
> > 
> > The display part of the GPU is partly on the PCH, and it's possible to 
> > mix & match them a bit, so we have this detection code to figure 
> > things out.  In some cases, the PCH display portion may not even be 
> > present, so we look for that too.
> > 
> > Practically speaking, we could probably assume specific CPU/PCH 
> > combos, as I don't think they're generally mixed across generations, 
> > though SNB and IVB did have compatible sockets, so there is the 
> > possibility of mixing CPT and PPT PCHs, but those are register 
> > identical as far as the graphics driver is concerned, so even that should be safe.
> > 
> > Beyond that, the other MCH data we need to look at is mirrored into 
> > the GPU's MMIO space on current gens.  On older gens, we do need to 
> > poke at the memory controller a bit to get some info (see 
> > intel_setup_mchbar()), but that's not true of newer stuff.  Looks like 
> > we only short circuit that on VLV though; we could probably do it on
> > SNB+.
> 
> That sounds great. Tiejun could you confirm that with windows driver guys too?
> 
> > --
> > Jesse Barnes, Intel Open Source Technology Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
> > That sounds great. Tiejun could you confirm that with windows driver guys too?
> 
> I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
> 
> I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
> 

For the MCH PCI registers that do need to be read - can you tell us which
ones those are?

Thank you!
> Allen
> 
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Michael S. Tsirkin
> Sent: Thursday, July 03, 2014 1:28 PM
> To: Jesse Barnes
> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
> 
> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 14:26:12 -0400
> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 
> > > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > > >With this long thread I lost a bit context about the 
> > > > > > >challenges that exists. But let me try summarizing it here - 
> > > > > > >which will hopefully get some consensus.
> > > > > > >
> > > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > > 
> > > > > > There are two problems:
> > > > > > 
> > > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
> > > > > > space addresses
> > > > > 
> > > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > > 1136 #define MCHBAR_I965 0x48                     
> > > > > 
> > > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > > 
> > > > > and
> > > > > 
> > > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > > 
> > > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > > 1205         } else {                                                                
> > > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > > 1207                 enabled = temp & 1;                                             
> > > > > 1208         }                                                
> > > > > > 
> > > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; 
> > > > > > some versions of the driver identify it by class, some versions identify it by slot (1f.0).
> > > > > 
> > > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant 
> > > > > intel_detect_pch which sets the pch_type based on :
> > > > > 
> > > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > > >  434                         dev_priv->pch_id = id;                                  
> > > > >  435                                                                                 
> > > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > > 
> > > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > > 
> > > > > > To solve the first, make a new machine type, PIIX4-based, and 
> > > > > > pass through the registers you need.  The patch must document 
> > > > > > _exactly_ why the registers are safe to pass.  If they are not 
> > > > > > reserved on PIIX4, the patch must document what the same 
> > > > > > offsets mean on PIIX4, and why it's sensible to assume that 
> > > > > > firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
> > > > > 
> > > > > OK. They look to be related to setting up an MBAR , but I don't 
> > > > > understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > > 
> > > > In particular, I think setting up MBAR should move out of i915 and 
> > > > become the bridge driver tweak on linux and windows.
> > > 
> > > That is an excellent idea.
> > > 
> > > However I am still curious to _why_ it has to be done in the first place.
> > 
> > The display part of the GPU is partly on the PCH, and it's possible to 
> > mix & match them a bit, so we have this detection code to figure 
> > things out.  In some cases, the PCH display portion may not even be 
> > present, so we look for that too.
> > 
> > Practically speaking, we could probably assume specific CPU/PCH 
> > combos, as I don't think they're generally mixed across generations, 
> > though SNB and IVB did have compatible sockets, so there is the 
> > possibility of mixing CPT and PPT PCHs, but those are register 
> > identical as far as the graphics driver is concerned, so even that should be safe.
> > 
> > Beyond that, the other MCH data we need to look at is mirrored into 
> > the GPU's MMIO space on current gens.  On older gens, we do need to 
> > poke at the memory controller a bit to get some info (see 
> > intel_setup_mchbar()), but that's not true of newer stuff.  Looks like 
> > we only short circuit that on VLV though; we could probably do it on
> > SNB+.
> 
> That sounds great. Tiejun could you confirm that with windows driver guys too?
> 
> > --
> > Jesse Barnes, Intel Open Source Technology Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Kay, Allen M]

> For the MCH PCI registers that do need to be read - can you tell us which ones those are?

In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW.   Some of the registers are needed by Ironlake GFX driver which we probably can remove.  I did a trace recently on Broadwell,  the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4).  Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e.

		case 0x00:        /* vendor id */
		case 0x02:        /* device id */
		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 */
		case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
		case 0x58:        /* SNB: PAVPC Offset */
		case 0xa4:        /* SNB: graphics base of stolen memory */
		case 0xa8:        /* SNB: base of GTT stolen memory */

Allen

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Friday, July 18, 2014 6:45 AM
To: Kay, Allen M
Cc: Michael S. Tsirkin; Jesse Barnes; peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
> > That sounds great. Tiejun could you confirm that with windows driver guys too?
> 
> I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
> 
> I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
> 

For the MCH PCI registers that do need to be read - can you tell us which ones those are?

Thank you!
> Allen
> 
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On 
> Behalf Of Michael S. Tsirkin
> Sent: Thursday, July 03, 2014 1:28 PM
> To: Jesse Barnes
> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross 
> Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie; 
> daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; 
> Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano 
> Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, 
> Tiejun
> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: 
> add Intel IGD passthrough support
> 
> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 14:26:12 -0400
> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 
> > > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > > >With this long thread I lost a bit context about the 
> > > > > > >challenges that exists. But let me try summarizing it here 
> > > > > > >- which will hopefully get some consensus.
> > > > > > >
> > > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > > 
> > > > > > There are two problems:
> > > > > > 
> > > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
> > > > > > space addresses
> > > > > 
> > > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > > 1136 #define MCHBAR_I965 0x48                     
> > > > > 
> > > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > > 
> > > > > and
> > > > > 
> > > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > > 
> > > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > > 1205         } else {                                                                
> > > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > > 1207                 enabled = temp & 1;                                             
> > > > > 1208         }                                                
> > > > > > 
> > > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; 
> > > > > > some versions of the driver identify it by class, some versions identify it by slot (1f.0).
> > > > > 
> > > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant 
> > > > > intel_detect_pch which sets the pch_type based on :
> > > > > 
> > > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > > >  434                         dev_priv->pch_id = id;                                  
> > > > >  435                                                                                 
> > > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > > 
> > > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > > 
> > > > > > To solve the first, make a new machine type, PIIX4-based, 
> > > > > > and pass through the registers you need.  The patch must 
> > > > > > document _exactly_ why the registers are safe to pass.  If 
> > > > > > they are not reserved on PIIX4, the patch must document what 
> > > > > > the same offsets mean on PIIX4, and why it's sensible to 
> > > > > > assume that firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
> > > > > 
> > > > > OK. They look to be related to setting up an MBAR , but I 
> > > > > don't understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > > 
> > > > In particular, I think setting up MBAR should move out of i915 
> > > > and become the bridge driver tweak on linux and windows.
> > > 
> > > That is an excellent idea.
> > > 
> > > However I am still curious to _why_ it has to be done in the first place.
> > 
> > The display part of the GPU is partly on the PCH, and it's possible 
> > to mix & match them a bit, so we have this detection code to figure 
> > things out.  In some cases, the PCH display portion may not even be 
> > present, so we look for that too.
> > 
> > Practically speaking, we could probably assume specific CPU/PCH 
> > combos, as I don't think they're generally mixed across generations, 
> > though SNB and IVB did have compatible sockets, so there is the 
> > possibility of mixing CPT and PPT PCHs, but those are register 
> > identical as far as the graphics driver is concerned, so even that should be safe.
> > 
> > Beyond that, the other MCH data we need to look at is mirrored into 
> > the GPU's MMIO space on current gens.  On older gens, we do need to 
> > poke at the memory controller a bit to get some info (see 
> > intel_setup_mchbar()), but that's not true of newer stuff.  Looks 
> > like we only short circuit that on VLV though; we could probably do 
> > it on
> > SNB+.
> 
> That sounds great. Tiejun could you confirm that with windows driver guys too?
> 
> > --
> > Jesse Barnes, Intel Open Source Technology Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Kay, Allen M]

> For the MCH PCI registers that do need to be read - can you tell us which ones those are?

In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW.   Some of the registers are needed by Ironlake GFX driver which we probably can remove.  I did a trace recently on Broadwell,  the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4).  Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e.

		case 0x00:        /* vendor id */
		case 0x02:        /* device id */
		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 */
		case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
		case 0x58:        /* SNB: PAVPC Offset */
		case 0xa4:        /* SNB: graphics base of stolen memory */
		case 0xa8:        /* SNB: base of GTT stolen memory */

Allen

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Friday, July 18, 2014 6:45 AM
To: Kay, Allen M
Cc: Michael S. Tsirkin; Jesse Barnes; peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
> > That sounds great. Tiejun could you confirm that with windows driver guys too?
> 
> I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
> 
> I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
> 

For the MCH PCI registers that do need to be read - can you tell us which ones those are?

Thank you!
> Allen
> 
> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On 
> Behalf Of Michael S. Tsirkin
> Sent: Thursday, July 03, 2014 1:28 PM
> To: Jesse Barnes
> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross 
> Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie; 
> daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; 
> Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano 
> Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, 
> Tiejun
> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: 
> add Intel IGD passthrough support
> 
> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 14:26:12 -0400
> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 
> > > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > > >With this long thread I lost a bit context about the 
> > > > > > >challenges that exists. But let me try summarizing it here 
> > > > > > >- which will hopefully get some consensus.
> > > > > > >
> > > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > > 
> > > > > > There are two problems:
> > > > > > 
> > > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
> > > > > > space addresses
> > > > > 
> > > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > > 1136 #define MCHBAR_I965 0x48                     
> > > > > 
> > > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > > 
> > > > > and
> > > > > 
> > > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > > 
> > > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > > 1205         } else {                                                                
> > > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > > 1207                 enabled = temp & 1;                                             
> > > > > 1208         }                                                
> > > > > > 
> > > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; 
> > > > > > some versions of the driver identify it by class, some versions identify it by slot (1f.0).
> > > > > 
> > > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant 
> > > > > intel_detect_pch which sets the pch_type based on :
> > > > > 
> > > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > > >  434                         dev_priv->pch_id = id;                                  
> > > > >  435                                                                                 
> > > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > > 
> > > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > > 
> > > > > > To solve the first, make a new machine type, PIIX4-based, 
> > > > > > and pass through the registers you need.  The patch must 
> > > > > > document _exactly_ why the registers are safe to pass.  If 
> > > > > > they are not reserved on PIIX4, the patch must document what 
> > > > > > the same offsets mean on PIIX4, and why it's sensible to 
> > > > > > assume that firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
> > > > > 
> > > > > OK. They look to be related to setting up an MBAR , but I 
> > > > > don't understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > > 
> > > > In particular, I think setting up MBAR should move out of i915 
> > > > and become the bridge driver tweak on linux and windows.
> > > 
> > > That is an excellent idea.
> > > 
> > > However I am still curious to _why_ it has to be done in the first place.
> > 
> > The display part of the GPU is partly on the PCH, and it's possible 
> > to mix & match them a bit, so we have this detection code to figure 
> > things out.  In some cases, the PCH display portion may not even be 
> > present, so we look for that too.
> > 
> > Practically speaking, we could probably assume specific CPU/PCH 
> > combos, as I don't think they're generally mixed across generations, 
> > though SNB and IVB did have compatible sockets, so there is the 
> > possibility of mixing CPT and PPT PCHs, but those are register 
> > identical as far as the graphics driver is concerned, so even that should be safe.
> > 
> > Beyond that, the other MCH data we need to look at is mirrored into 
> > the GPU's MMIO space on current gens.  On older gens, we do need to 
> > poke at the memory controller a bit to get some info (see 
> > intel_setup_mchbar()), but that's not true of newer stuff.  Looks 
> > like we only short circuit that on VLV though; we could probably do 
> > it on
> > SNB+.
> 
> That sounds great. Tiejun could you confirm that with windows driver guys too?
> 
> > --
> > Jesse Barnes, Intel Open Source Technology Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

[-- Attachment #1: Type: text/plain, Size: 11779 bytes --]

On Sat, Jul 19, 2014 at 12:27:21AM +0000, Kay, Allen M wrote:
> > For the MCH PCI registers that do need to be read - can you tell us which ones those are?
> 
> In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW.   Some of the registers are needed by Ironlake GFX driver which we probably can remove.  I did a trace recently on Broadwell,  the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4).  Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e.
> 
> 		case 0x00:        /* vendor id */
> 		case 0x02:        /* device id */
> 		case 0x08:        /* revision id */
> 		case 0x2c:        /* sybsystem vendor id */
> 		case 0x2e:        /* sybsystem id */

Right. We can fix the i915 to use the mechanism that Michael mentioned.
(see attached RFC patches)

> 		case 0x50:        /* SNB: processor graphics control register */
> 		case 0x52:        /* processor graphics control register */
> 		case 0xa0:        /* top of memory */
> 		case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
> 		case 0x58:        /* SNB: PAVPC Offset */
> 		case 0xa4:        /* SNB: graphics base of stolen memory */
> 		case 0xa8:        /* SNB: base of GTT stolen memory */

I dug in the intel-gtt.c (see ironlake_gtt_driver) to figure out this
a bit more. As in, I speculated, what if we returned 0 (and not implement
any support for reading from these registers). What would happen?

0x52 for Ironlake (g5):
------------------
It looks like intel_gmch_probe is called when i915_gem_gtt_init
starts (there is a lot of code that looks to be used between
intel-gtt.c and i915.c).

Anyhow the interesting parts are that i9xx_setup ends up calling
ioremap the i915 BAR to setup some of these registers for older generations.

Then i965_gtt_total_entries gets which reads 0x52, but it is only
needed for v5 generation. For other (v4 and G33) it reads it from the GPU's
0x2020  register.

If there is a mismatch, it writes to the GPU at 0x2020 to update the
the size based on the bridge. And then it reads from 0x2020 and that
is returned and stuck in  intel_private.gtt_total_entries.

So 0x52 in the emulated bridge could be populated with what the
GPU has at 0x2020. And the writes go in the emulated area.

0x52 for v6 -> v8:
-----------------
We seem to go to gen6_gmch_probe which just figures out the 
the GTT based on the GPU's BAR sizes. The stolen values
are read from 0x50 from the GPU. So no need to touch the bridge
(see gen6_gmch_probe)

OK, so no need to have 0x52 or 0x50 in the bridge.

0xA0:
---------
Could not find any reference in the Linux code. Why would
Windows driver need this? If we returned the _real_ TOM would
it matter? Is it used to figure out the device should use 32-bit
DMA operations or 40-bit?

0xb0 or 0x5c:
-------------
No mention of them in the Linux code.

0x58, 0xa4, 0xa8:
-----------------
No usage of them in the Linux code. We seem to be using the 0x52
from the bridge and 0x2020 from the GPU for this functionality.


So in theory*, if using Ironlake we need to have a proper value
in 0x52 in the bridge. But for the later chipsets we do not need
these values (I am assuming that intel_setup_mchbar can safely
return as it does that for Ironlake and could very well for later
generations).

Can this be reflected in the Windows driver as well?

P.S.
*theory: That is assuming we modify the Linux i915_drv.c:intel_detect_pch
to pick up the id as suggested earlier. See the RFC patches attached.
(Not compile tested at all!)
> 
> Allen
> 
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
> Sent: Friday, July 18, 2014 6:45 AM
> To: Kay, Allen M
> Cc: Michael S. Tsirkin; Jesse Barnes; peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
> 
> On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
> > > That sounds great. Tiejun could you confirm that with windows driver guys too?
> > 
> > I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
> > 
> > I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
> > 
> 
> For the MCH PCI registers that do need to be read - can you tell us which ones those are?
> 
> Thank you!
> > Allen
> > 
> > -----Original Message-----
> > From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On 
> > Behalf Of Michael S. Tsirkin
> > Sent: Thursday, July 03, 2014 1:28 PM
> > To: Jesse Barnes
> > Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross 
> > Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie; 
> > daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; 
> > Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano 
> > Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, 
> > Tiejun
> > Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: 
> > add Intel IGD passthrough support
> > 
> > On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> > > On Thu, 3 Jul 2014 14:26:12 -0400
> > > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > 
> > > > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > > > >With this long thread I lost a bit context about the 
> > > > > > > >challenges that exists. But let me try summarizing it here 
> > > > > > > >- which will hopefully get some consensus.
> > > > > > > >
> > > > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > > > 
> > > > > > > There are two problems:
> > > > > > > 
> > > > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
> > > > > > > space addresses
> > > > > > 
> > > > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > > > 1136 #define MCHBAR_I965 0x48                     
> > > > > > 
> > > > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > > > 
> > > > > > and
> > > > > > 
> > > > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > > > 
> > > > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > > > 1205         } else {                                                                
> > > > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > > > 1207                 enabled = temp & 1;                                             
> > > > > > 1208         }                                                
> > > > > > > 
> > > > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; 
> > > > > > > some versions of the driver identify it by class, some versions identify it by slot (1f.0).
> > > > > > 
> > > > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant 
> > > > > > intel_detect_pch which sets the pch_type based on :
> > > > > > 
> > > > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > > > >  434                         dev_priv->pch_id = id;                                  
> > > > > >  435                                                                                 
> > > > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > > > 
> > > > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > > > 
> > > > > > > To solve the first, make a new machine type, PIIX4-based, 
> > > > > > > and pass through the registers you need.  The patch must 
> > > > > > > document _exactly_ why the registers are safe to pass.  If 
> > > > > > > they are not reserved on PIIX4, the patch must document what 
> > > > > > > the same offsets mean on PIIX4, and why it's sensible to 
> > > > > > > assume that firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
> > > > > > 
> > > > > > OK. They look to be related to setting up an MBAR , but I 
> > > > > > don't understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > > > 
> > > > > In particular, I think setting up MBAR should move out of i915 
> > > > > and become the bridge driver tweak on linux and windows.
> > > > 
> > > > That is an excellent idea.
> > > > 
> > > > However I am still curious to _why_ it has to be done in the first place.
> > > 
> > > The display part of the GPU is partly on the PCH, and it's possible 
> > > to mix & match them a bit, so we have this detection code to figure 
> > > things out.  In some cases, the PCH display portion may not even be 
> > > present, so we look for that too.
> > > 
> > > Practically speaking, we could probably assume specific CPU/PCH 
> > > combos, as I don't think they're generally mixed across generations, 
> > > though SNB and IVB did have compatible sockets, so there is the 
> > > possibility of mixing CPT and PPT PCHs, but those are register 
> > > identical as far as the graphics driver is concerned, so even that should be safe.
> > > 
> > > Beyond that, the other MCH data we need to look at is mirrored into 
> > > the GPU's MMIO space on current gens.  On older gens, we do need to 
> > > poke at the memory controller a bit to get some info (see 
> > > intel_setup_mchbar()), but that's not true of newer stuff.  Looks 
> > > like we only short circuit that on VLV though; we could probably do 
> > > it on
> > > SNB+.
> > 
> > That sounds great. Tiejun could you confirm that with windows driver guys too?
> > 
> > > --
> > > Jesse Barnes, Intel Open Source Technology Center
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[-- Attachment #2: 0002-i915-drm-xen-Use-subsystem_vendor-and-model-instead-.patch --]
[-- Type: text/plain, Size: 1601 bytes --]

>From d82292c9fde0bd5ad04816096be3c4337660d4c7 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 23 Jul 2014 16:38:27 -0400
Subject: [PATCH 2/3] i915/drm/xen: Use subsystem_vendor and model instead of
 bridge to figure type.

Instead of trying to figure out what type of i915 GPU it is
based on the bridge we will use the subsystem_device if it is
virtualized. The other benefit of this patch is that for
baremetal we can now remove the scanning of the bridge and
just use the GPU's PCI device to scan if we would like.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/gpu/drm/i915/i915_drv.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 404273b..11b6dc1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -411,6 +411,9 @@ static int set_pch_type(struct pci_dev *pch, struct drm_i915_private *dev_priv)
 	if (pch->vendor != PCI_VENDOR_ID_INTEL)
 		return 0;
 
+	if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
+		id = pch->subsystem_device & INTEL_PCH_DEVICE_ID_MASK;
+
 	dev_priv->pch_id = id;
 
 	if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
@@ -478,6 +481,14 @@ void intel_detect_pch(struct drm_device *dev)
 		if (ok)
 			break;
 	}
+	if (!ok) {
+		/*
+		 * Try the GPU in case it is virtualized and we want to use
+		 * the subsystem vendor id instead of the bridge to match.
+		 */
+		pch = dev->pdev;
+		ok = set_pch_type(pch, dev_priv);
+	}
 	if (!ok)
 		DRM_DEBUG_KMS("No PCH found.\n");
 }
-- 
1.9.3


[-- Attachment #3: 0003-i915-drm-xen-If-we-are-running-under-virtualized-env.patch --]
[-- Type: text/plain, Size: 2043 bytes --]

>From 26d593b3b3255a57536aabc5cdf0f57061b6d888 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 23 Jul 2014 16:41:47 -0400
Subject: [PATCH 3/3] i915/drm/xen: If we are running under virtualized env we
 don't need the bridge.

So lets check if the subsystem tells us that we are under Xen
and if so ignore the bridge.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/gpu/drm/i915/i915_dma.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 6c65639..70bd61f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1123,6 +1123,11 @@ static int i915_set_status_page(struct drm_device *dev, void *data,
 static int i915_get_bridge_dev(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct pci_dev *pch = dev->pdev;
+
+	/* If we are virtualized we don't need the bridge. */
+	if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
+		return 0;
 
 	dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
 	if (!dev_priv->bridge_dev) {
@@ -1199,6 +1204,9 @@ intel_setup_mchbar(struct drm_device *dev)
 
 	dev_priv->mchbar_need_disable = false;
 
+	if (!dev_priv->bridge_dev)
+		return;
+
 	if (IS_I915G(dev) || IS_I915GM(dev)) {
 		pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
 		enabled = !!(temp & DEVEN_MCHBAR_EN);
@@ -1801,7 +1809,8 @@ out_regs:
 	intel_uncore_fini(dev);
 	pci_iounmap(dev->pdev, dev_priv->regs);
 put_bridge:
-	pci_dev_put(dev_priv->bridge_dev);
+	if (dev_priv->bridge_dev)
+		pci_dev_put(dev_priv->bridge_dev);
 free_priv:
 	if (dev_priv->slab)
 		kmem_cache_destroy(dev_priv->slab);
@@ -1903,7 +1912,8 @@ int i915_driver_unload(struct drm_device *dev)
 	if (dev_priv->slab)
 		kmem_cache_destroy(dev_priv->slab);
 
-	pci_dev_put(dev_priv->bridge_dev);
+	if (dev_priv->bridge_dev)
+		pci_dev_put(dev_priv->bridge_dev);
 	kfree(dev_priv);
 
 	return 0;
-- 
1.9.3


[-- Attachment #4: 0001-drm-i915-Move-figuring-out-of-the-PCH-type-to-its-ow.patch --]
[-- Type: text/plain, Size: 4524 bytes --]

>From d692d0458f60e3207d7dba615c8cbbcdeca07187 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 23 Jul 2014 16:31:12 -0400
Subject: [PATCH 1/3] drm/i915: Move figuring out of the PCH type to its own
 function and fix reference bug.

We move the figuring of the PCH type to its own function
and simplyfind the loop. Also we fix the 'pci_dev_put' which
previously was only called for the last bridge. Meaning
if the host had two bridges we would only put the last one, but
not the first one. With this we fix that.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/gpu/drm/i915/i915_drv.c | 90 ++++++++++++++++++++++-------------------
 1 file changed, 49 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 651e65e..404273b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -404,11 +404,55 @@ static const struct pci_device_id pciidlist[] = {		/* aka */
 MODULE_DEVICE_TABLE(pci, pciidlist);
 #endif
 
+static int set_pch_type(struct pci_dev *pch, struct drm_i915_private *dev_priv)
+{
+	unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
+
+	if (pch->vendor != PCI_VENDOR_ID_INTEL)
+		return 0;
+
+	dev_priv->pch_id = id;
+
+	if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
+		dev_priv->pch_type = PCH_IBX;
+		DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
+		WARN_ON(!IS_GEN5(dev));
+	} else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
+		dev_priv->pch_type = PCH_CPT;
+		DRM_DEBUG_KMS("Found CougarPoint PCH\n");
+		WARN_ON(!(IS_GEN6(dev) || IS_IVYBRIDGE(dev)));
+	} else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
+		/* PantherPoint is CPT compatible */
+		dev_priv->pch_type = PCH_CPT;
+		DRM_DEBUG_KMS("Found PantherPoint PCH\n");
+		WARN_ON(!(IS_GEN6(dev) || IS_IVYBRIDGE(dev)));
+	} else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
+		dev_priv->pch_type = PCH_LPT;
+		DRM_DEBUG_KMS("Found LynxPoint PCH\n");
+		WARN_ON(!IS_HASWELL(dev));
+		WARN_ON(IS_ULT(dev));
+	} else if (IS_BROADWELL(dev)) {
+		dev_priv->pch_type = PCH_LPT;
+		dev_priv->pch_id =
+			INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
+		DRM_DEBUG_KMS("This is Broadwell, assuming "
+			      "LynxPoint LP PCH\n");
+	} else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+		dev_priv->pch_type = PCH_LPT;
+		DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
+		WARN_ON(!IS_HASWELL(dev));
+		WARN_ON(!IS_ULT(dev));
+	} else
+		return 1;
+
+	return 1;
+}
+
 void intel_detect_pch(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct pci_dev *pch = NULL;
-
+	int ok = 0;
 	/* In all current cases, num_pipes is equivalent to the PCH_NOP setting
 	 * (which really amounts to a PCH but no South Display).
 	 */
@@ -429,49 +473,13 @@ void intel_detect_pch(struct drm_device *dev)
 	 * of only checking the first one.
 	 */
 	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
-		if (pch->vendor == PCI_VENDOR_ID_INTEL) {
-			unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
-			dev_priv->pch_id = id;
-
-			if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
-				dev_priv->pch_type = PCH_IBX;
-				DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
-				WARN_ON(!IS_GEN5(dev));
-			} else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
-				dev_priv->pch_type = PCH_CPT;
-				DRM_DEBUG_KMS("Found CougarPoint PCH\n");
-				WARN_ON(!(IS_GEN6(dev) || IS_IVYBRIDGE(dev)));
-			} else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
-				/* PantherPoint is CPT compatible */
-				dev_priv->pch_type = PCH_CPT;
-				DRM_DEBUG_KMS("Found PantherPoint PCH\n");
-				WARN_ON(!(IS_GEN6(dev) || IS_IVYBRIDGE(dev)));
-			} else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
-				dev_priv->pch_type = PCH_LPT;
-				DRM_DEBUG_KMS("Found LynxPoint PCH\n");
-				WARN_ON(!IS_HASWELL(dev));
-				WARN_ON(IS_ULT(dev));
-			} else if (IS_BROADWELL(dev)) {
-				dev_priv->pch_type = PCH_LPT;
-				dev_priv->pch_id =
-					INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
-				DRM_DEBUG_KMS("This is Broadwell, assuming "
-					      "LynxPoint LP PCH\n");
-			} else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
-				dev_priv->pch_type = PCH_LPT;
-				DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
-				WARN_ON(!IS_HASWELL(dev));
-				WARN_ON(!IS_ULT(dev));
-			} else
-				continue;
-
+		ok = set_pch_type(pch, dev_priv);
+		pci_dev_put(pch);
+		if (ok)
 			break;
-		}
 	}
-	if (!pch)
+	if (!ok)
 		DRM_DEBUG_KMS("No PCH found.\n");
-
-	pci_dev_put(pch);
 }
 
 bool i915_semaphore_is_enabled(struct drm_device *dev)
-- 
1.9.3

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

[-- Attachment #1: Type: text/plain, Size: 11779 bytes --]

On Sat, Jul 19, 2014 at 12:27:21AM +0000, Kay, Allen M wrote:
> > For the MCH PCI registers that do need to be read - can you tell us which ones those are?
> 
> In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW.   Some of the registers are needed by Ironlake GFX driver which we probably can remove.  I did a trace recently on Broadwell,  the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4).  Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e.
> 
> 		case 0x00:        /* vendor id */
> 		case 0x02:        /* device id */
> 		case 0x08:        /* revision id */
> 		case 0x2c:        /* sybsystem vendor id */
> 		case 0x2e:        /* sybsystem id */

Right. We can fix the i915 to use the mechanism that Michael mentioned.
(see attached RFC patches)

> 		case 0x50:        /* SNB: processor graphics control register */
> 		case 0x52:        /* processor graphics control register */
> 		case 0xa0:        /* top of memory */
> 		case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
> 		case 0x58:        /* SNB: PAVPC Offset */
> 		case 0xa4:        /* SNB: graphics base of stolen memory */
> 		case 0xa8:        /* SNB: base of GTT stolen memory */

I dug in the intel-gtt.c (see ironlake_gtt_driver) to figure out this
a bit more. As in, I speculated, what if we returned 0 (and not implement
any support for reading from these registers). What would happen?

0x52 for Ironlake (g5):
------------------
It looks like intel_gmch_probe is called when i915_gem_gtt_init
starts (there is a lot of code that looks to be used between
intel-gtt.c and i915.c).

Anyhow the interesting parts are that i9xx_setup ends up calling
ioremap the i915 BAR to setup some of these registers for older generations.

Then i965_gtt_total_entries gets which reads 0x52, but it is only
needed for v5 generation. For other (v4 and G33) it reads it from the GPU's
0x2020  register.

If there is a mismatch, it writes to the GPU at 0x2020 to update the
the size based on the bridge. And then it reads from 0x2020 and that
is returned and stuck in  intel_private.gtt_total_entries.

So 0x52 in the emulated bridge could be populated with what the
GPU has at 0x2020. And the writes go in the emulated area.

0x52 for v6 -> v8:
-----------------
We seem to go to gen6_gmch_probe which just figures out the 
the GTT based on the GPU's BAR sizes. The stolen values
are read from 0x50 from the GPU. So no need to touch the bridge
(see gen6_gmch_probe)

OK, so no need to have 0x52 or 0x50 in the bridge.

0xA0:
---------
Could not find any reference in the Linux code. Why would
Windows driver need this? If we returned the _real_ TOM would
it matter? Is it used to figure out the device should use 32-bit
DMA operations or 40-bit?

0xb0 or 0x5c:
-------------
No mention of them in the Linux code.

0x58, 0xa4, 0xa8:
-----------------
No usage of them in the Linux code. We seem to be using the 0x52
from the bridge and 0x2020 from the GPU for this functionality.


So in theory*, if using Ironlake we need to have a proper value
in 0x52 in the bridge. But for the later chipsets we do not need
these values (I am assuming that intel_setup_mchbar can safely
return as it does that for Ironlake and could very well for later
generations).

Can this be reflected in the Windows driver as well?

P.S.
*theory: That is assuming we modify the Linux i915_drv.c:intel_detect_pch
to pick up the id as suggested earlier. See the RFC patches attached.
(Not compile tested at all!)
> 
> Allen
> 
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
> Sent: Friday, July 18, 2014 6:45 AM
> To: Kay, Allen M
> Cc: Michael S. Tsirkin; Jesse Barnes; peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
> 
> On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
> > > That sounds great. Tiejun could you confirm that with windows driver guys too?
> > 
> > I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
> > 
> > I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
> > 
> 
> For the MCH PCI registers that do need to be read - can you tell us which ones those are?
> 
> Thank you!
> > Allen
> > 
> > -----Original Message-----
> > From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On 
> > Behalf Of Michael S. Tsirkin
> > Sent: Thursday, July 03, 2014 1:28 PM
> > To: Jesse Barnes
> > Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross 
> > Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie; 
> > daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; 
> > Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano 
> > Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, 
> > Tiejun
> > Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: 
> > add Intel IGD passthrough support
> > 
> > On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> > > On Thu, 3 Jul 2014 14:26:12 -0400
> > > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > 
> > > > On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> > > > > On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > > > On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > > > > > > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > > > > > > >With this long thread I lost a bit context about the 
> > > > > > > >challenges that exists. But let me try summarizing it here 
> > > > > > > >- which will hopefully get some consensus.
> > > > > > > >
> > > > > > > >1). Fix IGD hardware to not use Southbridge magic addresses.
> > > > > > > >    We can moan and moan but I doubt it is going to change.
> > > > > > > 
> > > > > > > There are two problems:
> > > > > > > 
> > > > > > > - Northbridge (i.e. MCH i.e. PCI host bridge) configuration 
> > > > > > > space addresses
> > > > > > 
> > > > > > Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> > > > > > 1135 #define MCHBAR_I915 0x44                                                        
> > > > > > 1136 #define MCHBAR_I965 0x48                     
> > > > > > 
> > > > > > 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;        
> > > > > > 1152         if (INTEL_INFO(dev)->gen >= 4)                                          
> > > > > > 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi); 
> > > > > > 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);             
> > > > > > 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;                
> > > > > > 
> > > > > > and
> > > > > > 
> > > > > > 1139 #define DEVEN_REG 0x54                                                          
> > > > > > 
> > > > > > 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915; 
> > > > > > 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {                                  
> > > > > > 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);  
> > > > > > 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);                           
> > > > > > 1205         } else {                                                                
> > > > > > 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp); 
> > > > > > 1207                 enabled = temp & 1;                                             
> > > > > > 1208         }                                                
> > > > > > > 
> > > > > > > - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID; 
> > > > > > > some versions of the driver identify it by class, some versions identify it by slot (1f.0).
> > > > > > 
> > > > > > Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant 
> > > > > > intel_detect_pch which sets the pch_type based on :
> > > > > > 
> > > > > >  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {                       
> > > > > >  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> > > > > >  434                         dev_priv->pch_id = id;                                  
> > > > > >  435                                                                                 
> > > > > >  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) { 
> > > > > > 
> > > > > > It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> > > > > > The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> > > > > > > 
> > > > > > > To solve the first, make a new machine type, PIIX4-based, 
> > > > > > > and pass through the registers you need.  The patch must 
> > > > > > > document _exactly_ why the registers are safe to pass.  If 
> > > > > > > they are not reserved on PIIX4, the patch must document what 
> > > > > > > the same offsets mean on PIIX4, and why it's sensible to 
> > > > > > > assume that firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
> > > > > > 
> > > > > > OK. They look to be related to setting up an MBAR , but I 
> > > > > > don't understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> > > > > 
> > > > > In particular, I think setting up MBAR should move out of i915 
> > > > > and become the bridge driver tweak on linux and windows.
> > > > 
> > > > That is an excellent idea.
> > > > 
> > > > However I am still curious to _why_ it has to be done in the first place.
> > > 
> > > The display part of the GPU is partly on the PCH, and it's possible 
> > > to mix & match them a bit, so we have this detection code to figure 
> > > things out.  In some cases, the PCH display portion may not even be 
> > > present, so we look for that too.
> > > 
> > > Practically speaking, we could probably assume specific CPU/PCH 
> > > combos, as I don't think they're generally mixed across generations, 
> > > though SNB and IVB did have compatible sockets, so there is the 
> > > possibility of mixing CPT and PPT PCHs, but those are register 
> > > identical as far as the graphics driver is concerned, so even that should be safe.
> > > 
> > > Beyond that, the other MCH data we need to look at is mirrored into 
> > > the GPU's MMIO space on current gens.  On older gens, we do need to 
> > > poke at the memory controller a bit to get some info (see 
> > > intel_setup_mchbar()), but that's not true of newer stuff.  Looks 
> > > like we only short circuit that on VLV though; we could probably do 
> > > it on
> > > SNB+.
> > 
> > That sounds great. Tiejun could you confirm that with windows driver guys too?
> > 
> > > --
> > > Jesse Barnes, Intel Open Source Technology Center
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[-- Attachment #2: 0002-i915-drm-xen-Use-subsystem_vendor-and-model-instead-.patch --]
[-- Type: text/plain, Size: 1601 bytes --]

>From d82292c9fde0bd5ad04816096be3c4337660d4c7 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 23 Jul 2014 16:38:27 -0400
Subject: [PATCH 2/3] i915/drm/xen: Use subsystem_vendor and model instead of
 bridge to figure type.

Instead of trying to figure out what type of i915 GPU it is
based on the bridge we will use the subsystem_device if it is
virtualized. The other benefit of this patch is that for
baremetal we can now remove the scanning of the bridge and
just use the GPU's PCI device to scan if we would like.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/gpu/drm/i915/i915_drv.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 404273b..11b6dc1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -411,6 +411,9 @@ static int set_pch_type(struct pci_dev *pch, struct drm_i915_private *dev_priv)
 	if (pch->vendor != PCI_VENDOR_ID_INTEL)
 		return 0;
 
+	if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
+		id = pch->subsystem_device & INTEL_PCH_DEVICE_ID_MASK;
+
 	dev_priv->pch_id = id;
 
 	if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
@@ -478,6 +481,14 @@ void intel_detect_pch(struct drm_device *dev)
 		if (ok)
 			break;
 	}
+	if (!ok) {
+		/*
+		 * Try the GPU in case it is virtualized and we want to use
+		 * the subsystem vendor id instead of the bridge to match.
+		 */
+		pch = dev->pdev;
+		ok = set_pch_type(pch, dev_priv);
+	}
 	if (!ok)
 		DRM_DEBUG_KMS("No PCH found.\n");
 }
-- 
1.9.3


[-- Attachment #3: 0003-i915-drm-xen-If-we-are-running-under-virtualized-env.patch --]
[-- Type: text/plain, Size: 2043 bytes --]

>From 26d593b3b3255a57536aabc5cdf0f57061b6d888 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 23 Jul 2014 16:41:47 -0400
Subject: [PATCH 3/3] i915/drm/xen: If we are running under virtualized env we
 don't need the bridge.

So lets check if the subsystem tells us that we are under Xen
and if so ignore the bridge.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/gpu/drm/i915/i915_dma.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 6c65639..70bd61f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1123,6 +1123,11 @@ static int i915_set_status_page(struct drm_device *dev, void *data,
 static int i915_get_bridge_dev(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct pci_dev *pch = dev->pdev;
+
+	/* If we are virtualized we don't need the bridge. */
+	if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
+		return 0;
 
 	dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
 	if (!dev_priv->bridge_dev) {
@@ -1199,6 +1204,9 @@ intel_setup_mchbar(struct drm_device *dev)
 
 	dev_priv->mchbar_need_disable = false;
 
+	if (!dev_priv->bridge_dev)
+		return;
+
 	if (IS_I915G(dev) || IS_I915GM(dev)) {
 		pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
 		enabled = !!(temp & DEVEN_MCHBAR_EN);
@@ -1801,7 +1809,8 @@ out_regs:
 	intel_uncore_fini(dev);
 	pci_iounmap(dev->pdev, dev_priv->regs);
 put_bridge:
-	pci_dev_put(dev_priv->bridge_dev);
+	if (dev_priv->bridge_dev)
+		pci_dev_put(dev_priv->bridge_dev);
 free_priv:
 	if (dev_priv->slab)
 		kmem_cache_destroy(dev_priv->slab);
@@ -1903,7 +1912,8 @@ int i915_driver_unload(struct drm_device *dev)
 	if (dev_priv->slab)
 		kmem_cache_destroy(dev_priv->slab);
 
-	pci_dev_put(dev_priv->bridge_dev);
+	if (dev_priv->bridge_dev)
+		pci_dev_put(dev_priv->bridge_dev);
 	kfree(dev_priv);
 
 	return 0;
-- 
1.9.3


[-- Attachment #4: 0001-drm-i915-Move-figuring-out-of-the-PCH-type-to-its-ow.patch --]
[-- Type: text/plain, Size: 4524 bytes --]

>From d692d0458f60e3207d7dba615c8cbbcdeca07187 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 23 Jul 2014 16:31:12 -0400
Subject: [PATCH 1/3] drm/i915: Move figuring out of the PCH type to its own
 function and fix reference bug.

We move the figuring of the PCH type to its own function
and simplyfind the loop. Also we fix the 'pci_dev_put' which
previously was only called for the last bridge. Meaning
if the host had two bridges we would only put the last one, but
not the first one. With this we fix that.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/gpu/drm/i915/i915_drv.c | 90 ++++++++++++++++++++++-------------------
 1 file changed, 49 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 651e65e..404273b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -404,11 +404,55 @@ static const struct pci_device_id pciidlist[] = {		/* aka */
 MODULE_DEVICE_TABLE(pci, pciidlist);
 #endif
 
+static int set_pch_type(struct pci_dev *pch, struct drm_i915_private *dev_priv)
+{
+	unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
+
+	if (pch->vendor != PCI_VENDOR_ID_INTEL)
+		return 0;
+
+	dev_priv->pch_id = id;
+
+	if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
+		dev_priv->pch_type = PCH_IBX;
+		DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
+		WARN_ON(!IS_GEN5(dev));
+	} else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
+		dev_priv->pch_type = PCH_CPT;
+		DRM_DEBUG_KMS("Found CougarPoint PCH\n");
+		WARN_ON(!(IS_GEN6(dev) || IS_IVYBRIDGE(dev)));
+	} else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
+		/* PantherPoint is CPT compatible */
+		dev_priv->pch_type = PCH_CPT;
+		DRM_DEBUG_KMS("Found PantherPoint PCH\n");
+		WARN_ON(!(IS_GEN6(dev) || IS_IVYBRIDGE(dev)));
+	} else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
+		dev_priv->pch_type = PCH_LPT;
+		DRM_DEBUG_KMS("Found LynxPoint PCH\n");
+		WARN_ON(!IS_HASWELL(dev));
+		WARN_ON(IS_ULT(dev));
+	} else if (IS_BROADWELL(dev)) {
+		dev_priv->pch_type = PCH_LPT;
+		dev_priv->pch_id =
+			INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
+		DRM_DEBUG_KMS("This is Broadwell, assuming "
+			      "LynxPoint LP PCH\n");
+	} else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+		dev_priv->pch_type = PCH_LPT;
+		DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
+		WARN_ON(!IS_HASWELL(dev));
+		WARN_ON(!IS_ULT(dev));
+	} else
+		return 1;
+
+	return 1;
+}
+
 void intel_detect_pch(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct pci_dev *pch = NULL;
-
+	int ok = 0;
 	/* In all current cases, num_pipes is equivalent to the PCH_NOP setting
 	 * (which really amounts to a PCH but no South Display).
 	 */
@@ -429,49 +473,13 @@ void intel_detect_pch(struct drm_device *dev)
 	 * of only checking the first one.
 	 */
 	while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
-		if (pch->vendor == PCI_VENDOR_ID_INTEL) {
-			unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
-			dev_priv->pch_id = id;
-
-			if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
-				dev_priv->pch_type = PCH_IBX;
-				DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
-				WARN_ON(!IS_GEN5(dev));
-			} else if (id == INTEL_PCH_CPT_DEVICE_ID_TYPE) {
-				dev_priv->pch_type = PCH_CPT;
-				DRM_DEBUG_KMS("Found CougarPoint PCH\n");
-				WARN_ON(!(IS_GEN6(dev) || IS_IVYBRIDGE(dev)));
-			} else if (id == INTEL_PCH_PPT_DEVICE_ID_TYPE) {
-				/* PantherPoint is CPT compatible */
-				dev_priv->pch_type = PCH_CPT;
-				DRM_DEBUG_KMS("Found PantherPoint PCH\n");
-				WARN_ON(!(IS_GEN6(dev) || IS_IVYBRIDGE(dev)));
-			} else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
-				dev_priv->pch_type = PCH_LPT;
-				DRM_DEBUG_KMS("Found LynxPoint PCH\n");
-				WARN_ON(!IS_HASWELL(dev));
-				WARN_ON(IS_ULT(dev));
-			} else if (IS_BROADWELL(dev)) {
-				dev_priv->pch_type = PCH_LPT;
-				dev_priv->pch_id =
-					INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
-				DRM_DEBUG_KMS("This is Broadwell, assuming "
-					      "LynxPoint LP PCH\n");
-			} else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
-				dev_priv->pch_type = PCH_LPT;
-				DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
-				WARN_ON(!IS_HASWELL(dev));
-				WARN_ON(!IS_ULT(dev));
-			} else
-				continue;
-
+		ok = set_pch_type(pch, dev_priv);
+		pci_dev_put(pch);
+		if (ok)
 			break;
-		}
 	}
-	if (!pch)
+	if (!ok)
 		DRM_DEBUG_KMS("No PCH found.\n");
-
-	pci_dev_put(pch);
 }
 
 bool i915_semaphore_is_enabled(struct drm_device *dev)
-- 
1.9.3


[-- Attachment #5: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/24 4:54, Konrad Rzeszutek Wilk wrote:
> On Sat, Jul 19, 2014 at 12:27:21AM +0000, Kay, Allen M wrote:
>>> For the MCH PCI registers that do need to be read - can you tell us which ones those are?
>>
>> In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW.   Some of the registers are needed by Ironlake GFX driver which we probably can remove.  I did a trace recently on Broadwell,  the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4).  Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e.
>>
>> 		case 0x00:        /* vendor id */
>> 		case 0x02:        /* device id */
>> 		case 0x08:        /* revision id */
>> 		case 0x2c:        /* sybsystem vendor id */
>> 		case 0x2e:        /* sybsystem id */
>
> Right. We can fix the i915 to use the mechanism that Michael mentioned.
> (see attached RFC patches)
>
>> 		case 0x50:        /* SNB: processor graphics control register */
>> 		case 0x52:        /* processor graphics control register */
>> 		case 0xa0:        /* top of memory */
>> 		case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
>> 		case 0x58:        /* SNB: PAVPC Offset */
>> 		case 0xa4:        /* SNB: graphics base of stolen memory */
>> 		case 0xa8:        /* SNB: base of GTT stolen memory */
>
> I dug in the intel-gtt.c (see ironlake_gtt_driver) to figure out this
> a bit more. As in, I speculated, what if we returned 0 (and not implement
> any support for reading from these registers). What would happen?
>
> 0x52 for Ironlake (g5):
> ------------------
> It looks like intel_gmch_probe is called when i915_gem_gtt_init
> starts (there is a lot of code that looks to be used between
> intel-gtt.c and i915.c).
>
> Anyhow the interesting parts are that i9xx_setup ends up calling
> ioremap the i915 BAR to setup some of these registers for older generations.
>
> Then i965_gtt_total_entries gets which reads 0x52, but it is only
> needed for v5 generation. For other (v4 and G33) it reads it from the GPU's
> 0x2020  register.
>
> If there is a mismatch, it writes to the GPU at 0x2020 to update the
> the size based on the bridge. And then it reads from 0x2020 and that
> is returned and stuck in  intel_private.gtt_total_entries.
>
> So 0x52 in the emulated bridge could be populated with what the
> GPU has at 0x2020. And the writes go in the emulated area.
>
> 0x52 for v6 -> v8:
> -----------------
> We seem to go to gen6_gmch_probe which just figures out the
> the GTT based on the GPU's BAR sizes. The stolen values
> are read from 0x50 from the GPU. So no need to touch the bridge
> (see gen6_gmch_probe)
>
> OK, so no need to have 0x52 or 0x50 in the bridge.
>
> 0xA0:
> ---------
> Could not find any reference in the Linux code. Why would
> Windows driver need this? If we returned the _real_ TOM would
> it matter? Is it used to figure out the device should use 32-bit
> DMA operations or 40-bit?
>
> 0xb0 or 0x5c:
> -------------
> No mention of them in the Linux code.
>
> 0x58, 0xa4, 0xa8:
> -----------------
> No usage of them in the Linux code. We seem to be using the 0x52
> from the bridge and 0x2020 from the GPU for this functionality.
>
>
> So in theory*, if using Ironlake we need to have a proper value
> in 0x52 in the bridge. But for the later chipsets we do not need
> these values (I am assuming that intel_setup_mchbar can safely
> return as it does that for Ironlake and could very well for later
> generations).
>
> Can this be reflected in the Windows driver as well?
>
> P.S.
> *theory: That is assuming we modify the Linux i915_drv.c:intel_detect_pch
> to pick up the id as suggested earlier. See the RFC patches attached.
> (Not compile tested at all!)

I take a look these patches, looks we still scan all PCI Bridge to walk 
all PCHs. So this means we still need to fake a PCI bridge, right? Or 
maybe you don't cover this problem this time.

I prefer we should check dev slot to get that PCH like my previous 
patch, "gpu:drm:i915:intel_detect_pch: back to check devfn instead of 
check class type". Because Windows always use this way, so I think this 
point should be same between Linux and Windows.

Or we need anther better way to unify all OSs.

Thanks
Tiejun

>>
>> Allen
>>
>> -----Original Message-----
>> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
>> Sent: Friday, July 18, 2014 6:45 AM
>> To: Kay, Allen M
>> Cc: Michael S. Tsirkin; Jesse Barnes; peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
>> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
>>
>> On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
>>>> That sounds great. Tiejun could you confirm that with windows driver guys too?
>>>
>>> I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
>>>
>>> I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
>>>
>>
>> For the MCH PCI registers that do need to be read - can you tell us which ones those are?
>>
>> Thank you!
>>> Allen
>>>
>>> -----Original Message-----
>>> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>>> Behalf Of Michael S. Tsirkin
>>> Sent: Thursday, July 03, 2014 1:28 PM
>>> To: Jesse Barnes
>>> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross
>>> Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie;
>>> daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org;
>>> Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano
>>> Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen,
>>> Tiejun
>>> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen:
>>> add Intel IGD passthrough support
>>>
>>> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
>>>> On Thu, 3 Jul 2014 14:26:12 -0400
>>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>>>
>>>>> On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
>>>>>> On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
>>>>>>> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
>>>>>>>> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
>>>>>>>>> With this long thread I lost a bit context about the
>>>>>>>>> challenges that exists. But let me try summarizing it here
>>>>>>>>> - which will hopefully get some consensus.
>>>>>>>>>
>>>>>>>>> 1). Fix IGD hardware to not use Southbridge magic addresses.
>>>>>>>>>     We can moan and moan but I doubt it is going to change.
>>>>>>>>
>>>>>>>> There are two problems:
>>>>>>>>
>>>>>>>> - Northbridge (i.e. MCH i.e. PCI host bridge) configuration
>>>>>>>> space addresses
>>>>>>>
>>>>>>> Right. So in  drivers/gpu/drm/i915/i915_dma.c:
>>>>>>> 1135 #define MCHBAR_I915 0x44
>>>>>>> 1136 #define MCHBAR_I965 0x48
>>>>>>>
>>>>>>> 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>>> 1152         if (INTEL_INFO(dev)->gen >= 4)
>>>>>>> 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi);
>>>>>>> 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);
>>>>>>> 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>> 1139 #define DEVEN_REG 0x54
>>>>>>>
>>>>>>> 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>>> 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {
>>>>>>> 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
>>>>>>> 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);
>>>>>>> 1205         } else {
>>>>>>> 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
>>>>>>> 1207                 enabled = temp & 1;
>>>>>>> 1208         }
>>>>>>>>
>>>>>>>> - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID;
>>>>>>>> some versions of the driver identify it by class, some versions identify it by slot (1f.0).
>>>>>>>
>>>>>>> Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant
>>>>>>> intel_detect_pch which sets the pch_type based on :
>>>>>>>
>>>>>>>   432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>>>   433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>>>   434                         dev_priv->pch_id = id;
>>>>>>>   435
>>>>>>>   436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>>>
>>>>>>> It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
>>>>>>> The INTEL_PCH_DEVICE_ID_MASK is 0xff00
>>>>>>>>
>>>>>>>> To solve the first, make a new machine type, PIIX4-based,
>>>>>>>> and pass through the registers you need.  The patch must
>>>>>>>> document _exactly_ why the registers are safe to pass.  If
>>>>>>>> they are not reserved on PIIX4, the patch must document what
>>>>>>>> the same offsets mean on PIIX4, and why it's sensible to
>>>>>>>> assume that firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
>>>>>>>
>>>>>>> OK. They look to be related to setting up an MBAR , but I
>>>>>>> don't understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
>>>>>>
>>>>>> In particular, I think setting up MBAR should move out of i915
>>>>>> and become the bridge driver tweak on linux and windows.
>>>>>
>>>>> That is an excellent idea.
>>>>>
>>>>> However I am still curious to _why_ it has to be done in the first place.
>>>>
>>>> The display part of the GPU is partly on the PCH, and it's possible
>>>> to mix & match them a bit, so we have this detection code to figure
>>>> things out.  In some cases, the PCH display portion may not even be
>>>> present, so we look for that too.
>>>>
>>>> Practically speaking, we could probably assume specific CPU/PCH
>>>> combos, as I don't think they're generally mixed across generations,
>>>> though SNB and IVB did have compatible sockets, so there is the
>>>> possibility of mixing CPT and PPT PCHs, but those are register
>>>> identical as far as the graphics driver is concerned, so even that should be safe.
>>>>
>>>> Beyond that, the other MCH data we need to look at is mirrored into
>>>> the GPU's MMIO space on current gens.  On older gens, we do need to
>>>> poke at the memory controller a bit to get some info (see
>>>> intel_setup_mchbar()), but that's not true of newer stuff.  Looks
>>>> like we only short circuit that on VLV though; we could probably do
>>>> it on
>>>> SNB+.
>>>
>>> That sounds great. Tiejun could you confirm that with windows driver guys too?
>>>
>>>> --
>>>> Jesse Barnes, Intel Open Source Technology Center
>>> _______________________________________________
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/24 4:54, Konrad Rzeszutek Wilk wrote:
> On Sat, Jul 19, 2014 at 12:27:21AM +0000, Kay, Allen M wrote:
>>> For the MCH PCI registers that do need to be read - can you tell us which ones those are?
>>
>> In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW.   Some of the registers are needed by Ironlake GFX driver which we probably can remove.  I did a trace recently on Broadwell,  the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4).  Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e.
>>
>> 		case 0x00:        /* vendor id */
>> 		case 0x02:        /* device id */
>> 		case 0x08:        /* revision id */
>> 		case 0x2c:        /* sybsystem vendor id */
>> 		case 0x2e:        /* sybsystem id */
>
> Right. We can fix the i915 to use the mechanism that Michael mentioned.
> (see attached RFC patches)
>
>> 		case 0x50:        /* SNB: processor graphics control register */
>> 		case 0x52:        /* processor graphics control register */
>> 		case 0xa0:        /* top of memory */
>> 		case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
>> 		case 0x58:        /* SNB: PAVPC Offset */
>> 		case 0xa4:        /* SNB: graphics base of stolen memory */
>> 		case 0xa8:        /* SNB: base of GTT stolen memory */
>
> I dug in the intel-gtt.c (see ironlake_gtt_driver) to figure out this
> a bit more. As in, I speculated, what if we returned 0 (and not implement
> any support for reading from these registers). What would happen?
>
> 0x52 for Ironlake (g5):
> ------------------
> It looks like intel_gmch_probe is called when i915_gem_gtt_init
> starts (there is a lot of code that looks to be used between
> intel-gtt.c and i915.c).
>
> Anyhow the interesting parts are that i9xx_setup ends up calling
> ioremap the i915 BAR to setup some of these registers for older generations.
>
> Then i965_gtt_total_entries gets which reads 0x52, but it is only
> needed for v5 generation. For other (v4 and G33) it reads it from the GPU's
> 0x2020  register.
>
> If there is a mismatch, it writes to the GPU at 0x2020 to update the
> the size based on the bridge. And then it reads from 0x2020 and that
> is returned and stuck in  intel_private.gtt_total_entries.
>
> So 0x52 in the emulated bridge could be populated with what the
> GPU has at 0x2020. And the writes go in the emulated area.
>
> 0x52 for v6 -> v8:
> -----------------
> We seem to go to gen6_gmch_probe which just figures out the
> the GTT based on the GPU's BAR sizes. The stolen values
> are read from 0x50 from the GPU. So no need to touch the bridge
> (see gen6_gmch_probe)
>
> OK, so no need to have 0x52 or 0x50 in the bridge.
>
> 0xA0:
> ---------
> Could not find any reference in the Linux code. Why would
> Windows driver need this? If we returned the _real_ TOM would
> it matter? Is it used to figure out the device should use 32-bit
> DMA operations or 40-bit?
>
> 0xb0 or 0x5c:
> -------------
> No mention of them in the Linux code.
>
> 0x58, 0xa4, 0xa8:
> -----------------
> No usage of them in the Linux code. We seem to be using the 0x52
> from the bridge and 0x2020 from the GPU for this functionality.
>
>
> So in theory*, if using Ironlake we need to have a proper value
> in 0x52 in the bridge. But for the later chipsets we do not need
> these values (I am assuming that intel_setup_mchbar can safely
> return as it does that for Ironlake and could very well for later
> generations).
>
> Can this be reflected in the Windows driver as well?
>
> P.S.
> *theory: That is assuming we modify the Linux i915_drv.c:intel_detect_pch
> to pick up the id as suggested earlier. See the RFC patches attached.
> (Not compile tested at all!)

I take a look these patches, looks we still scan all PCI Bridge to walk 
all PCHs. So this means we still need to fake a PCI bridge, right? Or 
maybe you don't cover this problem this time.

I prefer we should check dev slot to get that PCH like my previous 
patch, "gpu:drm:i915:intel_detect_pch: back to check devfn instead of 
check class type". Because Windows always use this way, so I think this 
point should be same between Linux and Windows.

Or we need anther better way to unify all OSs.

Thanks
Tiejun

>>
>> Allen
>>
>> -----Original Message-----
>> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
>> Sent: Friday, July 18, 2014 6:45 AM
>> To: Kay, Allen M
>> Cc: Michael S. Tsirkin; Jesse Barnes; peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
>> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
>>
>> On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
>>>> That sounds great. Tiejun could you confirm that with windows driver guys too?
>>>
>>> I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
>>>
>>> I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
>>>
>>
>> For the MCH PCI registers that do need to be read - can you tell us which ones those are?
>>
>> Thank you!
>>> Allen
>>>
>>> -----Original Message-----
>>> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>>> Behalf Of Michael S. Tsirkin
>>> Sent: Thursday, July 03, 2014 1:28 PM
>>> To: Jesse Barnes
>>> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross
>>> Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie;
>>> daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org;
>>> Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano
>>> Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen,
>>> Tiejun
>>> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen:
>>> add Intel IGD passthrough support
>>>
>>> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
>>>> On Thu, 3 Jul 2014 14:26:12 -0400
>>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>>>
>>>>> On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
>>>>>> On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
>>>>>>> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
>>>>>>>> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
>>>>>>>>> With this long thread I lost a bit context about the
>>>>>>>>> challenges that exists. But let me try summarizing it here
>>>>>>>>> - which will hopefully get some consensus.
>>>>>>>>>
>>>>>>>>> 1). Fix IGD hardware to not use Southbridge magic addresses.
>>>>>>>>>     We can moan and moan but I doubt it is going to change.
>>>>>>>>
>>>>>>>> There are two problems:
>>>>>>>>
>>>>>>>> - Northbridge (i.e. MCH i.e. PCI host bridge) configuration
>>>>>>>> space addresses
>>>>>>>
>>>>>>> Right. So in  drivers/gpu/drm/i915/i915_dma.c:
>>>>>>> 1135 #define MCHBAR_I915 0x44
>>>>>>> 1136 #define MCHBAR_I965 0x48
>>>>>>>
>>>>>>> 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>>> 1152         if (INTEL_INFO(dev)->gen >= 4)
>>>>>>> 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi);
>>>>>>> 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);
>>>>>>> 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>> 1139 #define DEVEN_REG 0x54
>>>>>>>
>>>>>>> 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>>> 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {
>>>>>>> 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
>>>>>>> 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);
>>>>>>> 1205         } else {
>>>>>>> 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
>>>>>>> 1207                 enabled = temp & 1;
>>>>>>> 1208         }
>>>>>>>>
>>>>>>>> - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID;
>>>>>>>> some versions of the driver identify it by class, some versions identify it by slot (1f.0).
>>>>>>>
>>>>>>> Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant
>>>>>>> intel_detect_pch which sets the pch_type based on :
>>>>>>>
>>>>>>>   432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>>>   433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>>>   434                         dev_priv->pch_id = id;
>>>>>>>   435
>>>>>>>   436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>>>
>>>>>>> It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
>>>>>>> The INTEL_PCH_DEVICE_ID_MASK is 0xff00
>>>>>>>>
>>>>>>>> To solve the first, make a new machine type, PIIX4-based,
>>>>>>>> and pass through the registers you need.  The patch must
>>>>>>>> document _exactly_ why the registers are safe to pass.  If
>>>>>>>> they are not reserved on PIIX4, the patch must document what
>>>>>>>> the same offsets mean on PIIX4, and why it's sensible to
>>>>>>>> assume that firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
>>>>>>>
>>>>>>> OK. They look to be related to setting up an MBAR , but I
>>>>>>> don't understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
>>>>>>
>>>>>> In particular, I think setting up MBAR should move out of i915
>>>>>> and become the bridge driver tweak on linux and windows.
>>>>>
>>>>> That is an excellent idea.
>>>>>
>>>>> However I am still curious to _why_ it has to be done in the first place.
>>>>
>>>> The display part of the GPU is partly on the PCH, and it's possible
>>>> to mix & match them a bit, so we have this detection code to figure
>>>> things out.  In some cases, the PCH display portion may not even be
>>>> present, so we look for that too.
>>>>
>>>> Practically speaking, we could probably assume specific CPU/PCH
>>>> combos, as I don't think they're generally mixed across generations,
>>>> though SNB and IVB did have compatible sockets, so there is the
>>>> possibility of mixing CPT and PPT PCHs, but those are register
>>>> identical as far as the graphics driver is concerned, so even that should be safe.
>>>>
>>>> Beyond that, the other MCH data we need to look at is mirrored into
>>>> the GPU's MMIO space on current gens.  On older gens, we do need to
>>>> poke at the memory controller a bit to get some info (see
>>>> intel_setup_mchbar()), but that's not true of newer stuff.  Looks
>>>> like we only short circuit that on VLV though; we could probably do
>>>> it on
>>>> SNB+.
>>>
>>> That sounds great. Tiejun could you confirm that with windows driver guys too?
>>>
>>>> --
>>>> Jesse Barnes, Intel Open Source Technology Center
>>> _______________________________________________
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Thu, Jul 24, 2014 at 09:44:41AM +0800, Chen, Tiejun wrote:
> On 2014/7/24 4:54, Konrad Rzeszutek Wilk wrote:
> >On Sat, Jul 19, 2014 at 12:27:21AM +0000, Kay, Allen M wrote:
> >>>For the MCH PCI registers that do need to be read - can you tell us which ones those are?
> >>
> >>In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW.   Some of the registers are needed by Ironlake GFX driver which we probably can remove.  I did a trace recently on Broadwell,  the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4).  Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e.
> >>
> >>		case 0x00:        /* vendor id */
> >>		case 0x02:        /* device id */
> >>		case 0x08:        /* revision id */
> >>		case 0x2c:        /* sybsystem vendor id */
> >>		case 0x2e:        /* sybsystem id */
> >
> >Right. We can fix the i915 to use the mechanism that Michael mentioned.
> >(see attached RFC patches)
> >
> >>		case 0x50:        /* SNB: processor graphics control register */
> >>		case 0x52:        /* processor graphics control register */
> >>		case 0xa0:        /* top of memory */
> >>		case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
> >>		case 0x58:        /* SNB: PAVPC Offset */
> >>		case 0xa4:        /* SNB: graphics base of stolen memory */
> >>		case 0xa8:        /* SNB: base of GTT stolen memory */
> >
> >I dug in the intel-gtt.c (see ironlake_gtt_driver) to figure out this
> >a bit more. As in, I speculated, what if we returned 0 (and not implement
> >any support for reading from these registers). What would happen?
> >
> >0x52 for Ironlake (g5):
> >------------------
> >It looks like intel_gmch_probe is called when i915_gem_gtt_init
> >starts (there is a lot of code that looks to be used between
> >intel-gtt.c and i915.c).
> >
> >Anyhow the interesting parts are that i9xx_setup ends up calling
> >ioremap the i915 BAR to setup some of these registers for older generations.
> >
> >Then i965_gtt_total_entries gets which reads 0x52, but it is only
> >needed for v5 generation. For other (v4 and G33) it reads it from the GPU's
> >0x2020  register.
> >
> >If there is a mismatch, it writes to the GPU at 0x2020 to update the
> >the size based on the bridge. And then it reads from 0x2020 and that
> >is returned and stuck in  intel_private.gtt_total_entries.
> >
> >So 0x52 in the emulated bridge could be populated with what the
> >GPU has at 0x2020. And the writes go in the emulated area.
> >
> >0x52 for v6 -> v8:
> >-----------------
> >We seem to go to gen6_gmch_probe which just figures out the
> >the GTT based on the GPU's BAR sizes. The stolen values
> >are read from 0x50 from the GPU. So no need to touch the bridge
> >(see gen6_gmch_probe)
> >
> >OK, so no need to have 0x52 or 0x50 in the bridge.
> >
> >0xA0:
> >---------
> >Could not find any reference in the Linux code. Why would
> >Windows driver need this? If we returned the _real_ TOM would
> >it matter? Is it used to figure out the device should use 32-bit
> >DMA operations or 40-bit?
> >
> >0xb0 or 0x5c:
> >-------------
> >No mention of them in the Linux code.
> >
> >0x58, 0xa4, 0xa8:
> >-----------------
> >No usage of them in the Linux code. We seem to be using the 0x52
> >from the bridge and 0x2020 from the GPU for this functionality.
> >
> >
> >So in theory*, if using Ironlake we need to have a proper value
> >in 0x52 in the bridge. But for the later chipsets we do not need
> >these values (I am assuming that intel_setup_mchbar can safely
> >return as it does that for Ironlake and could very well for later
> >generations).
> >
> >Can this be reflected in the Windows driver as well?
> >
> >P.S.
> >*theory: That is assuming we modify the Linux i915_drv.c:intel_detect_pch
> >to pick up the id as suggested earlier. See the RFC patches attached.
> >(Not compile tested at all!)
> 
> I take a look these patches, looks we still scan all PCI Bridge to walk all
> PCHs. So this means we still need to fake a PCI bridge, right? Or maybe you
> don't cover this problem this time.

I totally forgot. Feel free to fix that.
> 
> I prefer we should check dev slot to get that PCH like my previous patch,

Uh? Your patch was checking for 0:1f.0, not the slot of the device.

(see https://lkml.org/lkml/2014/6/19/121)
> "gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class
> type". Because Windows always use this way, so I think this point should be
> same between Linux and Windows.

Didn't we discuss that we did not want to pass in PCH at all if we can?

And from the observation I made above it seems that we can safely do it
under Linux. With Windows I don't know - but I presume the answer is yes too.


> 
> Or we need anther better way to unify all OSs.

Yes. The observation is that a lot of these registers are aliased in the GPU.
As such we can skip some of this bridge poking. Hm. I should have gotten
further and also done this on baremetal, but figured as an RFC it would
paint a picture of what we had in mind?

> 
> Thanks
> Tiejun
> 
> >>
> >>Allen
> >>
> >>-----Original Message-----
> >>From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> >>Sent: Friday, July 18, 2014 6:45 AM
> >>To: Kay, Allen M
> >>Cc: Michael S. Tsirkin; Jesse Barnes; peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
> >>Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
> >>
> >>On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
> >>>>That sounds great. Tiejun could you confirm that with windows driver guys too?
> >>>
> >>>I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
> >>>
> >>>I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
> >>>
> >>
> >>For the MCH PCI registers that do need to be read - can you tell us which ones those are?
> >>
> >>Thank you!
> >>>Allen
> >>>
> >>>-----Original Message-----
> >>>From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
> >>>Behalf Of Michael S. Tsirkin
> >>>Sent: Thursday, July 03, 2014 1:28 PM
> >>>To: Jesse Barnes
> >>>Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross
> >>>Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie;
> >>>daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org;
> >>>Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano
> >>>Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen,
> >>>Tiejun
> >>>Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen:
> >>>add Intel IGD passthrough support
> >>>
> >>>On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> >>>>On Thu, 3 Jul 2014 14:26:12 -0400
> >>>>Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >>>>
> >>>>>On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> >>>>>>On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> >>>>>>>On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> >>>>>>>>Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> >>>>>>>>>With this long thread I lost a bit context about the
> >>>>>>>>>challenges that exists. But let me try summarizing it here
> >>>>>>>>>- which will hopefully get some consensus.
> >>>>>>>>>
> >>>>>>>>>1). Fix IGD hardware to not use Southbridge magic addresses.
> >>>>>>>>>    We can moan and moan but I doubt it is going to change.
> >>>>>>>>
> >>>>>>>>There are two problems:
> >>>>>>>>
> >>>>>>>>- Northbridge (i.e. MCH i.e. PCI host bridge) configuration
> >>>>>>>>space addresses
> >>>>>>>
> >>>>>>>Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> >>>>>>>1135 #define MCHBAR_I915 0x44
> >>>>>>>1136 #define MCHBAR_I965 0x48
> >>>>>>>
> >>>>>>>1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
> >>>>>>>1152         if (INTEL_INFO(dev)->gen >= 4)
> >>>>>>>1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi);
> >>>>>>>1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);
> >>>>>>>1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
> >>>>>>>
> >>>>>>>and
> >>>>>>>
> >>>>>>>1139 #define DEVEN_REG 0x54
> >>>>>>>
> >>>>>>>1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
> >>>>>>>1202         if (IS_I915G(dev) || IS_I915GM(dev)) {
> >>>>>>>1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
> >>>>>>>1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);
> >>>>>>>1205         } else {
> >>>>>>>1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
> >>>>>>>1207                 enabled = temp & 1;
> >>>>>>>1208         }
> >>>>>>>>
> >>>>>>>>- Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID;
> >>>>>>>>some versions of the driver identify it by class, some versions identify it by slot (1f.0).
> >>>>>>>
> >>>>>>>Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant
> >>>>>>>intel_detect_pch which sets the pch_type based on :
> >>>>>>>
> >>>>>>>  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> >>>>>>>  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >>>>>>>  434                         dev_priv->pch_id = id;
> >>>>>>>  435
> >>>>>>>  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >>>>>>>
> >>>>>>>It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> >>>>>>>The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> >>>>>>>>
> >>>>>>>>To solve the first, make a new machine type, PIIX4-based,
> >>>>>>>>and pass through the registers you need.  The patch must
> >>>>>>>>document _exactly_ why the registers are safe to pass.  If
> >>>>>>>>they are not reserved on PIIX4, the patch must document what
> >>>>>>>>the same offsets mean on PIIX4, and why it's sensible to
> >>>>>>>>assume that firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
> >>>>>>>
> >>>>>>>OK. They look to be related to setting up an MBAR , but I
> >>>>>>>don't understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> >>>>>>
> >>>>>>In particular, I think setting up MBAR should move out of i915
> >>>>>>and become the bridge driver tweak on linux and windows.
> >>>>>
> >>>>>That is an excellent idea.
> >>>>>
> >>>>>However I am still curious to _why_ it has to be done in the first place.
> >>>>
> >>>>The display part of the GPU is partly on the PCH, and it's possible
> >>>>to mix & match them a bit, so we have this detection code to figure
> >>>>things out.  In some cases, the PCH display portion may not even be
> >>>>present, so we look for that too.
> >>>>
> >>>>Practically speaking, we could probably assume specific CPU/PCH
> >>>>combos, as I don't think they're generally mixed across generations,
> >>>>though SNB and IVB did have compatible sockets, so there is the
> >>>>possibility of mixing CPT and PPT PCHs, but those are register
> >>>>identical as far as the graphics driver is concerned, so even that should be safe.
> >>>>
> >>>>Beyond that, the other MCH data we need to look at is mirrored into
> >>>>the GPU's MMIO space on current gens.  On older gens, we do need to
> >>>>poke at the memory controller a bit to get some info (see
> >>>>intel_setup_mchbar()), but that's not true of newer stuff.  Looks
> >>>>like we only short circuit that on VLV though; we could probably do
> >>>>it on
> >>>>SNB+.
> >>>
> >>>That sounds great. Tiejun could you confirm that with windows driver guys too?
> >>>
> >>>>--
> >>>>Jesse Barnes, Intel Open Source Technology Center
> >>>_______________________________________________
> >>>Intel-gfx mailing list
> >>>Intel-gfx@lists.freedesktop.org
> >>>http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Thu, Jul 24, 2014 at 09:44:41AM +0800, Chen, Tiejun wrote:
> On 2014/7/24 4:54, Konrad Rzeszutek Wilk wrote:
> >On Sat, Jul 19, 2014 at 12:27:21AM +0000, Kay, Allen M wrote:
> >>>For the MCH PCI registers that do need to be read - can you tell us which ones those are?
> >>
> >>In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW.   Some of the registers are needed by Ironlake GFX driver which we probably can remove.  I did a trace recently on Broadwell,  the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4).  Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e.
> >>
> >>		case 0x00:        /* vendor id */
> >>		case 0x02:        /* device id */
> >>		case 0x08:        /* revision id */
> >>		case 0x2c:        /* sybsystem vendor id */
> >>		case 0x2e:        /* sybsystem id */
> >
> >Right. We can fix the i915 to use the mechanism that Michael mentioned.
> >(see attached RFC patches)
> >
> >>		case 0x50:        /* SNB: processor graphics control register */
> >>		case 0x52:        /* processor graphics control register */
> >>		case 0xa0:        /* top of memory */
> >>		case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
> >>		case 0x58:        /* SNB: PAVPC Offset */
> >>		case 0xa4:        /* SNB: graphics base of stolen memory */
> >>		case 0xa8:        /* SNB: base of GTT stolen memory */
> >
> >I dug in the intel-gtt.c (see ironlake_gtt_driver) to figure out this
> >a bit more. As in, I speculated, what if we returned 0 (and not implement
> >any support for reading from these registers). What would happen?
> >
> >0x52 for Ironlake (g5):
> >------------------
> >It looks like intel_gmch_probe is called when i915_gem_gtt_init
> >starts (there is a lot of code that looks to be used between
> >intel-gtt.c and i915.c).
> >
> >Anyhow the interesting parts are that i9xx_setup ends up calling
> >ioremap the i915 BAR to setup some of these registers for older generations.
> >
> >Then i965_gtt_total_entries gets which reads 0x52, but it is only
> >needed for v5 generation. For other (v4 and G33) it reads it from the GPU's
> >0x2020  register.
> >
> >If there is a mismatch, it writes to the GPU at 0x2020 to update the
> >the size based on the bridge. And then it reads from 0x2020 and that
> >is returned and stuck in  intel_private.gtt_total_entries.
> >
> >So 0x52 in the emulated bridge could be populated with what the
> >GPU has at 0x2020. And the writes go in the emulated area.
> >
> >0x52 for v6 -> v8:
> >-----------------
> >We seem to go to gen6_gmch_probe which just figures out the
> >the GTT based on the GPU's BAR sizes. The stolen values
> >are read from 0x50 from the GPU. So no need to touch the bridge
> >(see gen6_gmch_probe)
> >
> >OK, so no need to have 0x52 or 0x50 in the bridge.
> >
> >0xA0:
> >---------
> >Could not find any reference in the Linux code. Why would
> >Windows driver need this? If we returned the _real_ TOM would
> >it matter? Is it used to figure out the device should use 32-bit
> >DMA operations or 40-bit?
> >
> >0xb0 or 0x5c:
> >-------------
> >No mention of them in the Linux code.
> >
> >0x58, 0xa4, 0xa8:
> >-----------------
> >No usage of them in the Linux code. We seem to be using the 0x52
> >from the bridge and 0x2020 from the GPU for this functionality.
> >
> >
> >So in theory*, if using Ironlake we need to have a proper value
> >in 0x52 in the bridge. But for the later chipsets we do not need
> >these values (I am assuming that intel_setup_mchbar can safely
> >return as it does that for Ironlake and could very well for later
> >generations).
> >
> >Can this be reflected in the Windows driver as well?
> >
> >P.S.
> >*theory: That is assuming we modify the Linux i915_drv.c:intel_detect_pch
> >to pick up the id as suggested earlier. See the RFC patches attached.
> >(Not compile tested at all!)
> 
> I take a look these patches, looks we still scan all PCI Bridge to walk all
> PCHs. So this means we still need to fake a PCI bridge, right? Or maybe you
> don't cover this problem this time.

I totally forgot. Feel free to fix that.
> 
> I prefer we should check dev slot to get that PCH like my previous patch,

Uh? Your patch was checking for 0:1f.0, not the slot of the device.

(see https://lkml.org/lkml/2014/6/19/121)
> "gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class
> type". Because Windows always use this way, so I think this point should be
> same between Linux and Windows.

Didn't we discuss that we did not want to pass in PCH at all if we can?

And from the observation I made above it seems that we can safely do it
under Linux. With Windows I don't know - but I presume the answer is yes too.


> 
> Or we need anther better way to unify all OSs.

Yes. The observation is that a lot of these registers are aliased in the GPU.
As such we can skip some of this bridge poking. Hm. I should have gotten
further and also done this on baremetal, but figured as an RFC it would
paint a picture of what we had in mind?

> 
> Thanks
> Tiejun
> 
> >>
> >>Allen
> >>
> >>-----Original Message-----
> >>From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> >>Sent: Friday, July 18, 2014 6:45 AM
> >>To: Kay, Allen M
> >>Cc: Michael S. Tsirkin; Jesse Barnes; peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
> >>Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
> >>
> >>On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
> >>>>That sounds great. Tiejun could you confirm that with windows driver guys too?
> >>>
> >>>I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
> >>>
> >>>I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
> >>>
> >>
> >>For the MCH PCI registers that do need to be read - can you tell us which ones those are?
> >>
> >>Thank you!
> >>>Allen
> >>>
> >>>-----Original Message-----
> >>>From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
> >>>Behalf Of Michael S. Tsirkin
> >>>Sent: Thursday, July 03, 2014 1:28 PM
> >>>To: Jesse Barnes
> >>>Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross
> >>>Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie;
> >>>daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org;
> >>>Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano
> >>>Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen,
> >>>Tiejun
> >>>Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen:
> >>>add Intel IGD passthrough support
> >>>
> >>>On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
> >>>>On Thu, 3 Jul 2014 14:26:12 -0400
> >>>>Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >>>>
> >>>>>On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
> >>>>>>On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> >>>>>>>On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> >>>>>>>>Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> >>>>>>>>>With this long thread I lost a bit context about the
> >>>>>>>>>challenges that exists. But let me try summarizing it here
> >>>>>>>>>- which will hopefully get some consensus.
> >>>>>>>>>
> >>>>>>>>>1). Fix IGD hardware to not use Southbridge magic addresses.
> >>>>>>>>>    We can moan and moan but I doubt it is going to change.
> >>>>>>>>
> >>>>>>>>There are two problems:
> >>>>>>>>
> >>>>>>>>- Northbridge (i.e. MCH i.e. PCI host bridge) configuration
> >>>>>>>>space addresses
> >>>>>>>
> >>>>>>>Right. So in  drivers/gpu/drm/i915/i915_dma.c:
> >>>>>>>1135 #define MCHBAR_I915 0x44
> >>>>>>>1136 #define MCHBAR_I965 0x48
> >>>>>>>
> >>>>>>>1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
> >>>>>>>1152         if (INTEL_INFO(dev)->gen >= 4)
> >>>>>>>1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi);
> >>>>>>>1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);
> >>>>>>>1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
> >>>>>>>
> >>>>>>>and
> >>>>>>>
> >>>>>>>1139 #define DEVEN_REG 0x54
> >>>>>>>
> >>>>>>>1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
> >>>>>>>1202         if (IS_I915G(dev) || IS_I915GM(dev)) {
> >>>>>>>1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
> >>>>>>>1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);
> >>>>>>>1205         } else {
> >>>>>>>1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
> >>>>>>>1207                 enabled = temp & 1;
> >>>>>>>1208         }
> >>>>>>>>
> >>>>>>>>- Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID;
> >>>>>>>>some versions of the driver identify it by class, some versions identify it by slot (1f.0).
> >>>>>>>
> >>>>>>>Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant
> >>>>>>>intel_detect_pch which sets the pch_type based on :
> >>>>>>>
> >>>>>>>  432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
> >>>>>>>  433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
> >>>>>>>  434                         dev_priv->pch_id = id;
> >>>>>>>  435
> >>>>>>>  436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
> >>>>>>>
> >>>>>>>It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
> >>>>>>>The INTEL_PCH_DEVICE_ID_MASK is 0xff00
> >>>>>>>>
> >>>>>>>>To solve the first, make a new machine type, PIIX4-based,
> >>>>>>>>and pass through the registers you need.  The patch must
> >>>>>>>>document _exactly_ why the registers are safe to pass.  If
> >>>>>>>>they are not reserved on PIIX4, the patch must document what
> >>>>>>>>the same offsets mean on PIIX4, and why it's sensible to
> >>>>>>>>assume that firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
> >>>>>>>
> >>>>>>>OK. They look to be related to setting up an MBAR , but I
> >>>>>>>don't understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
> >>>>>>
> >>>>>>In particular, I think setting up MBAR should move out of i915
> >>>>>>and become the bridge driver tweak on linux and windows.
> >>>>>
> >>>>>That is an excellent idea.
> >>>>>
> >>>>>However I am still curious to _why_ it has to be done in the first place.
> >>>>
> >>>>The display part of the GPU is partly on the PCH, and it's possible
> >>>>to mix & match them a bit, so we have this detection code to figure
> >>>>things out.  In some cases, the PCH display portion may not even be
> >>>>present, so we look for that too.
> >>>>
> >>>>Practically speaking, we could probably assume specific CPU/PCH
> >>>>combos, as I don't think they're generally mixed across generations,
> >>>>though SNB and IVB did have compatible sockets, so there is the
> >>>>possibility of mixing CPT and PPT PCHs, but those are register
> >>>>identical as far as the graphics driver is concerned, so even that should be safe.
> >>>>
> >>>>Beyond that, the other MCH data we need to look at is mirrored into
> >>>>the GPU's MMIO space on current gens.  On older gens, we do need to
> >>>>poke at the memory controller a bit to get some info (see
> >>>>intel_setup_mchbar()), but that's not true of newer stuff.  Looks
> >>>>like we only short circuit that on VLV though; we could probably do
> >>>>it on
> >>>>SNB+.
> >>>
> >>>That sounds great. Tiejun could you confirm that with windows driver guys too?
> >>>
> >>>>--
> >>>>Jesse Barnes, Intel Open Source Technology Center
> >>>_______________________________________________
> >>>Intel-gfx mailing list
> >>>Intel-gfx@lists.freedesktop.org
> >>>http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/26 1:01, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 24, 2014 at 09:44:41AM +0800, Chen, Tiejun wrote:
>> On 2014/7/24 4:54, Konrad Rzeszutek Wilk wrote:
>>> On Sat, Jul 19, 2014 at 12:27:21AM +0000, Kay, Allen M wrote:
>>>>> For the MCH PCI registers that do need to be read - can you tell us which ones those are?
>>>>
>>>> In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW.   Some of the registers are needed by Ironlake GFX driver which we probably can remove.  I did a trace recently on Broadwell,  the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4).  Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e.
>>>>
>>>> 		case 0x00:        /* vendor id */
>>>> 		case 0x02:        /* device id */
>>>> 		case 0x08:        /* revision id */
>>>> 		case 0x2c:        /* sybsystem vendor id */
>>>> 		case 0x2e:        /* sybsystem id */
>>>
>>> Right. We can fix the i915 to use the mechanism that Michael mentioned.
>>> (see attached RFC patches)
>>>
>>>> 		case 0x50:        /* SNB: processor graphics control register */
>>>> 		case 0x52:        /* processor graphics control register */
>>>> 		case 0xa0:        /* top of memory */
>>>> 		case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
>>>> 		case 0x58:        /* SNB: PAVPC Offset */
>>>> 		case 0xa4:        /* SNB: graphics base of stolen memory */
>>>> 		case 0xa8:        /* SNB: base of GTT stolen memory */
>>>
>>> I dug in the intel-gtt.c (see ironlake_gtt_driver) to figure out this
>>> a bit more. As in, I speculated, what if we returned 0 (and not implement
>>> any support for reading from these registers). What would happen?
>>>
>>> 0x52 for Ironlake (g5):
>>> ------------------
>>> It looks like intel_gmch_probe is called when i915_gem_gtt_init
>>> starts (there is a lot of code that looks to be used between
>>> intel-gtt.c and i915.c).
>>>
>>> Anyhow the interesting parts are that i9xx_setup ends up calling
>>> ioremap the i915 BAR to setup some of these registers for older generations.
>>>
>>> Then i965_gtt_total_entries gets which reads 0x52, but it is only
>>> needed for v5 generation. For other (v4 and G33) it reads it from the GPU's
>>> 0x2020  register.
>>>
>>> If there is a mismatch, it writes to the GPU at 0x2020 to update the
>>> the size based on the bridge. And then it reads from 0x2020 and that
>>> is returned and stuck in  intel_private.gtt_total_entries.
>>>
>>> So 0x52 in the emulated bridge could be populated with what the
>>> GPU has at 0x2020. And the writes go in the emulated area.
>>>
>>> 0x52 for v6 -> v8:
>>> -----------------
>>> We seem to go to gen6_gmch_probe which just figures out the
>>> the GTT based on the GPU's BAR sizes. The stolen values
>>> are read from 0x50 from the GPU. So no need to touch the bridge
>>> (see gen6_gmch_probe)
>>>
>>> OK, so no need to have 0x52 or 0x50 in the bridge.
>>>
>>> 0xA0:
>>> ---------
>>> Could not find any reference in the Linux code. Why would
>>> Windows driver need this? If we returned the _real_ TOM would
>>> it matter? Is it used to figure out the device should use 32-bit
>>> DMA operations or 40-bit?
>>>
>>> 0xb0 or 0x5c:
>>> -------------
>>> No mention of them in the Linux code.
>>>
>>> 0x58, 0xa4, 0xa8:
>>> -----------------
>>> No usage of them in the Linux code. We seem to be using the 0x52
>> >from the bridge and 0x2020 from the GPU for this functionality.
>>>
>>>
>>> So in theory*, if using Ironlake we need to have a proper value
>>> in 0x52 in the bridge. But for the later chipsets we do not need
>>> these values (I am assuming that intel_setup_mchbar can safely
>>> return as it does that for Ironlake and could very well for later
>>> generations).
>>>
>>> Can this be reflected in the Windows driver as well?
>>>
>>> P.S.
>>> *theory: That is assuming we modify the Linux i915_drv.c:intel_detect_pch
>>> to pick up the id as suggested earlier. See the RFC patches attached.
>>> (Not compile tested at all!)
>>
>> I take a look these patches, looks we still scan all PCI Bridge to walk all
>> PCHs. So this means we still need to fake a PCI bridge, right? Or maybe you
>> don't cover this problem this time.
>
> I totally forgot. Feel free to fix that.
>>

Sorry for this delay response.

>> I prefer we should check dev slot to get that PCH like my previous patch,
>
> Uh? Your patch was checking for 0:1f.0, not the slot of the device.

Yes.

>
> (see https://lkml.org/lkml/2014/6/19/121)
>> "gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class
>> type". Because Windows always use this way, so I think this point should be
>> same between Linux and Windows.
>
> Didn't we discuss that we did not want to pass in PCH at all if we can?

I'm a bit confused since I guess I'm missing something important in this 
long discussion. I guess we just fake a simple PCIe device but just has 
PCI_VENDOR_ID_XEN/Real_PCH_Device_ID, and then well probe such a PCIe 
device inside intel_detect_pch(), right?

And this means we will not support those existing drivers?

>
> And from the observation I made above it seems that we can safely do it
> under Linux. With Windows I don't know - but I presume the answer is yes too.
>
>
>>
>> Or we need anther better way to unify all OSs.
>
> Yes. The observation is that a lot of these registers are aliased in the GPU.
> As such we can skip some of this bridge poking. Hm. I should have gotten

Sounds reasonable but I'm not an Windows/Linux GFX driver developer, so 
I think we need to wait Allen to double check these points.

Thanks
Tiejun

> further and also done this on baremetal, but figured as an RFC it would
> paint a picture of what we had in mind?
>
>>
>> Thanks
>> Tiejun
>>
>>>>
>>>> Allen
>>>>
>>>> -----Original Message-----
>>>> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
>>>> Sent: Friday, July 18, 2014 6:45 AM
>>>> To: Kay, Allen M
>>>> Cc: Michael S. Tsirkin; Jesse Barnes; peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
>>>> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
>>>>
>>>> On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
>>>>>> That sounds great. Tiejun could you confirm that with windows driver guys too?
>>>>>
>>>>> I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
>>>>>
>>>>> I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
>>>>>
>>>>
>>>> For the MCH PCI registers that do need to be read - can you tell us which ones those are?
>>>>
>>>> Thank you!
>>>>> Allen
>>>>>
>>>>> -----Original Message-----
>>>>> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>>>>> Behalf Of Michael S. Tsirkin
>>>>> Sent: Thursday, July 03, 2014 1:28 PM
>>>>> To: Jesse Barnes
>>>>> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross
>>>>> Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie;
>>>>> daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org;
>>>>> Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano
>>>>> Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen,
>>>>> Tiejun
>>>>> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen:
>>>>> add Intel IGD passthrough support
>>>>>
>>>>> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
>>>>>> On Thu, 3 Jul 2014 14:26:12 -0400
>>>>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>>>>>
>>>>>>> On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
>>>>>>>> On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
>>>>>>>>> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
>>>>>>>>>> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
>>>>>>>>>>> With this long thread I lost a bit context about the
>>>>>>>>>>> challenges that exists. But let me try summarizing it here
>>>>>>>>>>> - which will hopefully get some consensus.
>>>>>>>>>>>
>>>>>>>>>>> 1). Fix IGD hardware to not use Southbridge magic addresses.
>>>>>>>>>>>     We can moan and moan but I doubt it is going to change.
>>>>>>>>>>
>>>>>>>>>> There are two problems:
>>>>>>>>>>
>>>>>>>>>> - Northbridge (i.e. MCH i.e. PCI host bridge) configuration
>>>>>>>>>> space addresses
>>>>>>>>>
>>>>>>>>> Right. So in  drivers/gpu/drm/i915/i915_dma.c:
>>>>>>>>> 1135 #define MCHBAR_I915 0x44
>>>>>>>>> 1136 #define MCHBAR_I965 0x48
>>>>>>>>>
>>>>>>>>> 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>>>>> 1152         if (INTEL_INFO(dev)->gen >= 4)
>>>>>>>>> 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi);
>>>>>>>>> 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);
>>>>>>>>> 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> 1139 #define DEVEN_REG 0x54
>>>>>>>>>
>>>>>>>>> 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>>>>> 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {
>>>>>>>>> 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
>>>>>>>>> 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);
>>>>>>>>> 1205         } else {
>>>>>>>>> 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
>>>>>>>>> 1207                 enabled = temp & 1;
>>>>>>>>> 1208         }
>>>>>>>>>>
>>>>>>>>>> - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID;
>>>>>>>>>> some versions of the driver identify it by class, some versions identify it by slot (1f.0).
>>>>>>>>>
>>>>>>>>> Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant
>>>>>>>>> intel_detect_pch which sets the pch_type based on :
>>>>>>>>>
>>>>>>>>>   432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>>>>>   433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>>>>>   434                         dev_priv->pch_id = id;
>>>>>>>>>   435
>>>>>>>>>   436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>>>>>
>>>>>>>>> It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
>>>>>>>>> The INTEL_PCH_DEVICE_ID_MASK is 0xff00
>>>>>>>>>>
>>>>>>>>>> To solve the first, make a new machine type, PIIX4-based,
>>>>>>>>>> and pass through the registers you need.  The patch must
>>>>>>>>>> document _exactly_ why the registers are safe to pass.  If
>>>>>>>>>> they are not reserved on PIIX4, the patch must document what
>>>>>>>>>> the same offsets mean on PIIX4, and why it's sensible to
>>>>>>>>>> assume that firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
>>>>>>>>>
>>>>>>>>> OK. They look to be related to setting up an MBAR , but I
>>>>>>>>> don't understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
>>>>>>>>
>>>>>>>> In particular, I think setting up MBAR should move out of i915
>>>>>>>> and become the bridge driver tweak on linux and windows.
>>>>>>>
>>>>>>> That is an excellent idea.
>>>>>>>
>>>>>>> However I am still curious to _why_ it has to be done in the first place.
>>>>>>
>>>>>> The display part of the GPU is partly on the PCH, and it's possible
>>>>>> to mix & match them a bit, so we have this detection code to figure
>>>>>> things out.  In some cases, the PCH display portion may not even be
>>>>>> present, so we look for that too.
>>>>>>
>>>>>> Practically speaking, we could probably assume specific CPU/PCH
>>>>>> combos, as I don't think they're generally mixed across generations,
>>>>>> though SNB and IVB did have compatible sockets, so there is the
>>>>>> possibility of mixing CPT and PPT PCHs, but those are register
>>>>>> identical as far as the graphics driver is concerned, so even that should be safe.
>>>>>>
>>>>>> Beyond that, the other MCH data we need to look at is mirrored into
>>>>>> the GPU's MMIO space on current gens.  On older gens, we do need to
>>>>>> poke at the memory controller a bit to get some info (see
>>>>>> intel_setup_mchbar()), but that's not true of newer stuff.  Looks
>>>>>> like we only short circuit that on VLV though; we could probably do
>>>>>> it on
>>>>>> SNB+.
>>>>>
>>>>> That sounds great. Tiejun could you confirm that with windows driver guys too?
>>>>>
>>>>>> --
>>>>>> Jesse Barnes, Intel Open Source Technology Center
>>>>> _______________________________________________
>>>>> Intel-gfx mailing list
>>>>> Intel-gfx@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/26 1:01, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 24, 2014 at 09:44:41AM +0800, Chen, Tiejun wrote:
>> On 2014/7/24 4:54, Konrad Rzeszutek Wilk wrote:
>>> On Sat, Jul 19, 2014 at 12:27:21AM +0000, Kay, Allen M wrote:
>>>>> For the MCH PCI registers that do need to be read - can you tell us which ones those are?
>>>>
>>>> In qemu/hw/xen_pt_igd.c/igd_pci_read(), following MCH PCI config register reads are passthrough to the host HW.   Some of the registers are needed by Ironlake GFX driver which we probably can remove.  I did a trace recently on Broadwell,  the number of register accessed are even smaller (0, 2, 2c, 2e, 50, 52, a0, a4).  Given that we now have integrated MCH and GPU in the same socket, looks like driver can easily remove reads for offsets 0 - 0x2e.
>>>>
>>>> 		case 0x00:        /* vendor id */
>>>> 		case 0x02:        /* device id */
>>>> 		case 0x08:        /* revision id */
>>>> 		case 0x2c:        /* sybsystem vendor id */
>>>> 		case 0x2e:        /* sybsystem id */
>>>
>>> Right. We can fix the i915 to use the mechanism that Michael mentioned.
>>> (see attached RFC patches)
>>>
>>>> 		case 0x50:        /* SNB: processor graphics control register */
>>>> 		case 0x52:        /* processor graphics control register */
>>>> 		case 0xa0:        /* top of memory */
>>>> 		case 0xb0:        /* ILK: BSM: should read from dev 2 offset 0x5c */
>>>> 		case 0x58:        /* SNB: PAVPC Offset */
>>>> 		case 0xa4:        /* SNB: graphics base of stolen memory */
>>>> 		case 0xa8:        /* SNB: base of GTT stolen memory */
>>>
>>> I dug in the intel-gtt.c (see ironlake_gtt_driver) to figure out this
>>> a bit more. As in, I speculated, what if we returned 0 (and not implement
>>> any support for reading from these registers). What would happen?
>>>
>>> 0x52 for Ironlake (g5):
>>> ------------------
>>> It looks like intel_gmch_probe is called when i915_gem_gtt_init
>>> starts (there is a lot of code that looks to be used between
>>> intel-gtt.c and i915.c).
>>>
>>> Anyhow the interesting parts are that i9xx_setup ends up calling
>>> ioremap the i915 BAR to setup some of these registers for older generations.
>>>
>>> Then i965_gtt_total_entries gets which reads 0x52, but it is only
>>> needed for v5 generation. For other (v4 and G33) it reads it from the GPU's
>>> 0x2020  register.
>>>
>>> If there is a mismatch, it writes to the GPU at 0x2020 to update the
>>> the size based on the bridge. And then it reads from 0x2020 and that
>>> is returned and stuck in  intel_private.gtt_total_entries.
>>>
>>> So 0x52 in the emulated bridge could be populated with what the
>>> GPU has at 0x2020. And the writes go in the emulated area.
>>>
>>> 0x52 for v6 -> v8:
>>> -----------------
>>> We seem to go to gen6_gmch_probe which just figures out the
>>> the GTT based on the GPU's BAR sizes. The stolen values
>>> are read from 0x50 from the GPU. So no need to touch the bridge
>>> (see gen6_gmch_probe)
>>>
>>> OK, so no need to have 0x52 or 0x50 in the bridge.
>>>
>>> 0xA0:
>>> ---------
>>> Could not find any reference in the Linux code. Why would
>>> Windows driver need this? If we returned the _real_ TOM would
>>> it matter? Is it used to figure out the device should use 32-bit
>>> DMA operations or 40-bit?
>>>
>>> 0xb0 or 0x5c:
>>> -------------
>>> No mention of them in the Linux code.
>>>
>>> 0x58, 0xa4, 0xa8:
>>> -----------------
>>> No usage of them in the Linux code. We seem to be using the 0x52
>> >from the bridge and 0x2020 from the GPU for this functionality.
>>>
>>>
>>> So in theory*, if using Ironlake we need to have a proper value
>>> in 0x52 in the bridge. But for the later chipsets we do not need
>>> these values (I am assuming that intel_setup_mchbar can safely
>>> return as it does that for Ironlake and could very well for later
>>> generations).
>>>
>>> Can this be reflected in the Windows driver as well?
>>>
>>> P.S.
>>> *theory: That is assuming we modify the Linux i915_drv.c:intel_detect_pch
>>> to pick up the id as suggested earlier. See the RFC patches attached.
>>> (Not compile tested at all!)
>>
>> I take a look these patches, looks we still scan all PCI Bridge to walk all
>> PCHs. So this means we still need to fake a PCI bridge, right? Or maybe you
>> don't cover this problem this time.
>
> I totally forgot. Feel free to fix that.
>>

Sorry for this delay response.

>> I prefer we should check dev slot to get that PCH like my previous patch,
>
> Uh? Your patch was checking for 0:1f.0, not the slot of the device.

Yes.

>
> (see https://lkml.org/lkml/2014/6/19/121)
>> "gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class
>> type". Because Windows always use this way, so I think this point should be
>> same between Linux and Windows.
>
> Didn't we discuss that we did not want to pass in PCH at all if we can?

I'm a bit confused since I guess I'm missing something important in this 
long discussion. I guess we just fake a simple PCIe device but just has 
PCI_VENDOR_ID_XEN/Real_PCH_Device_ID, and then well probe such a PCIe 
device inside intel_detect_pch(), right?

And this means we will not support those existing drivers?

>
> And from the observation I made above it seems that we can safely do it
> under Linux. With Windows I don't know - but I presume the answer is yes too.
>
>
>>
>> Or we need anther better way to unify all OSs.
>
> Yes. The observation is that a lot of these registers are aliased in the GPU.
> As such we can skip some of this bridge poking. Hm. I should have gotten

Sounds reasonable but I'm not an Windows/Linux GFX driver developer, so 
I think we need to wait Allen to double check these points.

Thanks
Tiejun

> further and also done this on baremetal, but figured as an RFC it would
> paint a picture of what we had in mind?
>
>>
>> Thanks
>> Tiejun
>>
>>>>
>>>> Allen
>>>>
>>>> -----Original Message-----
>>>> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
>>>> Sent: Friday, July 18, 2014 6:45 AM
>>>> To: Kay, Allen M
>>>> Cc: Michael S. Tsirkin; Jesse Barnes; peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross Philipson; airlied@linux.ie; daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen, Tiejun
>>>> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
>>>>
>>>> On Thu, Jul 17, 2014 at 05:37:12PM +0000, Kay, Allen M wrote:
>>>>>> That sounds great. Tiejun could you confirm that with windows driver guys too?
>>>>>
>>>>> I believe windows driver can also assume specific CPU/PCH combos.  I will discuss this with native Windows driver guys.  Preferably, the same code path can be used for both native and virtualization cases to avoid frequent breakage as most developers and QA do not test new code changes in virtualization environment.
>>>>>
>>>>> I have verified that Windows driver do not need to write to any MCH PCI registers on HSW/BDW so the PCI write function can be removed.  The  MCH PCI registers that need to be read, we are working with HW team to get them mirrored in GPU MMIO registers in future HW.
>>>>>
>>>>
>>>> For the MCH PCI registers that do need to be read - can you tell us which ones those are?
>>>>
>>>> Thank you!
>>>>> Allen
>>>>>
>>>>> -----Original Message-----
>>>>> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>>>>> Behalf Of Michael S. Tsirkin
>>>>> Sent: Thursday, July 03, 2014 1:28 PM
>>>>> To: Jesse Barnes
>>>>> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Ross
>>>>> Philipson; Konrad Rzeszutek Wilk; airlied@linux.ie;
>>>>> daniel.vetter@ffwll.ch; intel-gfx@lists.freedesktop.org;
>>>>> Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; Anthony Perard; Stefano
>>>>> Stabellini; anthony@codemonkey.ws; Paolo Bonzini; Zhang, Yang Z; Chen,
>>>>> Tiejun
>>>>> Subject: Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen:
>>>>> add Intel IGD passthrough support
>>>>>
>>>>> On Thu, Jul 03, 2014 at 12:09:28PM -0700, Jesse Barnes wrote:
>>>>>> On Thu, 3 Jul 2014 14:26:12 -0400
>>>>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>>>>>
>>>>>>> On Thu, Jul 03, 2014 at 10:32:12AM +0300, Michael S. Tsirkin wrote:
>>>>>>>> On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
>>>>>>>>> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
>>>>>>>>>> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
>>>>>>>>>>> With this long thread I lost a bit context about the
>>>>>>>>>>> challenges that exists. But let me try summarizing it here
>>>>>>>>>>> - which will hopefully get some consensus.
>>>>>>>>>>>
>>>>>>>>>>> 1). Fix IGD hardware to not use Southbridge magic addresses.
>>>>>>>>>>>     We can moan and moan but I doubt it is going to change.
>>>>>>>>>>
>>>>>>>>>> There are two problems:
>>>>>>>>>>
>>>>>>>>>> - Northbridge (i.e. MCH i.e. PCI host bridge) configuration
>>>>>>>>>> space addresses
>>>>>>>>>
>>>>>>>>> Right. So in  drivers/gpu/drm/i915/i915_dma.c:
>>>>>>>>> 1135 #define MCHBAR_I915 0x44
>>>>>>>>> 1136 #define MCHBAR_I965 0x48
>>>>>>>>>
>>>>>>>>> 1147         int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>>>>> 1152         if (INTEL_INFO(dev)->gen >= 4)
>>>>>>>>> 1153                 pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi);
>>>>>>>>> 1154         pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);
>>>>>>>>> 1155         mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> 1139 #define DEVEN_REG 0x54
>>>>>>>>>
>>>>>>>>> 1193         int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
>>>>>>>>> 1202         if (IS_I915G(dev) || IS_I915GM(dev)) {
>>>>>>>>> 1203                 pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
>>>>>>>>> 1204                 enabled = !!(temp & DEVEN_MCHBAR_EN);
>>>>>>>>> 1205         } else {
>>>>>>>>> 1206                 pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
>>>>>>>>> 1207                 enabled = temp & 1;
>>>>>>>>> 1208         }
>>>>>>>>>>
>>>>>>>>>> - Southbridge (i.e. PCH i.e. ISA bridge) vendor/device ID;
>>>>>>>>>> some versions of the driver identify it by class, some versions identify it by slot (1f.0).
>>>>>>>>>
>>>>>>>>> Right, So in  drivers/gpu/drm/i915/i915_drv.c the giant
>>>>>>>>> intel_detect_pch which sets the pch_type based on :
>>>>>>>>>
>>>>>>>>>   432                 if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>>>>>>>>   433                         unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK;
>>>>>>>>>   434                         dev_priv->pch_id = id;
>>>>>>>>>   435
>>>>>>>>>   436                         if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
>>>>>>>>>
>>>>>>>>> It checks for 0x3b00, 0x1c00, 0x1e00, 0x8c00 and 0x9c00.
>>>>>>>>> The INTEL_PCH_DEVICE_ID_MASK is 0xff00
>>>>>>>>>>
>>>>>>>>>> To solve the first, make a new machine type, PIIX4-based,
>>>>>>>>>> and pass through the registers you need.  The patch must
>>>>>>>>>> document _exactly_ why the registers are safe to pass.  If
>>>>>>>>>> they are not reserved on PIIX4, the patch must document what
>>>>>>>>>> the same offsets mean on PIIX4, and why it's sensible to
>>>>>>>>>> assume that firmware for virtual machine will not read/write them.  Bonus point for also documenting the same for Q35.
>>>>>>>>>
>>>>>>>>> OK. They look to be related to setting up an MBAR , but I
>>>>>>>>> don't understand why it is needed. Hopefully some of the i915 folks CC-ed here can answer.
>>>>>>>>
>>>>>>>> In particular, I think setting up MBAR should move out of i915
>>>>>>>> and become the bridge driver tweak on linux and windows.
>>>>>>>
>>>>>>> That is an excellent idea.
>>>>>>>
>>>>>>> However I am still curious to _why_ it has to be done in the first place.
>>>>>>
>>>>>> The display part of the GPU is partly on the PCH, and it's possible
>>>>>> to mix & match them a bit, so we have this detection code to figure
>>>>>> things out.  In some cases, the PCH display portion may not even be
>>>>>> present, so we look for that too.
>>>>>>
>>>>>> Practically speaking, we could probably assume specific CPU/PCH
>>>>>> combos, as I don't think they're generally mixed across generations,
>>>>>> though SNB and IVB did have compatible sockets, so there is the
>>>>>> possibility of mixing CPT and PPT PCHs, but those are register
>>>>>> identical as far as the graphics driver is concerned, so even that should be safe.
>>>>>>
>>>>>> Beyond that, the other MCH data we need to look at is mirrored into
>>>>>> the GPU's MMIO space on current gens.  On older gens, we do need to
>>>>>> poke at the memory controller a bit to get some info (see
>>>>>> intel_setup_mchbar()), but that's not true of newer stuff.  Looks
>>>>>> like we only short circuit that on VLV though; we could probably do
>>>>>> it on
>>>>>> SNB+.
>>>>>
>>>>> That sounds great. Tiejun could you confirm that with windows driver guys too?
>>>>>
>>>>>> --
>>>>>> Jesse Barnes, Intel Open Source Technology Center
>>>>> _______________________________________________
>>>>> Intel-gfx mailing list
>>>>> Intel-gfx@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 29/07/2014 08:59, Chen, Tiejun ha scritto:
>>
>> (see https://lkml.org/lkml/2014/6/19/121)
>>> "gpu:drm:i915:intel_detect_pch: back to check devfn instead of check
>>> class
>>> type". Because Windows always use this way, so I think this point
>>> should be
>>> same between Linux and Windows.
>>
>> Didn't we discuss that we did not want to pass in PCH at all if we can?
> 
> I'm a bit confused since I guess I'm missing something important in this
> long discussion. I guess we just fake a simple PCIe device but just has
> PCI_VENDOR_ID_XEN/Real_PCH_Device_ID, and then well probe such a PCIe
> device inside intel_detect_pch(), right?

Yes, for the special PIIX4 legacy machine type we want to do that and
place the device at 00:1f.0.

Paolo

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 29/07/2014 08:59, Chen, Tiejun ha scritto:
>>
>> (see https://lkml.org/lkml/2014/6/19/121)
>>> "gpu:drm:i915:intel_detect_pch: back to check devfn instead of check
>>> class
>>> type". Because Windows always use this way, so I think this point
>>> should be
>>> same between Linux and Windows.
>>
>> Didn't we discuss that we did not want to pass in PCH at all if we can?
> 
> I'm a bit confused since I guess I'm missing something important in this
> long discussion. I guess we just fake a simple PCIe device but just has
> PCI_VENDOR_ID_XEN/Real_PCH_Device_ID, and then well probe such a PCIe
> device inside intel_detect_pch(), right?

Yes, for the special PIIX4 legacy machine type we want to do that and
place the device at 00:1f.0.

Paolo

Re: [Qemu-devel] [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/29 16:32, Paolo Bonzini wrote:
> Il 29/07/2014 08:59, Chen, Tiejun ha scritto:
>>>
>>> (see https://lkml.org/lkml/2014/6/19/121)
>>>> "gpu:drm:i915:intel_detect_pch: back to check devfn instead of check
>>>> class
>>>> type". Because Windows always use this way, so I think this point
>>>> should be
>>>> same between Linux and Windows.
>>>
>>> Didn't we discuss that we did not want to pass in PCH at all if we can?
>>
>> I'm a bit confused since I guess I'm missing something important in this
>> long discussion. I guess we just fake a simple PCIe device but just has
>> PCI_VENDOR_ID_XEN/Real_PCH_Device_ID, and then well probe such a PCIe
>> device inside intel_detect_pch(), right?
>
> Yes, for the special PIIX4 legacy machine type we want to do that and
> place the device at 00:1f.0.
>

Got it.

BTW, please review those patches implemented a separate machine, xenigd, 
firstly. Then I can step on this point.

Thanks
Tiejun

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/29 16:32, Paolo Bonzini wrote:
> Il 29/07/2014 08:59, Chen, Tiejun ha scritto:
>>>
>>> (see https://lkml.org/lkml/2014/6/19/121)
>>>> "gpu:drm:i915:intel_detect_pch: back to check devfn instead of check
>>>> class
>>>> type". Because Windows always use this way, so I think this point
>>>> should be
>>>> same between Linux and Windows.
>>>
>>> Didn't we discuss that we did not want to pass in PCH at all if we can?
>>
>> I'm a bit confused since I guess I'm missing something important in this
>> long discussion. I guess we just fake a simple PCIe device but just has
>> PCI_VENDOR_ID_XEN/Real_PCH_Device_ID, and then well probe such a PCIe
>> device inside intel_detect_pch(), right?
>
> Yes, for the special PIIX4 legacy machine type we want to do that and
> place the device at 00:1f.0.
>

Got it.

BTW, please review those patches implemented a separate machine, xenigd, 
firstly. Then I can step on this point.

Thanks
Tiejun

Re: [Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 03/07/2014 21:09, Jesse Barnes ha scritto:
> Practically speaking, we could probably assume specific CPU/PCH combos,
> as I don't think they're generally mixed across generations, though SNB
> and IVB did have compatible sockets, so there is the possibility of
> mixing CPT and PPT PCHs, but those are register identical as far as the
> graphics driver is concerned, so even that should be safe.

I guess the driver could do that if it finds an unknown PCH device ID. 
But encoding it in the subsystem device ID could also work and it would 
be easy to do in the hypervisor.

> Beyond that, the other MCH data we need to look at is mirrored into the
> GPU's MMIO space on current gens.

Heh, that's exactly the same as the paravirtualized solution we were 
suggesting. ;)

Paolo

> On older gens, we do need to poke at
> the memory controller a bit to get some info (see
> intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
> we only short circuit that on VLV though; we could probably do it on
> SNB+.

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 03/07/2014 21:09, Jesse Barnes ha scritto:
> Practically speaking, we could probably assume specific CPU/PCH combos,
> as I don't think they're generally mixed across generations, though SNB
> and IVB did have compatible sockets, so there is the possibility of
> mixing CPT and PPT PCHs, but those are register identical as far as the
> graphics driver is concerned, so even that should be safe.

I guess the driver could do that if it finds an unknown PCH device ID. 
But encoding it in the subsystem device ID could also work and it would 
be easy to do in the hypervisor.

> Beyond that, the other MCH data we need to look at is mirrored into the
> GPU's MMIO space on current gens.

Heh, that's exactly the same as the paravirtualized solution we were 
suggesting. ;)

Paolo

> On older gens, we do need to poke at
> the memory controller a bit to get some info (see
> intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
> we only short circuit that on VLV though; we could probably do it on
> SNB+.

Re: [Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Fri, Jul 04, 2014 at 08:28:25AM +0200, Paolo Bonzini wrote:
> Il 03/07/2014 21:09, Jesse Barnes ha scritto:
> >Practically speaking, we could probably assume specific CPU/PCH combos,
> >as I don't think they're generally mixed across generations, though SNB
> >and IVB did have compatible sockets, so there is the possibility of
> >mixing CPT and PPT PCHs, but those are register identical as far as the
> >graphics driver is concerned, so even that should be safe.
> 
> I guess the driver could do that if it finds an unknown PCH device ID.

I would say if possible, do this unconditionally.
If this logic is strictly required then I would
also check the subsystem vendor id and skip the
PCH tricks if it matches Xen.

> But
> encoding it in the subsystem device ID could also work and it would be easy
> to do in the hypervisor.

Right, but that's custom code in the hypervisor as opposed to the generic one.
If generic one can work, that's much better.

> >Beyond that, the other MCH data we need to look at is mirrored into the
> >GPU's MMIO space on current gens.
> 
> Heh, that's exactly the same as the paravirtualized solution we were
> suggesting. ;)
> 
> Paolo
> 
> >On older gens, we do need to poke at
> >the memory controller a bit to get some info (see
> >intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
> >we only short circuit that on VLV though; we could probably do it on
> >SNB+.

Re: ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Fri, Jul 04, 2014 at 08:28:25AM +0200, Paolo Bonzini wrote:
> Il 03/07/2014 21:09, Jesse Barnes ha scritto:
> >Practically speaking, we could probably assume specific CPU/PCH combos,
> >as I don't think they're generally mixed across generations, though SNB
> >and IVB did have compatible sockets, so there is the possibility of
> >mixing CPT and PPT PCHs, but those are register identical as far as the
> >graphics driver is concerned, so even that should be safe.
> 
> I guess the driver could do that if it finds an unknown PCH device ID.

I would say if possible, do this unconditionally.
If this logic is strictly required then I would
also check the subsystem vendor id and skip the
PCH tricks if it matches Xen.

> But
> encoding it in the subsystem device ID could also work and it would be easy
> to do in the hypervisor.

Right, but that's custom code in the hypervisor as opposed to the generic one.
If generic one can work, that's much better.

> >Beyond that, the other MCH data we need to look at is mirrored into the
> >GPU's MMIO space on current gens.
> 
> Heh, that's exactly the same as the paravirtualized solution we were
> suggesting. ;)
> 
> Paolo
> 
> >On older gens, we do need to poke at
> >the memory controller a bit to get some info (see
> >intel_setup_mchbar()), but that's not true of newer stuff.  Looks like
> >we only short circuit that on VLV though; we could probably do it on
> >SNB+.

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Ross Philipson]

> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Wednesday, July 02, 2014 7:33 AM
> To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini
> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Allen M.
> Kay; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org;
> yang.z.zhang@intel.com; anthony@codemonkey.ws; Anthony Perard; Chen,
> Tiejun
> Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough
> support
> 
> Il 01/07/2014 19:39, Ross Philipson ha scritto:
> >
> > We do IGD pass-through in our project (XenClient). The patches
> > originally came from our project. We surface the same ISA bridge and
> > have never had activation issues on any version of Widows from XP to
> > Win8. We do not normally run server platforms so I can't say for sure
> > there.
> 
> The problem is not activation, the problem is that the patches are
> making assumptions on the driver and the firmware that might work today
> but are IMHO just not sane.

Sure I don't think anybody is suggesting that activation is
the main problem. It was just a potential problem with respect
to one of the proposed solutions.

When we first started doing this (back in 2009ish) we ran into
all these problems with surfacing ISA bridges, giving guest
drivers access to registers in the host bridge. etc. Nothing seemed
sane; I sympathize. 

> 
> I would have no problem with a clean patchset that adds a new machine
> type and doesn't touch code in "-M pc", but it looks like mst disagrees.
>   Ultimately, if a patchset is too hacky for upstream, you can include
> it in your downstream XenClient (and XenServer) QEMU branch.  It
> happens.
> 
> Paolo
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date:
> 06/30/14

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Ross Philipson]

> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Wednesday, July 02, 2014 7:33 AM
> To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini
> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Allen M.
> Kay; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org;
> yang.z.zhang@intel.com; anthony@codemonkey.ws; Anthony Perard; Chen,
> Tiejun
> Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough
> support
> 
> Il 01/07/2014 19:39, Ross Philipson ha scritto:
> >
> > We do IGD pass-through in our project (XenClient). The patches
> > originally came from our project. We surface the same ISA bridge and
> > have never had activation issues on any version of Widows from XP to
> > Win8. We do not normally run server platforms so I can't say for sure
> > there.
> 
> The problem is not activation, the problem is that the patches are
> making assumptions on the driver and the firmware that might work today
> but are IMHO just not sane.

Sure I don't think anybody is suggesting that activation is
the main problem. It was just a potential problem with respect
to one of the proposed solutions.

When we first started doing this (back in 2009ish) we ran into
all these problems with surfacing ISA bridges, giving guest
drivers access to registers in the host bridge. etc. Nothing seemed
sane; I sympathize. 

> 
> I would have no problem with a clean patchset that adds a new machine
> type and doesn't touch code in "-M pc", but it looks like mst disagrees.
>   Ultimately, if a patchset is too hacky for upstream, you can include
> it in your downstream XenClient (and XenServer) QEMU branch.  It
> happens.
> 
> Paolo
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date:
> 06/30/14

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 03:15:02PM +0000, Ross Philipson wrote:
> > -----Original Message-----
> > From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> > Sent: Wednesday, July 02, 2014 7:33 AM
> > To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini
> > Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Allen M.
> > Kay; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org;
> > yang.z.zhang@intel.com; anthony@codemonkey.ws; Anthony Perard; Chen,
> > Tiejun
> > Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough
> > support
> > 
> > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > >
> > > We do IGD pass-through in our project (XenClient). The patches
> > > originally came from our project. We surface the same ISA bridge and
> > > have never had activation issues on any version of Widows from XP to
> > > Win8. We do not normally run server platforms so I can't say for sure
> > > there.
> > 
> > The problem is not activation, the problem is that the patches are
> > making assumptions on the driver and the firmware that might work today
> > but are IMHO just not sane.
> 
> Sure I don't think anybody is suggesting that activation is
> the main problem. It was just a potential problem with respect
> to one of the proposed solutions.
> 
> When we first started doing this (back in 2009ish) we ran into
> all these problems with surfacing ISA bridges, giving guest
> drivers access to registers in the host bridge. etc. Nothing seemed
> sane; I sympathize. 

At some level, maybe Paolo is right.  Ignore existing drivers and ask
intel developers to update their drivers to do something sane on
hypervisors, even if they do ugly things on real hardware.

A simple proposal since what I wrote earlier though apparently wasn't
very clear:

  Detect Xen subsystem vendor id on vga card.
  If there, avoid poking at chipset. Instead
	- use subsystem device # for card type
	- use second half of BAR0 of device
	- instead of access to pci host

hypervisors will simply take BAR0 and double it in size,
make second part map to what would be the pci host.

Tiejun, is there a chance this can be done not only
on Linux but on windows as well?


> > 
> > I would have no problem with a clean patchset that adds a new machine
> > type and doesn't touch code in "-M pc", but it looks like mst disagrees.
> >   Ultimately, if a patchset is too hacky for upstream, you can include
> > it in your downstream XenClient (and XenServer) QEMU branch.  It
> > happens.
> > 
> > Paolo
> > 
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date:
> > 06/30/14

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 03:15:02PM +0000, Ross Philipson wrote:
> > -----Original Message-----
> > From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> > Sent: Wednesday, July 02, 2014 7:33 AM
> > To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini
> > Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Allen M.
> > Kay; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org;
> > yang.z.zhang@intel.com; anthony@codemonkey.ws; Anthony Perard; Chen,
> > Tiejun
> > Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough
> > support
> > 
> > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > >
> > > We do IGD pass-through in our project (XenClient). The patches
> > > originally came from our project. We surface the same ISA bridge and
> > > have never had activation issues on any version of Widows from XP to
> > > Win8. We do not normally run server platforms so I can't say for sure
> > > there.
> > 
> > The problem is not activation, the problem is that the patches are
> > making assumptions on the driver and the firmware that might work today
> > but are IMHO just not sane.
> 
> Sure I don't think anybody is suggesting that activation is
> the main problem. It was just a potential problem with respect
> to one of the proposed solutions.
> 
> When we first started doing this (back in 2009ish) we ran into
> all these problems with surfacing ISA bridges, giving guest
> drivers access to registers in the host bridge. etc. Nothing seemed
> sane; I sympathize. 

At some level, maybe Paolo is right.  Ignore existing drivers and ask
intel developers to update their drivers to do something sane on
hypervisors, even if they do ugly things on real hardware.

A simple proposal since what I wrote earlier though apparently wasn't
very clear:

  Detect Xen subsystem vendor id on vga card.
  If there, avoid poking at chipset. Instead
	- use subsystem device # for card type
	- use second half of BAR0 of device
	- instead of access to pci host

hypervisors will simply take BAR0 and double it in size,
make second part map to what would be the pci host.

Tiejun, is there a chance this can be done not only
on Linux but on windows as well?


> > 
> > I would have no problem with a clean patchset that adds a new machine
> > type and doesn't touch code in "-M pc", but it looks like mst disagrees.
> >   Ultimately, if a patchset is too hacky for upstream, you can include
> > it in your downstream XenClient (and XenServer) QEMU branch.  It
> > happens.
> > 
> > Paolo
> > 
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date:
> > 06/30/14

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> At some level, maybe Paolo is right.  Ignore existing drivers and ask
> intel developers to update their drivers to do something sane on
> hypervisors, even if they do ugly things on real hardware.
> 
> A simple proposal since what I wrote earlier though apparently wasn't
> very clear:
> 
>   Detect Xen subsystem vendor id on vga card.
>   If there, avoid poking at chipset. Instead
> 	- use subsystem device # for card type

You mean for PCH type (aka PCH device id).

> 	- use second half of BAR0 of device
> 	- instead of access to pci host
> 
> hypervisors will simply take BAR0 and double it in size,
> make second part map to what would be the pci host.

Nice.  Detecting the backdoor via the subsystem vendor id
is clever.

I'm not sure if it's possible to just double the size of BAR0 
or not, but my laptop has:

	Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 5000 [size=64]

and I hope we can reserve a few KB for hypervisors within those
4M, or 8 bytes for an address/data pair (like cf8/cfc) within BAR4's
64 bytes (or grow BAR4 to 128 bytes, or something like that).

Xen can still add the hacky machine type if they want for existing 
hosts, but this would be a nice way forward.

Paolo

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> At some level, maybe Paolo is right.  Ignore existing drivers and ask
> intel developers to update their drivers to do something sane on
> hypervisors, even if they do ugly things on real hardware.
> 
> A simple proposal since what I wrote earlier though apparently wasn't
> very clear:
> 
>   Detect Xen subsystem vendor id on vga card.
>   If there, avoid poking at chipset. Instead
> 	- use subsystem device # for card type

You mean for PCH type (aka PCH device id).

> 	- use second half of BAR0 of device
> 	- instead of access to pci host
> 
> hypervisors will simply take BAR0 and double it in size,
> make second part map to what would be the pci host.

Nice.  Detecting the backdoor via the subsystem vendor id
is clever.

I'm not sure if it's possible to just double the size of BAR0 
or not, but my laptop has:

	Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 5000 [size=64]

and I hope we can reserve a few KB for hypervisors within those
4M, or 8 bytes for an address/data pair (like cf8/cfc) within BAR4's
64 bytes (or grow BAR4 to 128 bytes, or something like that).

Xen can still add the hacky machine type if they want for existing 
hosts, but this would be a nice way forward.

Paolo

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right.  Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly things on real hardware.
> > 
> > A simple proposal since what I wrote earlier though apparently wasn't
> > very clear:
> > 
> >   Detect Xen subsystem vendor id on vga card.
> >   If there, avoid poking at chipset. Instead
> > 	- use subsystem device # for card type
> 
> You mean for PCH type (aka PCH device id).
> 
> > 	- use second half of BAR0 of device
> > 	- instead of access to pci host
> > 
> > hypervisors will simply take BAR0 and double it in size,
> > make second part map to what would be the pci host.
> 
> Nice.  Detecting the backdoor via the subsystem vendor id
> is clever.
> 
> I'm not sure if it's possible to just double the size of BAR0 
> or not, but my laptop has:
> 
> 	Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
> 	Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
> 	Region 4: I/O ports at 5000 [size=64]
> 
> and I hope we can reserve a few KB for hypervisors within those
> 4M, or 8 bytes for an address/data pair (like cf8/cfc) within BAR4's
> 64 bytes (or grow BAR4 to 128 bytes, or something like that).
> 
> Xen can still add the hacky machine type if they want for existing 
> hosts, but this would be a nice way forward.

It would be good to understand first why i915 in the first place
needs to setup the bridge MBAR if it has not been set. As in, why
is this region needed? Is it needed to flush the pipeline (as in
you need to write there?) or .. 

Perhaps it is not needed anymore with the current hardware and
what can be done is put a stake in the ground saying that only
genX or later will be supported.

The commit ids allude to power managament and the earlier commits
did poke there - but I don't see it on the latest tree.
> 
> Paolo
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Konrad Rzeszutek Wilk]

On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right.  Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly things on real hardware.
> > 
> > A simple proposal since what I wrote earlier though apparently wasn't
> > very clear:
> > 
> >   Detect Xen subsystem vendor id on vga card.
> >   If there, avoid poking at chipset. Instead
> > 	- use subsystem device # for card type
> 
> You mean for PCH type (aka PCH device id).
> 
> > 	- use second half of BAR0 of device
> > 	- instead of access to pci host
> > 
> > hypervisors will simply take BAR0 and double it in size,
> > make second part map to what would be the pci host.
> 
> Nice.  Detecting the backdoor via the subsystem vendor id
> is clever.
> 
> I'm not sure if it's possible to just double the size of BAR0 
> or not, but my laptop has:
> 
> 	Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
> 	Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
> 	Region 4: I/O ports at 5000 [size=64]
> 
> and I hope we can reserve a few KB for hypervisors within those
> 4M, or 8 bytes for an address/data pair (like cf8/cfc) within BAR4's
> 64 bytes (or grow BAR4 to 128 bytes, or something like that).
> 
> Xen can still add the hacky machine type if they want for existing 
> hosts, but this would be a nice way forward.

It would be good to understand first why i915 in the first place
needs to setup the bridge MBAR if it has not been set. As in, why
is this region needed? Is it needed to flush the pipeline (as in
you need to write there?) or .. 

Perhaps it is not needed anymore with the current hardware and
what can be done is put a stake in the ground saying that only
genX or later will be supported.

The commit ids allude to power managament and the earlier commits
did poke there - but I don't see it on the latest tree.
> 
> Paolo
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right.  Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly things on real hardware.
> > 
> > A simple proposal since what I wrote earlier though apparently wasn't
> > very clear:
> > 
> >   Detect Xen subsystem vendor id on vga card.
> >   If there, avoid poking at chipset. Instead
> > 	- use subsystem device # for card type
> 
> You mean for PCH type (aka PCH device id).
> 
> > 	- use second half of BAR0 of device
> > 	- instead of access to pci host
> > 
> > hypervisors will simply take BAR0 and double it in size,
> > make second part map to what would be the pci host.
> 
> Nice.  Detecting the backdoor via the subsystem vendor id
> is clever.
> 
> I'm not sure if it's possible to just double the size of BAR0 
> or not,

Why won't it be?
You just make one bit that is RO in hw RW in QEMU.

> but my laptop has:
> 
> 	Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
> 	Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
> 	Region 4: I/O ports at 5000 [size=64]
> 
> and I hope we can reserve a few KB for hypervisors within those
> 4M, or 8 bytes for an address/data pair (like cf8/cfc) within BAR4's
> 64 bytes (or grow BAR4 to 128 bytes, or something like that).

Wasting IO isn't a good idea usually.

> Xen can still add the hacky machine type if they want for existing 
> hosts, but this would be a nice way forward.
> 
> Paolo

We need to get agreement from driver writers though,
specifically windows guys.

-- 
MST

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right.  Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly things on real hardware.
> > 
> > A simple proposal since what I wrote earlier though apparently wasn't
> > very clear:
> > 
> >   Detect Xen subsystem vendor id on vga card.
> >   If there, avoid poking at chipset. Instead
> > 	- use subsystem device # for card type
> 
> You mean for PCH type (aka PCH device id).
> 
> > 	- use second half of BAR0 of device
> > 	- instead of access to pci host
> > 
> > hypervisors will simply take BAR0 and double it in size,
> > make second part map to what would be the pci host.
> 
> Nice.  Detecting the backdoor via the subsystem vendor id
> is clever.
> 
> I'm not sure if it's possible to just double the size of BAR0 
> or not,

Why won't it be?
You just make one bit that is RO in hw RW in QEMU.

> but my laptop has:
> 
> 	Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
> 	Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
> 	Region 4: I/O ports at 5000 [size=64]
> 
> and I hope we can reserve a few KB for hypervisors within those
> 4M, or 8 bytes for an address/data pair (like cf8/cfc) within BAR4's
> 64 bytes (or grow BAR4 to 128 bytes, or something like that).

Wasting IO isn't a good idea usually.

> Xen can still add the hacky machine type if they want for existing 
> hosts, but this would be a nice way forward.
> 
> Paolo

We need to get agreement from driver writers though,
specifically windows guys.

-- 
MST

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/2 23:27, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 03:15:02PM +0000, Ross Philipson wrote:
>>> -----Original Message-----
>>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
>>> Sent: Wednesday, July 02, 2014 7:33 AM
>>> To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini
>>> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Allen M.
>>> Kay; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org;
>>> yang.z.zhang@intel.com; anthony@codemonkey.ws; Anthony Perard; Chen,
>>> Tiejun
>>> Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough
>>> support
>>>
>>> Il 01/07/2014 19:39, Ross Philipson ha scritto:
>>>>
>>>> We do IGD pass-through in our project (XenClient). The patches
>>>> originally came from our project. We surface the same ISA bridge and
>>>> have never had activation issues on any version of Widows from XP to
>>>> Win8. We do not normally run server platforms so I can't say for sure
>>>> there.
>>>
>>> The problem is not activation, the problem is that the patches are
>>> making assumptions on the driver and the firmware that might work today
>>> but are IMHO just not sane.
>>
>> Sure I don't think anybody is suggesting that activation is
>> the main problem. It was just a potential problem with respect
>> to one of the proposed solutions.
>>
>> When we first started doing this (back in 2009ish) we ran into
>> all these problems with surfacing ISA bridges, giving guest
>> drivers access to registers in the host bridge. etc. Nothing seemed
>> sane; I sympathize.
>
> At some level, maybe Paolo is right.  Ignore existing drivers and ask
> intel developers to update their drivers to do something sane on
> hypervisors, even if they do ugly things on real hardware.
>
> A simple proposal since what I wrote earlier though apparently wasn't
> very clear:
>
>    Detect Xen subsystem vendor id on vga card.
>    If there, avoid poking at chipset. Instead
> 	- use subsystem device # for card type
> 	- use second half of BAR0 of device
> 	- instead of access to pci host
>
> hypervisors will simply take BAR0 and double it in size,
> make second part map to what would be the pci host.
>
> Tiejun, is there a chance this can be done not only
> on Linux but on windows as well?

MST,

Looks this is paravirtualizaed way, right?

I can post this requirement to check but please make sure I really 
understand what you mean,

#1 We need to define a new Xen subsystem vendor id and emulate this 
value on vga card

#2 Native driver need to do:

	* if the subsystem id on vga is that emulated XEN subsystem id, the 
native driver can get all necessary access including PCI host bridge at 
0.0 and ISA bridge at 1f.0 from second half of that emulated BAR0 double 
the real size.

Right? If yes, I'd like to ask them.

But question is how to walk from PCI config on PCI host to BAR0 on VGA:

     	dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));

	pci_write/read_config_dword(dev_priv->bridge_dev,,,)

Thanks
Tiejun

>
>
>>>
>>> I would have no problem with a clean patchset that adds a new machine
>>> type and doesn't touch code in "-M pc", but it looks like mst disagrees.
>>>    Ultimately, if a patchset is too hacky for upstream, you can include
>>> it in your downstream XenClient (and XenServer) QEMU branch.  It
>>> happens.
>>>
>>> Paolo
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date:
>>> 06/30/14
>

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/2 23:27, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 03:15:02PM +0000, Ross Philipson wrote:
>>> -----Original Message-----
>>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
>>> Sent: Wednesday, July 02, 2014 7:33 AM
>>> To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini
>>> Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Allen M.
>>> Kay; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org;
>>> yang.z.zhang@intel.com; anthony@codemonkey.ws; Anthony Perard; Chen,
>>> Tiejun
>>> Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough
>>> support
>>>
>>> Il 01/07/2014 19:39, Ross Philipson ha scritto:
>>>>
>>>> We do IGD pass-through in our project (XenClient). The patches
>>>> originally came from our project. We surface the same ISA bridge and
>>>> have never had activation issues on any version of Widows from XP to
>>>> Win8. We do not normally run server platforms so I can't say for sure
>>>> there.
>>>
>>> The problem is not activation, the problem is that the patches are
>>> making assumptions on the driver and the firmware that might work today
>>> but are IMHO just not sane.
>>
>> Sure I don't think anybody is suggesting that activation is
>> the main problem. It was just a potential problem with respect
>> to one of the proposed solutions.
>>
>> When we first started doing this (back in 2009ish) we ran into
>> all these problems with surfacing ISA bridges, giving guest
>> drivers access to registers in the host bridge. etc. Nothing seemed
>> sane; I sympathize.
>
> At some level, maybe Paolo is right.  Ignore existing drivers and ask
> intel developers to update their drivers to do something sane on
> hypervisors, even if they do ugly things on real hardware.
>
> A simple proposal since what I wrote earlier though apparently wasn't
> very clear:
>
>    Detect Xen subsystem vendor id on vga card.
>    If there, avoid poking at chipset. Instead
> 	- use subsystem device # for card type
> 	- use second half of BAR0 of device
> 	- instead of access to pci host
>
> hypervisors will simply take BAR0 and double it in size,
> make second part map to what would be the pci host.
>
> Tiejun, is there a chance this can be done not only
> on Linux but on windows as well?

MST,

Looks this is paravirtualizaed way, right?

I can post this requirement to check but please make sure I really 
understand what you mean,

#1 We need to define a new Xen subsystem vendor id and emulate this 
value on vga card

#2 Native driver need to do:

	* if the subsystem id on vga is that emulated XEN subsystem id, the 
native driver can get all necessary access including PCI host bridge at 
0.0 and ISA bridge at 1f.0 from second half of that emulated BAR0 double 
the real size.

Right? If yes, I'd like to ask them.

But question is how to walk from PCI config on PCI host to BAR0 on VGA:

     	dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));

	pci_write/read_config_dword(dev_priv->bridge_dev,,,)

Thanks
Tiejun

>
>
>>>
>>> I would have no problem with a clean patchset that adds a new machine
>>> type and doesn't touch code in "-M pc", but it looks like mst disagrees.
>>>    Ultimately, if a patchset is too hacky for upstream, you can include
>>> it in your downstream XenClient (and XenServer) QEMU branch.  It
>>> happens.
>>>
>>> Paolo
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date:
>>> 06/30/14
>

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Thu, Jul 03, 2014 at 01:57:24PM +0800, Chen, Tiejun wrote:
> On 2014/7/2 23:27, Michael S. Tsirkin wrote:
> >On Wed, Jul 02, 2014 at 03:15:02PM +0000, Ross Philipson wrote:
> >>>-----Original Message-----
> >>>From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> >>>Sent: Wednesday, July 02, 2014 7:33 AM
> >>>To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini
> >>>Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Allen M.
> >>>Kay; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org;
> >>>yang.z.zhang@intel.com; anthony@codemonkey.ws; Anthony Perard; Chen,
> >>>Tiejun
> >>>Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough
> >>>support
> >>>
> >>>Il 01/07/2014 19:39, Ross Philipson ha scritto:
> >>>>
> >>>>We do IGD pass-through in our project (XenClient). The patches
> >>>>originally came from our project. We surface the same ISA bridge and
> >>>>have never had activation issues on any version of Widows from XP to
> >>>>Win8. We do not normally run server platforms so I can't say for sure
> >>>>there.
> >>>
> >>>The problem is not activation, the problem is that the patches are
> >>>making assumptions on the driver and the firmware that might work today
> >>>but are IMHO just not sane.
> >>
> >>Sure I don't think anybody is suggesting that activation is
> >>the main problem. It was just a potential problem with respect
> >>to one of the proposed solutions.
> >>
> >>When we first started doing this (back in 2009ish) we ran into
> >>all these problems with surfacing ISA bridges, giving guest
> >>drivers access to registers in the host bridge. etc. Nothing seemed
> >>sane; I sympathize.
> >
> >At some level, maybe Paolo is right.  Ignore existing drivers and ask
> >intel developers to update their drivers to do something sane on
> >hypervisors, even if they do ugly things on real hardware.
> >
> >A simple proposal since what I wrote earlier though apparently wasn't
> >very clear:
> >
> >   Detect Xen subsystem vendor id on vga card.
> >   If there, avoid poking at chipset. Instead
> >	- use subsystem device # for card type
> >	- use second half of BAR0 of device
> >	- instead of access to pci host
> >
> >hypervisors will simply take BAR0 and double it in size,
> >make second part map to what would be the pci host.
> >
> >Tiejun, is there a chance this can be done not only
> >on Linux but on windows as well?
> 
> MST,
> 
> Looks this is paravirtualizaed way, right?
> 
> I can post this requirement to check but please make sure I really
> understand what you mean,
> 
> #1 We need to define a new Xen subsystem vendor id and emulate this value on
> vga card
> 
> #2 Native driver need to do:
> 
> 	* if the subsystem id on vga is that emulated XEN subsystem id, the native
> driver can get all necessary access including PCI host bridge at 0.0 and ISA
> bridge at 1f.0 from second half of that emulated BAR0 double the real size.
> 
> Right? If yes, I'd like to ask them.

Yes.

And in addition, get the device type from the low bits of
the subsystem id as opposed to the ISA bridge.

This way you don't need to modify the PC type at all.

> But question is how to walk from PCI config on PCI host to BAR0 on VGA:
> 
>     	dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> 
> 	pci_write/read_config_dword(dev_priv->bridge_dev,,,)
> 
> Thanks
> Tiejun

So you would have a helper: set dev_priv->bridge_dev to NULL, and then


	i915_write/read_host_dword(dev, dev_priv, offset)
	{
		if (dev_priv->bridge_dev)
			pci_write/read_config_dword(dev_priv->bridge_dev,,,)
		else
			iowrite/read16(dev->pv_io_base, ....)
	}

The point being not touching anything except the vga device at all.

Note: we can't allow guests to change the config of the real host
bridge, so we end up whitelisting specific cards and specific registers
anyway.  So the only problem this solves is that of conflicts between
the host bridge emulated by qemu and the hardware one.

Also, maybe driver guys will see the pain this causes them
and will put some pressure on the hardware guys to
do it like this in future hardware :)

> >
> >
> >>>
> >>>I would have no problem with a clean patchset that adds a new machine
> >>>type and doesn't touch code in "-M pc", but it looks like mst disagrees.
> >>>   Ultimately, if a patchset is too hacky for upstream, you can include
> >>>it in your downstream XenClient (and XenServer) QEMU branch.  It
> >>>happens.
> >>>
> >>>Paolo
> >>>
> >>>-----
> >>>No virus found in this message.
> >>>Checked by AVG - www.avg.com
> >>>Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date:
> >>>06/30/14
> >

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Thu, Jul 03, 2014 at 01:57:24PM +0800, Chen, Tiejun wrote:
> On 2014/7/2 23:27, Michael S. Tsirkin wrote:
> >On Wed, Jul 02, 2014 at 03:15:02PM +0000, Ross Philipson wrote:
> >>>-----Original Message-----
> >>>From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> >>>Sent: Wednesday, July 02, 2014 7:33 AM
> >>>To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini
> >>>Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Allen M.
> >>>Kay; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org;
> >>>yang.z.zhang@intel.com; anthony@codemonkey.ws; Anthony Perard; Chen,
> >>>Tiejun
> >>>Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough
> >>>support
> >>>
> >>>Il 01/07/2014 19:39, Ross Philipson ha scritto:
> >>>>
> >>>>We do IGD pass-through in our project (XenClient). The patches
> >>>>originally came from our project. We surface the same ISA bridge and
> >>>>have never had activation issues on any version of Widows from XP to
> >>>>Win8. We do not normally run server platforms so I can't say for sure
> >>>>there.
> >>>
> >>>The problem is not activation, the problem is that the patches are
> >>>making assumptions on the driver and the firmware that might work today
> >>>but are IMHO just not sane.
> >>
> >>Sure I don't think anybody is suggesting that activation is
> >>the main problem. It was just a potential problem with respect
> >>to one of the proposed solutions.
> >>
> >>When we first started doing this (back in 2009ish) we ran into
> >>all these problems with surfacing ISA bridges, giving guest
> >>drivers access to registers in the host bridge. etc. Nothing seemed
> >>sane; I sympathize.
> >
> >At some level, maybe Paolo is right.  Ignore existing drivers and ask
> >intel developers to update their drivers to do something sane on
> >hypervisors, even if they do ugly things on real hardware.
> >
> >A simple proposal since what I wrote earlier though apparently wasn't
> >very clear:
> >
> >   Detect Xen subsystem vendor id on vga card.
> >   If there, avoid poking at chipset. Instead
> >	- use subsystem device # for card type
> >	- use second half of BAR0 of device
> >	- instead of access to pci host
> >
> >hypervisors will simply take BAR0 and double it in size,
> >make second part map to what would be the pci host.
> >
> >Tiejun, is there a chance this can be done not only
> >on Linux but on windows as well?
> 
> MST,
> 
> Looks this is paravirtualizaed way, right?
> 
> I can post this requirement to check but please make sure I really
> understand what you mean,
> 
> #1 We need to define a new Xen subsystem vendor id and emulate this value on
> vga card
> 
> #2 Native driver need to do:
> 
> 	* if the subsystem id on vga is that emulated XEN subsystem id, the native
> driver can get all necessary access including PCI host bridge at 0.0 and ISA
> bridge at 1f.0 from second half of that emulated BAR0 double the real size.
> 
> Right? If yes, I'd like to ask them.

Yes.

And in addition, get the device type from the low bits of
the subsystem id as opposed to the ISA bridge.

This way you don't need to modify the PC type at all.

> But question is how to walk from PCI config on PCI host to BAR0 on VGA:
> 
>     	dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> 
> 	pci_write/read_config_dword(dev_priv->bridge_dev,,,)
> 
> Thanks
> Tiejun

So you would have a helper: set dev_priv->bridge_dev to NULL, and then


	i915_write/read_host_dword(dev, dev_priv, offset)
	{
		if (dev_priv->bridge_dev)
			pci_write/read_config_dword(dev_priv->bridge_dev,,,)
		else
			iowrite/read16(dev->pv_io_base, ....)
	}

The point being not touching anything except the vga device at all.

Note: we can't allow guests to change the config of the real host
bridge, so we end up whitelisting specific cards and specific registers
anyway.  So the only problem this solves is that of conflicts between
the host bridge emulated by qemu and the hardware one.

Also, maybe driver guys will see the pain this causes them
and will put some pressure on the hardware guys to
do it like this in future hardware :)

> >
> >
> >>>
> >>>I would have no problem with a clean patchset that adds a new machine
> >>>type and doesn't touch code in "-M pc", but it looks like mst disagrees.
> >>>   Ultimately, if a patchset is too hacky for upstream, you can include
> >>>it in your downstream XenClient (and XenServer) QEMU branch.  It
> >>>happens.
> >>>
> >>>Paolo
> >>>
> >>>-----
> >>>No virus found in this message.
> >>>Checked by AVG - www.avg.com
> >>>Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date:
> >>>06/30/14
> >

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 5789 bytes --]

On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
> > On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> > > On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> > > > On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> > > > >On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> > > > >>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > > > >>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > > > >>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > > > >>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > > > >>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> > > > >>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>Are you saying the config space in the video device?
> > > > >>>>>>
> > > > >>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> > > > >>>>>>MMIO BAR.
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> > > > >>>>>offset or BAR in the config space.
> > > > >>>>>
> > > > >>>>>And guy who are responsible for the native driver seems not be accept to
> > > > >>>>>extend some magic offset of an existing MMIO BAR.
> > > > >>>>>
> > > > >>>>>In addition I think in a short time its not possible to migrate i440fx to
> > > > >>>>>q35 as a PCIe machine of xen.
> > > > >>>>
> > > > >>>>That seems like a weak motivation.  I don't see a need to get something
> > > > >>>>merged upstream in a short time: this seems sure to miss 2.1,
> > > > >>>>so you have the time to make it architecturally sound.
> > > > >>>>"Making existing guests work" would be a better motivation.
> > > > >>>
> > > > >>>Yes.
> > > > >>
> > > > >>So focus on this then. Existing guests will probably work
> > > > >>fine on a newer chipset - likely better than on i440fx.
> > > > >>xen management tools need to do some work to support this?
> > > > >
> > > > >Unfortunately existing Windows guests don't take well chipset changes.
> > > > >Windows might request a new activation.
> > > > 
> > > > That is a very good point. A while back I did a bunch of work to try to keep
> > > > Windows activated between running an instance of Windows on bare metal and
> > > > as a VM. There were numerous bits of hardware and firmware that went into
> > > > the calculation as to whether Windows thought it was the same platform for
> > > > activation purposes. Changing the chipset sounds like a likely candidate for
> > > > inspection. Somewhere out there on the webs is a partial list of the things
> > > > that are inspected - lost the URL.
> > > 
> > > It's not hard to try it out with kvm (you just need to remember to use ide with
> > > q35: ahci is the default there).  I did, and windows did not ask me to
> > > re-activate.
> > > 
> > > The detailed info is not hard to find:
> > > http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> > > links to:
> > > http://technet.microsoft.com/en-us/library/bb457054.aspx
> > > 
> > > 
> > > 1
> > > Display Adapter
> > > 00010 (5)
> > > 2
> > > SCSI Adapter
> > > 00011 (5)
> > > 3
> > > IDE Adapter
> > > 0011 (4)
> > > 4
> > > Network Adapter MAC Address
> > > 1001011000 (10)
> > > 5
> > > RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> > > 101 (3)
> > > 6
> > > Processor Type
> > > 011 (3)
> > > 7
> > > Processor Serial Number
> > > 000000 (6)
> > > 8
> > > Hard Drive Device
> > > 1101100 (7)
> > > 9
> > > Hard Drive Volume Serial Number
> > > 1001000001 (10)
> > > 10
> > > CD—ROM / CD-RW / DVD-ROM
> > > 010111 (6)
> > > -
> > > "Dockable"
> > > 0 (1)
> > > -
> > > Hardware Hash version (version of algorithm used)
> > > 001 (3)
> > > 
> > > So no, chipset version won't cause re-activation.
> > 
> > The page you linked is about Windows XP. Newer Windows versions have
> > stricter activation rules.  I don't think that moving existing VM images
> > from piix to q35 could be done without extensive testing of all the
> > major existing operating system images. I certainly wouldn't rely on a
> > wikipedia page for this.
> 
> So do the testing then.
> You don't even need to do anything on xen - run them all on kvm.
> This testing will benefit everyone.

Sure, test results on KVM would be reusable for Xen and vice versa.
Indeed they would benefit everybody.  I don't have the bandwidth for
this but I would encourage somebody in the community to step up and test
Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003,
Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.

Paul, did I miss anything important?


> > Also I don't like the idea of tying Tiejun's patch series, that covers a
> > very narrow use case, to something as important and general purpose as
> > upgrading chipset.
> 
> If it's true that implementing igd passthrough on top of q35 is much
> cleaner architecturally, then I don't see why we should merge a stop-gap
> solution that we'll need to then support indefinitely.
>
> We are talking about upstreaming functionality that xen already has, right?
> So there's no time to market concern, whoever wants a solution today
> has it.  Why not do it in the cleanest possible way?

I don't know if it is actually the case that building it on q35 would be
much cleaner architecturally. If it was true, it would be worth thinking
about. However I don't know if we can ask Tiejun to undertake a task
that is significantly different and an order of magnitude bigger than
his current effort in order to upstream his series, that has a much
narrower scope.

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 5789 bytes --]

On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
> > On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> > > On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> > > > On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> > > > >On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> > > > >>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > > > >>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > > > >>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > > > >>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > > > >>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> > > > >>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>Are you saying the config space in the video device?
> > > > >>>>>>
> > > > >>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> > > > >>>>>>MMIO BAR.
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> > > > >>>>>offset or BAR in the config space.
> > > > >>>>>
> > > > >>>>>And guy who are responsible for the native driver seems not be accept to
> > > > >>>>>extend some magic offset of an existing MMIO BAR.
> > > > >>>>>
> > > > >>>>>In addition I think in a short time its not possible to migrate i440fx to
> > > > >>>>>q35 as a PCIe machine of xen.
> > > > >>>>
> > > > >>>>That seems like a weak motivation.  I don't see a need to get something
> > > > >>>>merged upstream in a short time: this seems sure to miss 2.1,
> > > > >>>>so you have the time to make it architecturally sound.
> > > > >>>>"Making existing guests work" would be a better motivation.
> > > > >>>
> > > > >>>Yes.
> > > > >>
> > > > >>So focus on this then. Existing guests will probably work
> > > > >>fine on a newer chipset - likely better than on i440fx.
> > > > >>xen management tools need to do some work to support this?
> > > > >
> > > > >Unfortunately existing Windows guests don't take well chipset changes.
> > > > >Windows might request a new activation.
> > > > 
> > > > That is a very good point. A while back I did a bunch of work to try to keep
> > > > Windows activated between running an instance of Windows on bare metal and
> > > > as a VM. There were numerous bits of hardware and firmware that went into
> > > > the calculation as to whether Windows thought it was the same platform for
> > > > activation purposes. Changing the chipset sounds like a likely candidate for
> > > > inspection. Somewhere out there on the webs is a partial list of the things
> > > > that are inspected - lost the URL.
> > > 
> > > It's not hard to try it out with kvm (you just need to remember to use ide with
> > > q35: ahci is the default there).  I did, and windows did not ask me to
> > > re-activate.
> > > 
> > > The detailed info is not hard to find:
> > > http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> > > links to:
> > > http://technet.microsoft.com/en-us/library/bb457054.aspx
> > > 
> > > 
> > > 1
> > > Display Adapter
> > > 00010 (5)
> > > 2
> > > SCSI Adapter
> > > 00011 (5)
> > > 3
> > > IDE Adapter
> > > 0011 (4)
> > > 4
> > > Network Adapter MAC Address
> > > 1001011000 (10)
> > > 5
> > > RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> > > 101 (3)
> > > 6
> > > Processor Type
> > > 011 (3)
> > > 7
> > > Processor Serial Number
> > > 000000 (6)
> > > 8
> > > Hard Drive Device
> > > 1101100 (7)
> > > 9
> > > Hard Drive Volume Serial Number
> > > 1001000001 (10)
> > > 10
> > > CD—ROM / CD-RW / DVD-ROM
> > > 010111 (6)
> > > -
> > > "Dockable"
> > > 0 (1)
> > > -
> > > Hardware Hash version (version of algorithm used)
> > > 001 (3)
> > > 
> > > So no, chipset version won't cause re-activation.
> > 
> > The page you linked is about Windows XP. Newer Windows versions have
> > stricter activation rules.  I don't think that moving existing VM images
> > from piix to q35 could be done without extensive testing of all the
> > major existing operating system images. I certainly wouldn't rely on a
> > wikipedia page for this.
> 
> So do the testing then.
> You don't even need to do anything on xen - run them all on kvm.
> This testing will benefit everyone.

Sure, test results on KVM would be reusable for Xen and vice versa.
Indeed they would benefit everybody.  I don't have the bandwidth for
this but I would encourage somebody in the community to step up and test
Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003,
Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.

Paul, did I miss anything important?


> > Also I don't like the idea of tying Tiejun's patch series, that covers a
> > very narrow use case, to something as important and general purpose as
> > upgrading chipset.
> 
> If it's true that implementing igd passthrough on top of q35 is much
> cleaner architecturally, then I don't see why we should merge a stop-gap
> solution that we'll need to then support indefinitely.
>
> We are talking about upstreaming functionality that xen already has, right?
> So there's no time to market concern, whoever wants a solution today
> has it.  Why not do it in the cleanest possible way?

I don't know if it is actually the case that building it on q35 would be
much cleaner architecturally. If it was true, it would be worth thinking
about. However I don't know if we can ask Tiejun to undertake a task
that is significantly different and an order of magnitude bigger than
his current effort in order to upstream his series, that has a much
narrower scope.

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 07:20:26PM +0100, Stefano Stabellini wrote:
> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> > On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
> > > On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> > > > On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> > > > > On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> > > > > >On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> > > > > >>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > > > > >>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > > > > >>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > > > > >>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > > > > >>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> > > > > >>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>Are you saying the config space in the video device?
> > > > > >>>>>>
> > > > > >>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> > > > > >>>>>>MMIO BAR.
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> > > > > >>>>>offset or BAR in the config space.
> > > > > >>>>>
> > > > > >>>>>And guy who are responsible for the native driver seems not be accept to
> > > > > >>>>>extend some magic offset of an existing MMIO BAR.
> > > > > >>>>>
> > > > > >>>>>In addition I think in a short time its not possible to migrate i440fx to
> > > > > >>>>>q35 as a PCIe machine of xen.
> > > > > >>>>
> > > > > >>>>That seems like a weak motivation.  I don't see a need to get something
> > > > > >>>>merged upstream in a short time: this seems sure to miss 2.1,
> > > > > >>>>so you have the time to make it architecturally sound.
> > > > > >>>>"Making existing guests work" would be a better motivation.
> > > > > >>>
> > > > > >>>Yes.
> > > > > >>
> > > > > >>So focus on this then. Existing guests will probably work
> > > > > >>fine on a newer chipset - likely better than on i440fx.
> > > > > >>xen management tools need to do some work to support this?
> > > > > >
> > > > > >Unfortunately existing Windows guests don't take well chipset changes.
> > > > > >Windows might request a new activation.
> > > > > 
> > > > > That is a very good point. A while back I did a bunch of work to try to keep
> > > > > Windows activated between running an instance of Windows on bare metal and
> > > > > as a VM. There were numerous bits of hardware and firmware that went into
> > > > > the calculation as to whether Windows thought it was the same platform for
> > > > > activation purposes. Changing the chipset sounds like a likely candidate for
> > > > > inspection. Somewhere out there on the webs is a partial list of the things
> > > > > that are inspected - lost the URL.
> > > > 
> > > > It's not hard to try it out with kvm (you just need to remember to use ide with
> > > > q35: ahci is the default there).  I did, and windows did not ask me to
> > > > re-activate.
> > > > 
> > > > The detailed info is not hard to find:
> > > > http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> > > > links to:
> > > > http://technet.microsoft.com/en-us/library/bb457054.aspx
> > > > 
> > > > 
> > > > 1
> > > > Display Adapter
> > > > 00010 (5)
> > > > 2
> > > > SCSI Adapter
> > > > 00011 (5)
> > > > 3
> > > > IDE Adapter
> > > > 0011 (4)
> > > > 4
> > > > Network Adapter MAC Address
> > > > 1001011000 (10)
> > > > 5
> > > > RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> > > > 101 (3)
> > > > 6
> > > > Processor Type
> > > > 011 (3)
> > > > 7
> > > > Processor Serial Number
> > > > 000000 (6)
> > > > 8
> > > > Hard Drive Device
> > > > 1101100 (7)
> > > > 9
> > > > Hard Drive Volume Serial Number
> > > > 1001000001 (10)
> > > > 10
> > > > CD—ROM / CD-RW / DVD-ROM
> > > > 010111 (6)
> > > > -
> > > > "Dockable"
> > > > 0 (1)
> > > > -
> > > > Hardware Hash version (version of algorithm used)
> > > > 001 (3)
> > > > 
> > > > So no, chipset version won't cause re-activation.
> > > 
> > > The page you linked is about Windows XP. Newer Windows versions have
> > > stricter activation rules.  I don't think that moving existing VM images
> > > from piix to q35 could be done without extensive testing of all the
> > > major existing operating system images. I certainly wouldn't rely on a
> > > wikipedia page for this.
> > 
> > So do the testing then.
> > You don't even need to do anything on xen - run them all on kvm.
> > This testing will benefit everyone.
> 
> Sure, test results on KVM would be reusable for Xen and vice versa.
> Indeed they would benefit everybody.  I don't have the bandwidth for
> this but I would encourage somebody in the community to step up and test
> Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003,
> Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.
> 
> Paul, did I miss anything important?
> 
> 
> > > Also I don't like the idea of tying Tiejun's patch series, that covers a
> > > very narrow use case, to something as important and general purpose as
> > > upgrading chipset.
> > 
> > If it's true that implementing igd passthrough on top of q35 is much
> > cleaner architecturally, then I don't see why we should merge a stop-gap
> > solution that we'll need to then support indefinitely.
> >
> > We are talking about upstreaming functionality that xen already has, right?
> > So there's no time to market concern, whoever wants a solution today
> > has it.  Why not do it in the cleanest possible way?
> 
> I don't know if it is actually the case that building it on q35 would be
> much cleaner architecturally. If it was true, it would be worth thinking
> about. However I don't know if we can ask Tiejun to undertake a task
> that is significantly different and an order of magnitude bigger than
> his current effort in order to upstream his series, that has a much
> narrower scope.

A simple solution would be for Tiejun to work on this support for kvm
instead.

Once someone else works to
1. Add mch support to Xen
2. Unify device assignment code

Then Xen will get the feature for free.

;)

-- 
MST

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Tue, Jul 01, 2014 at 07:20:26PM +0100, Stefano Stabellini wrote:
> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> > On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
> > > On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> > > > On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> > > > > On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> > > > > >On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> > > > > >>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > > > > >>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > > > > >>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > > > > >>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > > > > >>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> > > > > >>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>Are you saying the config space in the video device?
> > > > > >>>>>>
> > > > > >>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> > > > > >>>>>>MMIO BAR.
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> > > > > >>>>>offset or BAR in the config space.
> > > > > >>>>>
> > > > > >>>>>And guy who are responsible for the native driver seems not be accept to
> > > > > >>>>>extend some magic offset of an existing MMIO BAR.
> > > > > >>>>>
> > > > > >>>>>In addition I think in a short time its not possible to migrate i440fx to
> > > > > >>>>>q35 as a PCIe machine of xen.
> > > > > >>>>
> > > > > >>>>That seems like a weak motivation.  I don't see a need to get something
> > > > > >>>>merged upstream in a short time: this seems sure to miss 2.1,
> > > > > >>>>so you have the time to make it architecturally sound.
> > > > > >>>>"Making existing guests work" would be a better motivation.
> > > > > >>>
> > > > > >>>Yes.
> > > > > >>
> > > > > >>So focus on this then. Existing guests will probably work
> > > > > >>fine on a newer chipset - likely better than on i440fx.
> > > > > >>xen management tools need to do some work to support this?
> > > > > >
> > > > > >Unfortunately existing Windows guests don't take well chipset changes.
> > > > > >Windows might request a new activation.
> > > > > 
> > > > > That is a very good point. A while back I did a bunch of work to try to keep
> > > > > Windows activated between running an instance of Windows on bare metal and
> > > > > as a VM. There were numerous bits of hardware and firmware that went into
> > > > > the calculation as to whether Windows thought it was the same platform for
> > > > > activation purposes. Changing the chipset sounds like a likely candidate for
> > > > > inspection. Somewhere out there on the webs is a partial list of the things
> > > > > that are inspected - lost the URL.
> > > > 
> > > > It's not hard to try it out with kvm (you just need to remember to use ide with
> > > > q35: ahci is the default there).  I did, and windows did not ask me to
> > > > re-activate.
> > > > 
> > > > The detailed info is not hard to find:
> > > > http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> > > > links to:
> > > > http://technet.microsoft.com/en-us/library/bb457054.aspx
> > > > 
> > > > 
> > > > 1
> > > > Display Adapter
> > > > 00010 (5)
> > > > 2
> > > > SCSI Adapter
> > > > 00011 (5)
> > > > 3
> > > > IDE Adapter
> > > > 0011 (4)
> > > > 4
> > > > Network Adapter MAC Address
> > > > 1001011000 (10)
> > > > 5
> > > > RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> > > > 101 (3)
> > > > 6
> > > > Processor Type
> > > > 011 (3)
> > > > 7
> > > > Processor Serial Number
> > > > 000000 (6)
> > > > 8
> > > > Hard Drive Device
> > > > 1101100 (7)
> > > > 9
> > > > Hard Drive Volume Serial Number
> > > > 1001000001 (10)
> > > > 10
> > > > CD—ROM / CD-RW / DVD-ROM
> > > > 010111 (6)
> > > > -
> > > > "Dockable"
> > > > 0 (1)
> > > > -
> > > > Hardware Hash version (version of algorithm used)
> > > > 001 (3)
> > > > 
> > > > So no, chipset version won't cause re-activation.
> > > 
> > > The page you linked is about Windows XP. Newer Windows versions have
> > > stricter activation rules.  I don't think that moving existing VM images
> > > from piix to q35 could be done without extensive testing of all the
> > > major existing operating system images. I certainly wouldn't rely on a
> > > wikipedia page for this.
> > 
> > So do the testing then.
> > You don't even need to do anything on xen - run them all on kvm.
> > This testing will benefit everyone.
> 
> Sure, test results on KVM would be reusable for Xen and vice versa.
> Indeed they would benefit everybody.  I don't have the bandwidth for
> this but I would encourage somebody in the community to step up and test
> Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003,
> Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.
> 
> Paul, did I miss anything important?
> 
> 
> > > Also I don't like the idea of tying Tiejun's patch series, that covers a
> > > very narrow use case, to something as important and general purpose as
> > > upgrading chipset.
> > 
> > If it's true that implementing igd passthrough on top of q35 is much
> > cleaner architecturally, then I don't see why we should merge a stop-gap
> > solution that we'll need to then support indefinitely.
> >
> > We are talking about upstreaming functionality that xen already has, right?
> > So there's no time to market concern, whoever wants a solution today
> > has it.  Why not do it in the cleanest possible way?
> 
> I don't know if it is actually the case that building it on q35 would be
> much cleaner architecturally. If it was true, it would be worth thinking
> about. However I don't know if we can ask Tiejun to undertake a task
> that is significantly different and an order of magnitude bigger than
> his current effort in order to upstream his series, that has a much
> narrower scope.

A simple solution would be for Tiejun to work on this support for kvm
instead.

Once someone else works to
1. Add mch support to Xen
2. Unify device assignment code

Then Xen will get the feature for free.

;)

-- 
MST

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/2 2:20, Stefano Stabellini wrote:
> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
>> On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
>>> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
>>>> On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
>>>>> On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
>>>>>> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>>
>>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>>> MMIO BAR.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>>
>>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>>
>>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>>
>>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>
>>>>>>> So focus on this then. Existing guests will probably work
>>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>>> xen management tools need to do some work to support this?
>>>>>>
>>>>>> Unfortunately existing Windows guests don't take well chipset changes.
>>>>>> Windows might request a new activation.
>>>>>
>>>>> That is a very good point. A while back I did a bunch of work to try to keep
>>>>> Windows activated between running an instance of Windows on bare metal and
>>>>> as a VM. There were numerous bits of hardware and firmware that went into
>>>>> the calculation as to whether Windows thought it was the same platform for
>>>>> activation purposes. Changing the chipset sounds like a likely candidate for
>>>>> inspection. Somewhere out there on the webs is a partial list of the things
>>>>> that are inspected - lost the URL.
>>>>
>>>> It's not hard to try it out with kvm (you just need to remember to use ide with
>>>> q35: ahci is the default there).  I did, and windows did not ask me to
>>>> re-activate.
>>>>
>>>> The detailed info is not hard to find:
>>>> http://en.wikipedia.org/wiki/Microsoft_Product_Activation
>>>> links to:
>>>> http://technet.microsoft.com/en-us/library/bb457054.aspx
>>>>
>>>>
>>>> 1
>>>> Display Adapter
>>>> 00010 (5)
>>>> 2
>>>> SCSI Adapter
>>>> 00011 (5)
>>>> 3
>>>> IDE Adapter
>>>> 0011 (4)
>>>> 4
>>>> Network Adapter MAC Address
>>>> 1001011000 (10)
>>>> 5
>>>> RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
>>>> 101 (3)
>>>> 6
>>>> Processor Type
>>>> 011 (3)
>>>> 7
>>>> Processor Serial Number
>>>> 000000 (6)
>>>> 8
>>>> Hard Drive Device
>>>> 1101100 (7)
>>>> 9
>>>> Hard Drive Volume Serial Number
>>>> 1001000001 (10)
>>>> 10
>>>> CD—ROM / CD-RW / DVD-ROM
>>>> 010111 (6)
>>>> -
>>>> "Dockable"
>>>> 0 (1)
>>>> -
>>>> Hardware Hash version (version of algorithm used)
>>>> 001 (3)
>>>>
>>>> So no, chipset version won't cause re-activation.
>>>
>>> The page you linked is about Windows XP. Newer Windows versions have
>>> stricter activation rules.  I don't think that moving existing VM images
>>> from piix to q35 could be done without extensive testing of all the
>>> major existing operating system images. I certainly wouldn't rely on a
>>> wikipedia page for this.
>>
>> So do the testing then.
>> You don't even need to do anything on xen - run them all on kvm.
>> This testing will benefit everyone.
>
> Sure, test results on KVM would be reusable for Xen and vice versa.
> Indeed they would benefit everybody.  I don't have the bandwidth for
> this but I would encourage somebody in the community to step up and test
> Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003,
> Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.
>
> Paul, did I miss anything important?
>
>
>>> Also I don't like the idea of tying Tiejun's patch series, that covers a
>>> very narrow use case, to something as important and general purpose as
>>> upgrading chipset.
>>
>> If it's true that implementing igd passthrough on top of q35 is much
>> cleaner architecturally, then I don't see why we should merge a stop-gap
>> solution that we'll need to then support indefinitely.
>>
>> We are talking about upstreaming functionality that xen already has, right?
>> So there's no time to market concern, whoever wants a solution today
>> has it.  Why not do it in the cleanest possible way?
>
> I don't know if it is actually the case that building it on q35 would be
> much cleaner architecturally. If it was true, it would be worth thinking
> about. However I don't know if we can ask Tiejun to undertake a task

It really doesn't matter to me since this improvement is fine. But as 
you can image, I'm not sure how long/how much I can contribute to this 
task recently :)

Sounds we will schedule a meeting to discuss this case, and maybe some 
of you guys would be invited as well. Once we have a workable plan, then 
we can do this step by step without any further arguments.

Thanks
Tiejun

> that is significantly different and an order of magnitude bigger than
> his current effort in order to upstream his series, that has a much
> narrower scope.
>

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/2 2:20, Stefano Stabellini wrote:
> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
>> On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
>>> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
>>>> On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
>>>>> On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
>>>>>> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>>
>>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>>> MMIO BAR.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>>
>>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>>
>>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>>
>>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>
>>>>>>> So focus on this then. Existing guests will probably work
>>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>>> xen management tools need to do some work to support this?
>>>>>>
>>>>>> Unfortunately existing Windows guests don't take well chipset changes.
>>>>>> Windows might request a new activation.
>>>>>
>>>>> That is a very good point. A while back I did a bunch of work to try to keep
>>>>> Windows activated between running an instance of Windows on bare metal and
>>>>> as a VM. There were numerous bits of hardware and firmware that went into
>>>>> the calculation as to whether Windows thought it was the same platform for
>>>>> activation purposes. Changing the chipset sounds like a likely candidate for
>>>>> inspection. Somewhere out there on the webs is a partial list of the things
>>>>> that are inspected - lost the URL.
>>>>
>>>> It's not hard to try it out with kvm (you just need to remember to use ide with
>>>> q35: ahci is the default there).  I did, and windows did not ask me to
>>>> re-activate.
>>>>
>>>> The detailed info is not hard to find:
>>>> http://en.wikipedia.org/wiki/Microsoft_Product_Activation
>>>> links to:
>>>> http://technet.microsoft.com/en-us/library/bb457054.aspx
>>>>
>>>>
>>>> 1
>>>> Display Adapter
>>>> 00010 (5)
>>>> 2
>>>> SCSI Adapter
>>>> 00011 (5)
>>>> 3
>>>> IDE Adapter
>>>> 0011 (4)
>>>> 4
>>>> Network Adapter MAC Address
>>>> 1001011000 (10)
>>>> 5
>>>> RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
>>>> 101 (3)
>>>> 6
>>>> Processor Type
>>>> 011 (3)
>>>> 7
>>>> Processor Serial Number
>>>> 000000 (6)
>>>> 8
>>>> Hard Drive Device
>>>> 1101100 (7)
>>>> 9
>>>> Hard Drive Volume Serial Number
>>>> 1001000001 (10)
>>>> 10
>>>> CD—ROM / CD-RW / DVD-ROM
>>>> 010111 (6)
>>>> -
>>>> "Dockable"
>>>> 0 (1)
>>>> -
>>>> Hardware Hash version (version of algorithm used)
>>>> 001 (3)
>>>>
>>>> So no, chipset version won't cause re-activation.
>>>
>>> The page you linked is about Windows XP. Newer Windows versions have
>>> stricter activation rules.  I don't think that moving existing VM images
>>> from piix to q35 could be done without extensive testing of all the
>>> major existing operating system images. I certainly wouldn't rely on a
>>> wikipedia page for this.
>>
>> So do the testing then.
>> You don't even need to do anything on xen - run them all on kvm.
>> This testing will benefit everyone.
>
> Sure, test results on KVM would be reusable for Xen and vice versa.
> Indeed they would benefit everybody.  I don't have the bandwidth for
> this but I would encourage somebody in the community to step up and test
> Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003,
> Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.
>
> Paul, did I miss anything important?
>
>
>>> Also I don't like the idea of tying Tiejun's patch series, that covers a
>>> very narrow use case, to something as important and general purpose as
>>> upgrading chipset.
>>
>> If it's true that implementing igd passthrough on top of q35 is much
>> cleaner architecturally, then I don't see why we should merge a stop-gap
>> solution that we'll need to then support indefinitely.
>>
>> We are talking about upstreaming functionality that xen already has, right?
>> So there's no time to market concern, whoever wants a solution today
>> has it.  Why not do it in the cleanest possible way?
>
> I don't know if it is actually the case that building it on q35 would be
> much cleaner architecturally. If it was true, it would be worth thinking
> about. However I don't know if we can ask Tiejun to undertake a task

It really doesn't matter to me since this improvement is fine. But as 
you can image, I'm not sure how long/how much I can contribute to this 
task recently :)

Sounds we will schedule a meeting to discuss this case, and maybe some 
of you guys would be invited as well. Once we have a workable plan, then 
we can do this step by step without any further arguments.

Thanks
Tiejun

> that is significantly different and an order of magnitude bigger than
> his current effort in order to upstream his series, that has a much
> narrower scope.
>

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 09:37:44AM +0800, Chen, Tiejun wrote:
> On 2014/7/2 2:20, Stefano Stabellini wrote:
> >On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> >>On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
> >>>On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> >>>>On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> >>>>>On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> >>>>>>On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> >>>>>>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>>>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>Are you saying the config space in the video device?
> >>>>>>>>>>>
> >>>>>>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>>>>>MMIO BAR.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>>>>>offset or BAR in the config space.
> >>>>>>>>>>
> >>>>>>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>>>>>
> >>>>>>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>>>>>q35 as a PCIe machine of xen.
> >>>>>>>>>
> >>>>>>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>>>>>so you have the time to make it architecturally sound.
> >>>>>>>>>"Making existing guests work" would be a better motivation.
> >>>>>>>>
> >>>>>>>>Yes.
> >>>>>>>
> >>>>>>>So focus on this then. Existing guests will probably work
> >>>>>>>fine on a newer chipset - likely better than on i440fx.
> >>>>>>>xen management tools need to do some work to support this?
> >>>>>>
> >>>>>>Unfortunately existing Windows guests don't take well chipset changes.
> >>>>>>Windows might request a new activation.
> >>>>>
> >>>>>That is a very good point. A while back I did a bunch of work to try to keep
> >>>>>Windows activated between running an instance of Windows on bare metal and
> >>>>>as a VM. There were numerous bits of hardware and firmware that went into
> >>>>>the calculation as to whether Windows thought it was the same platform for
> >>>>>activation purposes. Changing the chipset sounds like a likely candidate for
> >>>>>inspection. Somewhere out there on the webs is a partial list of the things
> >>>>>that are inspected - lost the URL.
> >>>>
> >>>>It's not hard to try it out with kvm (you just need to remember to use ide with
> >>>>q35: ahci is the default there).  I did, and windows did not ask me to
> >>>>re-activate.
> >>>>
> >>>>The detailed info is not hard to find:
> >>>>http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> >>>>links to:
> >>>>http://technet.microsoft.com/en-us/library/bb457054.aspx
> >>>>
> >>>>
> >>>>1
> >>>>Display Adapter
> >>>>00010 (5)
> >>>>2
> >>>>SCSI Adapter
> >>>>00011 (5)
> >>>>3
> >>>>IDE Adapter
> >>>>0011 (4)
> >>>>4
> >>>>Network Adapter MAC Address
> >>>>1001011000 (10)
> >>>>5
> >>>>RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> >>>>101 (3)
> >>>>6
> >>>>Processor Type
> >>>>011 (3)
> >>>>7
> >>>>Processor Serial Number
> >>>>000000 (6)
> >>>>8
> >>>>Hard Drive Device
> >>>>1101100 (7)
> >>>>9
> >>>>Hard Drive Volume Serial Number
> >>>>1001000001 (10)
> >>>>10
> >>>>CD—ROM / CD-RW / DVD-ROM
> >>>>010111 (6)
> >>>>-
> >>>>"Dockable"
> >>>>0 (1)
> >>>>-
> >>>>Hardware Hash version (version of algorithm used)
> >>>>001 (3)
> >>>>
> >>>>So no, chipset version won't cause re-activation.
> >>>
> >>>The page you linked is about Windows XP. Newer Windows versions have
> >>>stricter activation rules.  I don't think that moving existing VM images
> >>>from piix to q35 could be done without extensive testing of all the
> >>>major existing operating system images. I certainly wouldn't rely on a
> >>>wikipedia page for this.
> >>
> >>So do the testing then.
> >>You don't even need to do anything on xen - run them all on kvm.
> >>This testing will benefit everyone.
> >
> >Sure, test results on KVM would be reusable for Xen and vice versa.
> >Indeed they would benefit everybody.  I don't have the bandwidth for
> >this but I would encourage somebody in the community to step up and test
> >Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003,
> >Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.
> >
> >Paul, did I miss anything important?
> >
> >
> >>>Also I don't like the idea of tying Tiejun's patch series, that covers a
> >>>very narrow use case, to something as important and general purpose as
> >>>upgrading chipset.
> >>
> >>If it's true that implementing igd passthrough on top of q35 is much
> >>cleaner architecturally, then I don't see why we should merge a stop-gap
> >>solution that we'll need to then support indefinitely.
> >>
> >>We are talking about upstreaming functionality that xen already has, right?
> >>So there's no time to market concern, whoever wants a solution today
> >>has it.  Why not do it in the cleanest possible way?
> >
> >I don't know if it is actually the case that building it on q35 would be
> >much cleaner architecturally. If it was true, it would be worth thinking
> >about. However I don't know if we can ask Tiejun to undertake a task
> 
> It really doesn't matter to me since this improvement is fine. But as you
> can image, I'm not sure how long/how much I can contribute to this task
> recently :)
> 
> Sounds we will schedule a meeting to discuss this case, and maybe some of
> you guys would be invited as well. Once we have a workable plan, then we can
> do this step by step without any further arguments.
> 
> Thanks
> Tiejun

Would you like to start by creating a feature page for your project
on QEMU wiki?  List design goals and non-goals.  Which guests would you
like to work? Etc.

Most importantly, include the issues raised on list with the latest
series.  As it is I'm concerned that issues get mixed up with
suggestions for addressing them.



> >that is significantly different and an order of magnitude bigger than
> >his current effort in order to upstream his series, that has a much
> >narrower scope.
> >

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jul 02, 2014 at 09:37:44AM +0800, Chen, Tiejun wrote:
> On 2014/7/2 2:20, Stefano Stabellini wrote:
> >On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> >>On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
> >>>On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
> >>>>On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
> >>>>>On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
> >>>>>>On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> >>>>>>>On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>>>>>>>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>>>>>>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>>>>>>>>>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>>>>>>>>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>- offsets 0x0000..0x0fff map to configuration space of the host MCH
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>Are you saying the config space in the video device?
> >>>>>>>>>>>
> >>>>>>>>>>>No, I am saying in a new BAR, or at some magic offset of an existing
> >>>>>>>>>>>MMIO BAR.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>As I mentioned previously, the IGD guy told me we have no any unused a
> >>>>>>>>>>offset or BAR in the config space.
> >>>>>>>>>>
> >>>>>>>>>>And guy who are responsible for the native driver seems not be accept to
> >>>>>>>>>>extend some magic offset of an existing MMIO BAR.
> >>>>>>>>>>
> >>>>>>>>>>In addition I think in a short time its not possible to migrate i440fx to
> >>>>>>>>>>q35 as a PCIe machine of xen.
> >>>>>>>>>
> >>>>>>>>>That seems like a weak motivation.  I don't see a need to get something
> >>>>>>>>>merged upstream in a short time: this seems sure to miss 2.1,
> >>>>>>>>>so you have the time to make it architecturally sound.
> >>>>>>>>>"Making existing guests work" would be a better motivation.
> >>>>>>>>
> >>>>>>>>Yes.
> >>>>>>>
> >>>>>>>So focus on this then. Existing guests will probably work
> >>>>>>>fine on a newer chipset - likely better than on i440fx.
> >>>>>>>xen management tools need to do some work to support this?
> >>>>>>
> >>>>>>Unfortunately existing Windows guests don't take well chipset changes.
> >>>>>>Windows might request a new activation.
> >>>>>
> >>>>>That is a very good point. A while back I did a bunch of work to try to keep
> >>>>>Windows activated between running an instance of Windows on bare metal and
> >>>>>as a VM. There were numerous bits of hardware and firmware that went into
> >>>>>the calculation as to whether Windows thought it was the same platform for
> >>>>>activation purposes. Changing the chipset sounds like a likely candidate for
> >>>>>inspection. Somewhere out there on the webs is a partial list of the things
> >>>>>that are inspected - lost the URL.
> >>>>
> >>>>It's not hard to try it out with kvm (you just need to remember to use ide with
> >>>>q35: ahci is the default there).  I did, and windows did not ask me to
> >>>>re-activate.
> >>>>
> >>>>The detailed info is not hard to find:
> >>>>http://en.wikipedia.org/wiki/Microsoft_Product_Activation
> >>>>links to:
> >>>>http://technet.microsoft.com/en-us/library/bb457054.aspx
> >>>>
> >>>>
> >>>>1
> >>>>Display Adapter
> >>>>00010 (5)
> >>>>2
> >>>>SCSI Adapter
> >>>>00011 (5)
> >>>>3
> >>>>IDE Adapter
> >>>>0011 (4)
> >>>>4
> >>>>Network Adapter MAC Address
> >>>>1001011000 (10)
> >>>>5
> >>>>RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
> >>>>101 (3)
> >>>>6
> >>>>Processor Type
> >>>>011 (3)
> >>>>7
> >>>>Processor Serial Number
> >>>>000000 (6)
> >>>>8
> >>>>Hard Drive Device
> >>>>1101100 (7)
> >>>>9
> >>>>Hard Drive Volume Serial Number
> >>>>1001000001 (10)
> >>>>10
> >>>>CD—ROM / CD-RW / DVD-ROM
> >>>>010111 (6)
> >>>>-
> >>>>"Dockable"
> >>>>0 (1)
> >>>>-
> >>>>Hardware Hash version (version of algorithm used)
> >>>>001 (3)
> >>>>
> >>>>So no, chipset version won't cause re-activation.
> >>>
> >>>The page you linked is about Windows XP. Newer Windows versions have
> >>>stricter activation rules.  I don't think that moving existing VM images
> >>>from piix to q35 could be done without extensive testing of all the
> >>>major existing operating system images. I certainly wouldn't rely on a
> >>>wikipedia page for this.
> >>
> >>So do the testing then.
> >>You don't even need to do anything on xen - run them all on kvm.
> >>This testing will benefit everyone.
> >
> >Sure, test results on KVM would be reusable for Xen and vice versa.
> >Indeed they would benefit everybody.  I don't have the bandwidth for
> >this but I would encourage somebody in the community to step up and test
> >Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003,
> >Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.
> >
> >Paul, did I miss anything important?
> >
> >
> >>>Also I don't like the idea of tying Tiejun's patch series, that covers a
> >>>very narrow use case, to something as important and general purpose as
> >>>upgrading chipset.
> >>
> >>If it's true that implementing igd passthrough on top of q35 is much
> >>cleaner architecturally, then I don't see why we should merge a stop-gap
> >>solution that we'll need to then support indefinitely.
> >>
> >>We are talking about upstreaming functionality that xen already has, right?
> >>So there's no time to market concern, whoever wants a solution today
> >>has it.  Why not do it in the cleanest possible way?
> >
> >I don't know if it is actually the case that building it on q35 would be
> >much cleaner architecturally. If it was true, it would be worth thinking
> >about. However I don't know if we can ask Tiejun to undertake a task
> 
> It really doesn't matter to me since this improvement is fine. But as you
> can image, I'm not sure how long/how much I can contribute to this task
> recently :)
> 
> Sounds we will schedule a meeting to discuss this case, and maybe some of
> you guys would be invited as well. Once we have a workable plan, then we can
> do this step by step without any further arguments.
> 
> Thanks
> Tiejun

Would you like to start by creating a feature page for your project
on QEMU wiki?  List design goals and non-goals.  Which guests would you
like to work? Etc.

Most importantly, include the issues raised on list with the latest
series.  As it is I'm concerned that issues get mixed up with
suggestions for addressing them.



> >that is significantly different and an order of magnitude bigger than
> >his current effort in order to upstream his series, that has a much
> >narrower scope.
> >

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/2 14:09, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 09:37:44AM +0800, Chen, Tiejun wrote:
>> On 2014/7/2 2:20, Stefano Stabellini wrote:
>>> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
>>>> On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
>>>>> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
>>>>>> On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
>>>>>>> On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
>>>>>>>> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>>>>> MMIO BAR.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>>>>
>>>>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>>>>
>>>>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>>>>
>>>>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>> So focus on this then. Existing guests will probably work
>>>>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>>>>> xen management tools need to do some work to support this?
>>>>>>>>
>>>>>>>> Unfortunately existing Windows guests don't take well chipset changes.
>>>>>>>> Windows might request a new activation.
>>>>>>>
>>>>>>> That is a very good point. A while back I did a bunch of work to try to keep
>>>>>>> Windows activated between running an instance of Windows on bare metal and
>>>>>>> as a VM. There were numerous bits of hardware and firmware that went into
>>>>>>> the calculation as to whether Windows thought it was the same platform for
>>>>>>> activation purposes. Changing the chipset sounds like a likely candidate for
>>>>>>> inspection. Somewhere out there on the webs is a partial list of the things
>>>>>>> that are inspected - lost the URL.
>>>>>>
>>>>>> It's not hard to try it out with kvm (you just need to remember to use ide with
>>>>>> q35: ahci is the default there).  I did, and windows did not ask me to
>>>>>> re-activate.
>>>>>>
>>>>>> The detailed info is not hard to find:
>>>>>> http://en.wikipedia.org/wiki/Microsoft_Product_Activation
>>>>>> links to:
>>>>>> http://technet.microsoft.com/en-us/library/bb457054.aspx
>>>>>>
>>>>>>
>>>>>> 1
>>>>>> Display Adapter
>>>>>> 00010 (5)
>>>>>> 2
>>>>>> SCSI Adapter
>>>>>> 00011 (5)
>>>>>> 3
>>>>>> IDE Adapter
>>>>>> 0011 (4)
>>>>>> 4
>>>>>> Network Adapter MAC Address
>>>>>> 1001011000 (10)
>>>>>> 5
>>>>>> RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
>>>>>> 101 (3)
>>>>>> 6
>>>>>> Processor Type
>>>>>> 011 (3)
>>>>>> 7
>>>>>> Processor Serial Number
>>>>>> 000000 (6)
>>>>>> 8
>>>>>> Hard Drive Device
>>>>>> 1101100 (7)
>>>>>> 9
>>>>>> Hard Drive Volume Serial Number
>>>>>> 1001000001 (10)
>>>>>> 10
>>>>>> CD—ROM / CD-RW / DVD-ROM
>>>>>> 010111 (6)
>>>>>> -
>>>>>> "Dockable"
>>>>>> 0 (1)
>>>>>> -
>>>>>> Hardware Hash version (version of algorithm used)
>>>>>> 001 (3)
>>>>>>
>>>>>> So no, chipset version won't cause re-activation.
>>>>>
>>>>> The page you linked is about Windows XP. Newer Windows versions have
>>>>> stricter activation rules.  I don't think that moving existing VM images
>>>> >from piix to q35 could be done without extensive testing of all the
>>>>> major existing operating system images. I certainly wouldn't rely on a
>>>>> wikipedia page for this.
>>>>
>>>> So do the testing then.
>>>> You don't even need to do anything on xen - run them all on kvm.
>>>> This testing will benefit everyone.
>>>
>>> Sure, test results on KVM would be reusable for Xen and vice versa.
>>> Indeed they would benefit everybody.  I don't have the bandwidth for
>>> this but I would encourage somebody in the community to step up and test
>>> Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003,
>>> Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.
>>>
>>> Paul, did I miss anything important?
>>>
>>>
>>>>> Also I don't like the idea of tying Tiejun's patch series, that covers a
>>>>> very narrow use case, to something as important and general purpose as
>>>>> upgrading chipset.
>>>>
>>>> If it's true that implementing igd passthrough on top of q35 is much
>>>> cleaner architecturally, then I don't see why we should merge a stop-gap
>>>> solution that we'll need to then support indefinitely.
>>>>
>>>> We are talking about upstreaming functionality that xen already has, right?
>>>> So there's no time to market concern, whoever wants a solution today
>>>> has it.  Why not do it in the cleanest possible way?
>>>
>>> I don't know if it is actually the case that building it on q35 would be
>>> much cleaner architecturally. If it was true, it would be worth thinking
>>> about. However I don't know if we can ask Tiejun to undertake a task
>>
>> It really doesn't matter to me since this improvement is fine. But as you
>> can image, I'm not sure how long/how much I can contribute to this task
>> recently :)
>>
>> Sounds we will schedule a meeting to discuss this case, and maybe some of
>> you guys would be invited as well. Once we have a workable plan, then we can
>> do this step by step without any further arguments.
>>
>> Thanks
>> Tiejun
>
> Would you like to start by creating a feature page for your project
> on QEMU wiki?  List design goals and non-goals.  Which guests would you
> like to work? Etc.

Sorry, I'm already told I shouldn't do anymore before this meeting.

>
> Most importantly, include the issues raised on list with the latest
> series.  As it is I'm concerned that issues get mixed up with
> suggestions for addressing them.

I think you can issue your any requirement or opinions to discuss in the 
meeting. Then as a developer I'd like to follow that outcome of the meeting.

Thanks
Tiejun

>
>
>
>>> that is significantly different and an order of magnitude bigger than
>>> his current effort in order to upstream his series, that has a much
>>> narrower scope.
>>>
>
>

Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/7/2 14:09, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 09:37:44AM +0800, Chen, Tiejun wrote:
>> On 2014/7/2 2:20, Stefano Stabellini wrote:
>>> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
>>>> On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote:
>>>>> On Tue, 1 Jul 2014, Michael S. Tsirkin wrote:
>>>>>> On Mon, Jun 30, 2014 at 03:31:05PM -0400, Ross Philipson wrote:
>>>>>>> On 06/30/2014 03:22 PM, Stefano Stabellini wrote:
>>>>>>>> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
>>>>>>>>>> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
>>>>>>>>>>>> On 2014/6/26 18:03, Paolo Bonzini wrote:
>>>>>>>>>>>>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you saying the config space in the video device?
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, I am saying in a new BAR, or at some magic offset of an existing
>>>>>>>>>>>>> MMIO BAR.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> As I mentioned previously, the IGD guy told me we have no any unused a
>>>>>>>>>>>> offset or BAR in the config space.
>>>>>>>>>>>>
>>>>>>>>>>>> And guy who are responsible for the native driver seems not be accept to
>>>>>>>>>>>> extend some magic offset of an existing MMIO BAR.
>>>>>>>>>>>>
>>>>>>>>>>>> In addition I think in a short time its not possible to migrate i440fx to
>>>>>>>>>>>> q35 as a PCIe machine of xen.
>>>>>>>>>>>
>>>>>>>>>>> That seems like a weak motivation.  I don't see a need to get something
>>>>>>>>>>> merged upstream in a short time: this seems sure to miss 2.1,
>>>>>>>>>>> so you have the time to make it architecturally sound.
>>>>>>>>>>> "Making existing guests work" would be a better motivation.
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>> So focus on this then. Existing guests will probably work
>>>>>>>>> fine on a newer chipset - likely better than on i440fx.
>>>>>>>>> xen management tools need to do some work to support this?
>>>>>>>>
>>>>>>>> Unfortunately existing Windows guests don't take well chipset changes.
>>>>>>>> Windows might request a new activation.
>>>>>>>
>>>>>>> That is a very good point. A while back I did a bunch of work to try to keep
>>>>>>> Windows activated between running an instance of Windows on bare metal and
>>>>>>> as a VM. There were numerous bits of hardware and firmware that went into
>>>>>>> the calculation as to whether Windows thought it was the same platform for
>>>>>>> activation purposes. Changing the chipset sounds like a likely candidate for
>>>>>>> inspection. Somewhere out there on the webs is a partial list of the things
>>>>>>> that are inspected - lost the URL.
>>>>>>
>>>>>> It's not hard to try it out with kvm (you just need to remember to use ide with
>>>>>> q35: ahci is the default there).  I did, and windows did not ask me to
>>>>>> re-activate.
>>>>>>
>>>>>> The detailed info is not hard to find:
>>>>>> http://en.wikipedia.org/wiki/Microsoft_Product_Activation
>>>>>> links to:
>>>>>> http://technet.microsoft.com/en-us/library/bb457054.aspx
>>>>>>
>>>>>>
>>>>>> 1
>>>>>> Display Adapter
>>>>>> 00010 (5)
>>>>>> 2
>>>>>> SCSI Adapter
>>>>>> 00011 (5)
>>>>>> 3
>>>>>> IDE Adapter
>>>>>> 0011 (4)
>>>>>> 4
>>>>>> Network Adapter MAC Address
>>>>>> 1001011000 (10)
>>>>>> 5
>>>>>> RAM Amount Range (i.e. 0-64mb, 64-128mb, etc)
>>>>>> 101 (3)
>>>>>> 6
>>>>>> Processor Type
>>>>>> 011 (3)
>>>>>> 7
>>>>>> Processor Serial Number
>>>>>> 000000 (6)
>>>>>> 8
>>>>>> Hard Drive Device
>>>>>> 1101100 (7)
>>>>>> 9
>>>>>> Hard Drive Volume Serial Number
>>>>>> 1001000001 (10)
>>>>>> 10
>>>>>> CD—ROM / CD-RW / DVD-ROM
>>>>>> 010111 (6)
>>>>>> -
>>>>>> "Dockable"
>>>>>> 0 (1)
>>>>>> -
>>>>>> Hardware Hash version (version of algorithm used)
>>>>>> 001 (3)
>>>>>>
>>>>>> So no, chipset version won't cause re-activation.
>>>>>
>>>>> The page you linked is about Windows XP. Newer Windows versions have
>>>>> stricter activation rules.  I don't think that moving existing VM images
>>>> >from piix to q35 could be done without extensive testing of all the
>>>>> major existing operating system images. I certainly wouldn't rely on a
>>>>> wikipedia page for this.
>>>>
>>>> So do the testing then.
>>>> You don't even need to do anything on xen - run them all on kvm.
>>>> This testing will benefit everyone.
>>>
>>> Sure, test results on KVM would be reusable for Xen and vice versa.
>>> Indeed they would benefit everybody.  I don't have the bandwidth for
>>> this but I would encourage somebody in the community to step up and test
>>> Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003,
>>> Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.
>>>
>>> Paul, did I miss anything important?
>>>
>>>
>>>>> Also I don't like the idea of tying Tiejun's patch series, that covers a
>>>>> very narrow use case, to something as important and general purpose as
>>>>> upgrading chipset.
>>>>
>>>> If it's true that implementing igd passthrough on top of q35 is much
>>>> cleaner architecturally, then I don't see why we should merge a stop-gap
>>>> solution that we'll need to then support indefinitely.
>>>>
>>>> We are talking about upstreaming functionality that xen already has, right?
>>>> So there's no time to market concern, whoever wants a solution today
>>>> has it.  Why not do it in the cleanest possible way?
>>>
>>> I don't know if it is actually the case that building it on q35 would be
>>> much cleaner architecturally. If it was true, it would be worth thinking
>>> about. However I don't know if we can ask Tiejun to undertake a task
>>
>> It really doesn't matter to me since this improvement is fine. But as you
>> can image, I'm not sure how long/how much I can contribute to this task
>> recently :)
>>
>> Sounds we will schedule a meeting to discuss this case, and maybe some of
>> you guys would be invited as well. Once we have a workable plan, then we can
>> do this step by step without any further arguments.
>>
>> Thanks
>> Tiejun
>
> Would you like to start by creating a feature page for your project
> on QEMU wiki?  List design goals and non-goals.  Which guests would you
> like to work? Etc.

Sorry, I'm already told I shouldn't do anymore before this meeting.

>
> Most importantly, include the issues raised on list with the latest
> series.  As it is I'm concerned that issues get mixed up with
> suggestions for addressing them.

I think you can issue your any requirement or opinions to discuss in the 
meeting. Then as a developer I'd like to follow that outcome of the meeting.

Thanks
Tiejun

>
>
>
>>> that is significantly different and an order of magnitude bigger than
>>> his current effort in order to upstream his series, that has a much
>>> narrower scope.
>>>
>
>

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 05:50:16PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:31, Paolo Bonzini wrote:
> >Il 25/06/2014 11:21, Chen, Tiejun ha scritto:
> >>>Adding a vendor-specific capability or BAR
> >>>in an existing device is painful - hard to find
> >>>free space for it.
> >>
> >>Yes, this is a potential risk as well since we can't guarantee current
> >>free space is always valid for ever.
> >
> >For past devices, we know which BARs they use.  For future devices, it
> >would be nice if the PCH/MCH backdoor was specified so that we know they
> >will leave a free BAR for virtualization.
> >
> 
> Now I'm a bit confused about BAR here.
> 
> You're saying we will reserve a free BAR to address those information to
> expose to guest, but which device does this free BAR belong to? The video
> device? Or PCH/MCH?
> 
> Thanks
> Tiejun

If you just want to pass a couple of IDs, then don't, it's a waste.
But I still don't know what problem you are trying to solve,
looking at guest driver did not help.

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 05:50:16PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:31, Paolo Bonzini wrote:
> >Il 25/06/2014 11:21, Chen, Tiejun ha scritto:
> >>>Adding a vendor-specific capability or BAR
> >>>in an existing device is painful - hard to find
> >>>free space for it.
> >>
> >>Yes, this is a potential risk as well since we can't guarantee current
> >>free space is always valid for ever.
> >
> >For past devices, we know which BARs they use.  For future devices, it
> >would be nice if the PCH/MCH backdoor was specified so that we know they
> >will leave a free BAR for virtualization.
> >
> 
> Now I'm a bit confused about BAR here.
> 
> You're saying we will reserve a free BAR to address those information to
> expose to guest, but which device does this free BAR belong to? The video
> device? Or PCH/MCH?
> 
> Thanks
> Tiejun

If you just want to pass a couple of IDs, then don't, it's a waste.
But I still don't know what problem you are trying to solve,
looking at guest driver did not help.

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> > You're saying we will reserve a free BAR to address those information to
> > expose to guest, but which device does this free BAR belong to? The video
> > device? Or PCH/MCH?
>
> If you just want to pass a couple of IDs, then don't, it's a waste.
> But I still don't know what problem you are trying to solve,
> looking at guest driver did not help.

It's not just a couple of IDs, it's also random fields of the MCH 
configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> > You're saying we will reserve a free BAR to address those information to
> > expose to guest, but which device does this free BAR belong to? The video
> > device? Or PCH/MCH?
>
> If you just want to pass a couple of IDs, then don't, it's a waste.
> But I still don't know what problem you are trying to solve,
> looking at guest driver did not help.

It's not just a couple of IDs, it's also random fields of the MCH 
configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 17:59, Paolo Bonzini wrote:
> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
>> > You're saying we will reserve a free BAR to address those
>> information to
>> > expose to guest, but which device does this free BAR belong to? The
>> video
>> > device? Or PCH/MCH?
>>
>> If you just want to pass a couple of IDs, then don't, it's a waste.
>> But I still don't know what problem you are trying to solve,
>> looking at guest driver did not help.
>
> It's not just a couple of IDs, it's also random fields of the MCH
> configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
>

Paolo,

No, we're not pointing the bridge_dev here, which is a host bridge at 
00:00.0.

Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() 
to know why we need this.

Thanks
Tiejun

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 17:59, Paolo Bonzini wrote:
> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
>> > You're saying we will reserve a free BAR to address those
>> information to
>> > expose to guest, but which device does this free BAR belong to? The
>> video
>> > device? Or PCH/MCH?
>>
>> If you just want to pass a couple of IDs, then don't, it's a waste.
>> But I still don't know what problem you are trying to solve,
>> looking at guest driver did not help.
>
> It's not just a couple of IDs, it's also random fields of the MCH
> configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
>

Paolo,

No, we're not pointing the bridge_dev here, which is a host bridge at 
00:00.0.

Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() 
to know why we need this.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:59, Paolo Bonzini wrote:
> >Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >>> You're saying we will reserve a free BAR to address those
> >>information to
> >>> expose to guest, but which device does this free BAR belong to? The
> >>video
> >>> device? Or PCH/MCH?
> >>
> >>If you just want to pass a couple of IDs, then don't, it's a waste.
> >>But I still don't know what problem you are trying to solve,
> >>looking at guest driver did not help.
> >
> >It's not just a couple of IDs, it's also random fields of the MCH
> >configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
> >
> 
> Paolo,
> 
> No, we're not pointing the bridge_dev here, which is a host bridge at
> 00:00.0.
> 
> Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() to
> know why we need this.
> 
> Thanks
> Tiejun
> 

So what if you dont?

        if (!pch)
                DRM_DEBUG_KMS("No PCH found.\n");

Is that all? Seems harmless enough.

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:59, Paolo Bonzini wrote:
> >Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >>> You're saying we will reserve a free BAR to address those
> >>information to
> >>> expose to guest, but which device does this free BAR belong to? The
> >>video
> >>> device? Or PCH/MCH?
> >>
> >>If you just want to pass a couple of IDs, then don't, it's a waste.
> >>But I still don't know what problem you are trying to solve,
> >>looking at guest driver did not help.
> >
> >It's not just a couple of IDs, it's also random fields of the MCH
> >configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
> >
> 
> Paolo,
> 
> No, we're not pointing the bridge_dev here, which is a host bridge at
> 00:00.0.
> 
> Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() to
> know why we need this.
> 
> Thanks
> Tiejun
> 

So what if you dont?

        if (!pch)
                DRM_DEBUG_KMS("No PCH found.\n");

Is that all? Seems harmless enough.

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 18:21, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 17:59, Paolo Bonzini wrote:
>>> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
>>>>> You're saying we will reserve a free BAR to address those
>>>> information to
>>>>> expose to guest, but which device does this free BAR belong to? The
>>>> video
>>>>> device? Or PCH/MCH?
>>>>
>>>> If you just want to pass a couple of IDs, then don't, it's a waste.
>>>> But I still don't know what problem you are trying to solve,
>>>> looking at guest driver did not help.
>>>
>>> It's not just a couple of IDs, it's also random fields of the MCH
>>> configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
>>>
>>
>> Paolo,
>>
>> No, we're not pointing the bridge_dev here, which is a host bridge at
>> 00:00.0.
>>
>> Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() to
>> know why we need this.
>>
>> Thanks
>> Tiejun
>>
>
> So what if you dont?
>
>          if (!pch)
>                  DRM_DEBUG_KMS("No PCH found.\n");
>
> Is that all? Seems harmless enough.
>

I don't read the whole driver completely so I don't know now. I guess 
the driver may go other live path even without this setting in a live, 
or this is a real bug to this driver on Intel platform.

But anyway, I think we should guarantee the driver work under the same 
configuration as the native in the passthrough case.

Thanks
Tiejun

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 18:21, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 17:59, Paolo Bonzini wrote:
>>> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
>>>>> You're saying we will reserve a free BAR to address those
>>>> information to
>>>>> expose to guest, but which device does this free BAR belong to? The
>>>> video
>>>>> device? Or PCH/MCH?
>>>>
>>>> If you just want to pass a couple of IDs, then don't, it's a waste.
>>>> But I still don't know what problem you are trying to solve,
>>>> looking at guest driver did not help.
>>>
>>> It's not just a couple of IDs, it's also random fields of the MCH
>>> configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
>>>
>>
>> Paolo,
>>
>> No, we're not pointing the bridge_dev here, which is a host bridge at
>> 00:00.0.
>>
>> Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() to
>> know why we need this.
>>
>> Thanks
>> Tiejun
>>
>
> So what if you dont?
>
>          if (!pch)
>                  DRM_DEBUG_KMS("No PCH found.\n");
>
> Is that all? Seems harmless enough.
>

I don't read the whole driver completely so I don't know now. I guess 
the driver may go other live path even without this setting in a live, 
or this is a real bug to this driver on Intel platform.

But anyway, I think we should guarantee the driver work under the same 
configuration as the native in the passthrough case.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 06:28:34PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 18:21, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 17:59, Paolo Bonzini wrote:
> >>>Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >>>>>You're saying we will reserve a free BAR to address those
> >>>>information to
> >>>>>expose to guest, but which device does this free BAR belong to? The
> >>>>video
> >>>>>device? Or PCH/MCH?
> >>>>
> >>>>If you just want to pass a couple of IDs, then don't, it's a waste.
> >>>>But I still don't know what problem you are trying to solve,
> >>>>looking at guest driver did not help.
> >>>
> >>>It's not just a couple of IDs, it's also random fields of the MCH
> >>>configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
> >>>
> >>
> >>Paolo,
> >>
> >>No, we're not pointing the bridge_dev here, which is a host bridge at
> >>00:00.0.
> >>
> >>Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() to
> >>know why we need this.
> >>
> >>Thanks
> >>Tiejun
> >>
> >
> >So what if you dont?
> >
> >         if (!pch)
> >                 DRM_DEBUG_KMS("No PCH found.\n");
> >
> >Is that all? Seems harmless enough.
> >
> 
> I don't read the whole driver completely so I don't know now. I guess the
> driver may go other live path even without this setting in a live, or this
> is a real bug to this driver on Intel platform.
> 
> But anyway, I think we should guarantee the driver work under the same
> configuration as the native in the passthrough case.
> 
> Thanks
> Tiejun

Just get it working as a first step. Then address theoretical
issues in follow-up patches.

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 06:28:34PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 18:21, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 17:59, Paolo Bonzini wrote:
> >>>Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >>>>>You're saying we will reserve a free BAR to address those
> >>>>information to
> >>>>>expose to guest, but which device does this free BAR belong to? The
> >>>>video
> >>>>>device? Or PCH/MCH?
> >>>>
> >>>>If you just want to pass a couple of IDs, then don't, it's a waste.
> >>>>But I still don't know what problem you are trying to solve,
> >>>>looking at guest driver did not help.
> >>>
> >>>It's not just a couple of IDs, it's also random fields of the MCH
> >>>configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
> >>>
> >>
> >>Paolo,
> >>
> >>No, we're not pointing the bridge_dev here, which is a host bridge at
> >>00:00.0.
> >>
> >>Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() to
> >>know why we need this.
> >>
> >>Thanks
> >>Tiejun
> >>
> >
> >So what if you dont?
> >
> >         if (!pch)
> >                 DRM_DEBUG_KMS("No PCH found.\n");
> >
> >Is that all? Seems harmless enough.
> >
> 
> I don't read the whole driver completely so I don't know now. I guess the
> driver may go other live path even without this setting in a live, or this
> is a real bug to this driver on Intel platform.
> 
> But anyway, I think we should guarantee the driver work under the same
> configuration as the native in the passthrough case.
> 
> Thanks
> Tiejun

Just get it working as a first step. Then address theoretical
issues in follow-up patches.

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 18:32, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 06:28:34PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 18:21, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/25 17:59, Paolo Bonzini wrote:
>>>>> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
>>>>>>> You're saying we will reserve a free BAR to address those
>>>>>> information to
>>>>>>> expose to guest, but which device does this free BAR belong to? The
>>>>>> video
>>>>>>> device? Or PCH/MCH?
>>>>>>
>>>>>> If you just want to pass a couple of IDs, then don't, it's a waste.
>>>>>> But I still don't know what problem you are trying to solve,
>>>>>> looking at guest driver did not help.
>>>>>
>>>>> It's not just a couple of IDs, it's also random fields of the MCH
>>>>> configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
>>>>>
>>>>
>>>> Paolo,
>>>>
>>>> No, we're not pointing the bridge_dev here, which is a host bridge at
>>>> 00:00.0.
>>>>
>>>> Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() to
>>>> know why we need this.
>>>>
>>>> Thanks
>>>> Tiejun
>>>>
>>>
>>> So what if you dont?
>>>
>>>          if (!pch)
>>>                  DRM_DEBUG_KMS("No PCH found.\n");
>>>
>>> Is that all? Seems harmless enough.
>>>
>>
>> I don't read the whole driver completely so I don't know now. I guess the
>> driver may go other live path even without this setting in a live, or this
>> is a real bug to this driver on Intel platform.
>>
>> But anyway, I think we should guarantee the driver work under the same
>> configuration as the native in the passthrough case.
>>
>> Thanks
>> Tiejun
>
> Just get it working as a first step. Then address theoretical
> issues in follow-up patches.
>

I'm not sure if we can simply. So I will post this to the driver 
developer to ask more.

Thanks
Tiejun

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 18:32, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 06:28:34PM +0800, Chen, Tiejun wrote:
>> On 2014/6/25 18:21, Michael S. Tsirkin wrote:
>>> On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/25 17:59, Paolo Bonzini wrote:
>>>>> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
>>>>>>> You're saying we will reserve a free BAR to address those
>>>>>> information to
>>>>>>> expose to guest, but which device does this free BAR belong to? The
>>>>>> video
>>>>>>> device? Or PCH/MCH?
>>>>>>
>>>>>> If you just want to pass a couple of IDs, then don't, it's a waste.
>>>>>> But I still don't know what problem you are trying to solve,
>>>>>> looking at guest driver did not help.
>>>>>
>>>>> It's not just a couple of IDs, it's also random fields of the MCH
>>>>> configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
>>>>>
>>>>
>>>> Paolo,
>>>>
>>>> No, we're not pointing the bridge_dev here, which is a host bridge at
>>>> 00:00.0.
>>>>
>>>> Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() to
>>>> know why we need this.
>>>>
>>>> Thanks
>>>> Tiejun
>>>>
>>>
>>> So what if you dont?
>>>
>>>          if (!pch)
>>>                  DRM_DEBUG_KMS("No PCH found.\n");
>>>
>>> Is that all? Seems harmless enough.
>>>
>>
>> I don't read the whole driver completely so I don't know now. I guess the
>> driver may go other live path even without this setting in a live, or this
>> is a real bug to this driver on Intel platform.
>>
>> But anyway, I think we should guarantee the driver work under the same
>> configuration as the native in the passthrough case.
>>
>> Thanks
>> Tiejun
>
> Just get it working as a first step. Then address theoretical
> issues in follow-up patches.
>

I'm not sure if we can simply. So I will post this to the driver 
developer to ask more.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 06:37:31PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 18:32, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 06:28:34PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 18:21, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/25 17:59, Paolo Bonzini wrote:
> >>>>>Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >>>>>>>You're saying we will reserve a free BAR to address those
> >>>>>>information to
> >>>>>>>expose to guest, but which device does this free BAR belong to? The
> >>>>>>video
> >>>>>>>device? Or PCH/MCH?
> >>>>>>
> >>>>>>If you just want to pass a couple of IDs, then don't, it's a waste.
> >>>>>>But I still don't know what problem you are trying to solve,
> >>>>>>looking at guest driver did not help.
> >>>>>
> >>>>>It's not just a couple of IDs, it's also random fields of the MCH
> >>>>>configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
> >>>>>
> >>>>
> >>>>Paolo,
> >>>>
> >>>>No, we're not pointing the bridge_dev here, which is a host bridge at
> >>>>00:00.0.
> >>>>
> >>>>Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() to
> >>>>know why we need this.
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>>
> >>>
> >>>So what if you dont?
> >>>
> >>>         if (!pch)
> >>>                 DRM_DEBUG_KMS("No PCH found.\n");
> >>>
> >>>Is that all? Seems harmless enough.
> >>>
> >>
> >>I don't read the whole driver completely so I don't know now. I guess the
> >>driver may go other live path even without this setting in a live, or this
> >>is a real bug to this driver on Intel platform.
> >>
> >>But anyway, I think we should guarantee the driver work under the same
> >>configuration as the native in the passthrough case.
> >>
> >>Thanks
> >>Tiejun
> >
> >Just get it working as a first step. Then address theoretical
> >issues in follow-up patches.
> >
> 
> I'm not sure if we can simply. So I will post this to the driver developer
> to ask more.
> 
> Thanks
> Tiejun


Please do.
The main issue in my mind is that you are implementing a non working
ISA bridge.
If guest uses it for anything - boom.


-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 06:37:31PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 18:32, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 06:28:34PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 18:21, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
> >>>>On 2014/6/25 17:59, Paolo Bonzini wrote:
> >>>>>Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >>>>>>>You're saying we will reserve a free BAR to address those
> >>>>>>information to
> >>>>>>>expose to guest, but which device does this free BAR belong to? The
> >>>>>>video
> >>>>>>>device? Or PCH/MCH?
> >>>>>>
> >>>>>>If you just want to pass a couple of IDs, then don't, it's a waste.
> >>>>>>But I still don't know what problem you are trying to solve,
> >>>>>>looking at guest driver did not help.
> >>>>>
> >>>>>It's not just a couple of IDs, it's also random fields of the MCH
> >>>>>configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
> >>>>>
> >>>>
> >>>>Paolo,
> >>>>
> >>>>No, we're not pointing the bridge_dev here, which is a host bridge at
> >>>>00:00.0.
> >>>>
> >>>>Here it should be a ISA bridge at 00:1f.0. Please see intel_detect_pch() to
> >>>>know why we need this.
> >>>>
> >>>>Thanks
> >>>>Tiejun
> >>>>
> >>>
> >>>So what if you dont?
> >>>
> >>>         if (!pch)
> >>>                 DRM_DEBUG_KMS("No PCH found.\n");
> >>>
> >>>Is that all? Seems harmless enough.
> >>>
> >>
> >>I don't read the whole driver completely so I don't know now. I guess the
> >>driver may go other live path even without this setting in a live, or this
> >>is a real bug to this driver on Intel platform.
> >>
> >>But anyway, I think we should guarantee the driver work under the same
> >>configuration as the native in the passthrough case.
> >>
> >>Thanks
> >>Tiejun
> >
> >Just get it working as a first step. Then address theoretical
> >issues in follow-up patches.
> >
> 
> I'm not sure if we can simply. So I will post this to the driver developer
> to ask more.
> 
> Thanks
> Tiejun


Please do.
The main issue in my mind is that you are implementing a non working
ISA bridge.
If guest uses it for anything - boom.


-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 12:21, Michael S. Tsirkin ha scritto:
> So what if you dont?
>
>         if (!pch)
>                 DRM_DEBUG_KMS("No PCH found.\n");
>
> Is that all? Seems harmless enough.
>

The switch statement above sets dev_priv->pch_type.  If it is set wrong, 
everything goes wrong.  grep for HAS_PCH_.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 12:21, Michael S. Tsirkin ha scritto:
> So what if you dont?
>
>         if (!pch)
>                 DRM_DEBUG_KMS("No PCH found.\n");
>
> Is that all? Seems harmless enough.
>

The switch statement above sets dev_priv->pch_type.  If it is set wrong, 
everything goes wrong.  grep for HAS_PCH_.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 02:11:45PM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 12:21, Michael S. Tsirkin ha scritto:
> >So what if you dont?
> >
> >        if (!pch)
> >                DRM_DEBUG_KMS("No PCH found.\n");
> >
> >Is that all? Seems harmless enough.
> >
> 
> The switch statement above sets dev_priv->pch_type.  If it is set wrong,
> everything goes wrong.  grep for HAS_PCH_.
> 
> Paolo

OK, so how about doing this: either for the ISA
bridge, or for the VGA card itself:

    set subsystem vendor id to PCI_VENDOR_ID_XEN,
    set subsystem device id to PCH device id

Your patch seems to emulate revision as well
but I don't see driver using that anywhere.
I would then just update driver with that info.

If you feel the need to support old guests without such a patch, we
could add some generic hook where users supply
device vendor revision id and class, and we create a dummy
device. Let xen management worry about making that match
PCH ISA bridge, or whatever, but let's also create a
clean path going forward.


-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 02:11:45PM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 12:21, Michael S. Tsirkin ha scritto:
> >So what if you dont?
> >
> >        if (!pch)
> >                DRM_DEBUG_KMS("No PCH found.\n");
> >
> >Is that all? Seems harmless enough.
> >
> 
> The switch statement above sets dev_priv->pch_type.  If it is set wrong,
> everything goes wrong.  grep for HAS_PCH_.
> 
> Paolo

OK, so how about doing this: either for the ISA
bridge, or for the VGA card itself:

    set subsystem vendor id to PCI_VENDOR_ID_XEN,
    set subsystem device id to PCH device id

Your patch seems to emulate revision as well
but I don't see driver using that anywhere.
I would then just update driver with that info.

If you feel the need to support old guests without such a patch, we
could add some generic hook where users supply
device vendor revision id and class, and we create a dummy
device. Let xen management worry about making that match
PCH ISA bridge, or whatever, but let's also create a
clean path going forward.


-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
> OK, so how about doing this: either for the ISA
> bridge, or for the VGA card itself:
>
>     set subsystem vendor id to PCI_VENDOR_ID_XEN,
>     set subsystem device id to PCH device id

That would work, but the same problem would then arise for the MCH.  The 
driver there is banging at random places in the configuration space.

This is why I asked for a solution that is future-proof, and since you 
can make one that works for both MCH and PCH it is nice to do the work 
just once.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
> OK, so how about doing this: either for the ISA
> bridge, or for the VGA card itself:
>
>     set subsystem vendor id to PCI_VENDOR_ID_XEN,
>     set subsystem device id to PCH device id

That would work, but the same problem would then arise for the MCH.  The 
driver there is banging at random places in the configuration space.

This is why I asked for a solution that is future-proof, and since you 
can make one that works for both MCH and PCH it is nice to do the work 
just once.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
> >OK, so how about doing this: either for the ISA
> >bridge, or for the VGA card itself:
> >
> >    set subsystem vendor id to PCI_VENDOR_ID_XEN,
> >    set subsystem device id to PCH device id
> 
> That would work, but the same problem would then arise for the MCH.  The
> driver there is banging at random places in the configuration space.
> 
> This is why I asked for a solution that is future-proof, and since you can
> make one that works for both MCH and PCH it is nice to do the work just
> once.
> 
> Paolo

Q35 has MCH, so I don't see why we can't make that work,
extending it as appropriate.
Doing that for PIIX is iffy.
Should we really do that? Q35 is there.

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
> >OK, so how about doing this: either for the ISA
> >bridge, or for the VGA card itself:
> >
> >    set subsystem vendor id to PCI_VENDOR_ID_XEN,
> >    set subsystem device id to PCH device id
> 
> That would work, but the same problem would then arise for the MCH.  The
> driver there is banging at random places in the configuration space.
> 
> This is why I asked for a solution that is future-proof, and since you can
> make one that works for both MCH and PCH it is nice to do the work just
> once.
> 
> Paolo

Q35 has MCH, so I don't see why we can't make that work,
extending it as appropriate.
Doing that for PIIX is iffy.
Should we really do that? Q35 is there.

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 16:10, Michael S. Tsirkin ha scritto:
> On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote:
>> Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
>>> OK, so how about doing this: either for the ISA
>>> bridge, or for the VGA card itself:
>>>
>>>    set subsystem vendor id to PCI_VENDOR_ID_XEN,
>>>    set subsystem device id to PCH device id
>>
>> That would work, but the same problem would then arise for the MCH.  The
>> driver there is banging at random places in the configuration space.
>>
>> This is why I asked for a solution that is future-proof, and since you can
>> make one that works for both MCH and PCH it is nice to do the work just
>> once.
>
> Q35 has MCH, so I don't see why we can't make that work,
> extending it as appropriate.

Is Q35's MCH configuration space entirely compatible with newer chipsets 
that are in the host and that the IGD driver expects?  I dont think it's 
safe to assume that.

> Doing that for PIIX is iffy.
> Should we really do that? Q35 is there.

Xen doesn't support Q35, and Q35 is still lacking migration.  So it's 
really a chicken-and-egg problem.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 16:10, Michael S. Tsirkin ha scritto:
> On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote:
>> Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
>>> OK, so how about doing this: either for the ISA
>>> bridge, or for the VGA card itself:
>>>
>>>    set subsystem vendor id to PCI_VENDOR_ID_XEN,
>>>    set subsystem device id to PCH device id
>>
>> That would work, but the same problem would then arise for the MCH.  The
>> driver there is banging at random places in the configuration space.
>>
>> This is why I asked for a solution that is future-proof, and since you can
>> make one that works for both MCH and PCH it is nice to do the work just
>> once.
>
> Q35 has MCH, so I don't see why we can't make that work,
> extending it as appropriate.

Is Q35's MCH configuration space entirely compatible with newer chipsets 
that are in the host and that the IGD driver expects?  I dont think it's 
safe to assume that.

> Doing that for PIIX is iffy.
> Should we really do that? Q35 is there.

Xen doesn't support Q35, and Q35 is still lacking migration.  So it's 
really a chicken-and-egg problem.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 04:16:12PM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 16:10, Michael S. Tsirkin ha scritto:
> >On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote:
> >>Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
> >>>OK, so how about doing this: either for the ISA
> >>>bridge, or for the VGA card itself:
> >>>
> >>>   set subsystem vendor id to PCI_VENDOR_ID_XEN,
> >>>   set subsystem device id to PCH device id
> >>
> >>That would work, but the same problem would then arise for the MCH.  The
> >>driver there is banging at random places in the configuration space.
> >>
> >>This is why I asked for a solution that is future-proof, and since you can
> >>make one that works for both MCH and PCH it is nice to do the work just
> >>once.
> >
> >Q35 has MCH, so I don't see why we can't make that work,
> >extending it as appropriate.
> 
> Is Q35's MCH configuration space entirely compatible with newer chipsets
> that are in the host and that the IGD driver expects?  I dont think it's
> safe to assume that.

So far only a couple of registers were emulated.
I don't see any conflicts there.

Implementing a newer MCH would also be useful, outside xen.


> >Doing that for PIIX is iffy.
> >Should we really do that? Q35 is there.
> 
> Xen doesn't support Q35,

You have to start somewhere :)

> and Q35 is still lacking migration.

It isn't, just disable ahci.

> So it's really a chicken-and-egg problem.
> 
> Paolo

Well I don't see how is this PV thing any better.

Again, experience shows if we don't push hard enough for people to fix
their stuff, and just merge crappy work-arounds "as a 1st step",
motivation for people to fix their stuff disappears, and the second step
is never taken.

Let's see the clean if incomplete solution as the first step.
We can add work-arounds for legacy configs as the second step.

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 04:16:12PM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 16:10, Michael S. Tsirkin ha scritto:
> >On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote:
> >>Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
> >>>OK, so how about doing this: either for the ISA
> >>>bridge, or for the VGA card itself:
> >>>
> >>>   set subsystem vendor id to PCI_VENDOR_ID_XEN,
> >>>   set subsystem device id to PCH device id
> >>
> >>That would work, but the same problem would then arise for the MCH.  The
> >>driver there is banging at random places in the configuration space.
> >>
> >>This is why I asked for a solution that is future-proof, and since you can
> >>make one that works for both MCH and PCH it is nice to do the work just
> >>once.
> >
> >Q35 has MCH, so I don't see why we can't make that work,
> >extending it as appropriate.
> 
> Is Q35's MCH configuration space entirely compatible with newer chipsets
> that are in the host and that the IGD driver expects?  I dont think it's
> safe to assume that.

So far only a couple of registers were emulated.
I don't see any conflicts there.

Implementing a newer MCH would also be useful, outside xen.


> >Doing that for PIIX is iffy.
> >Should we really do that? Q35 is there.
> 
> Xen doesn't support Q35,

You have to start somewhere :)

> and Q35 is still lacking migration.

It isn't, just disable ahci.

> So it's really a chicken-and-egg problem.
> 
> Paolo

Well I don't see how is this PV thing any better.

Again, experience shows if we don't push hard enough for people to fix
their stuff, and just merge crappy work-arounds "as a 1st step",
motivation for people to fix their stuff disappears, and the second step
is never taken.

Let's see the clean if incomplete solution as the first step.
We can add work-arounds for legacy configs as the second step.

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 11:59:21AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >> You're saying we will reserve a free BAR to address those information to
> >> expose to guest, but which device does this free BAR belong to? The video
> >> device? Or PCH/MCH?
> >
> >If you just want to pass a couple of IDs, then don't, it's a waste.
> >But I still don't know what problem you are trying to solve,
> >looking at guest driver did not help.
> 
> It's not just a couple of IDs, it's also random fields of the MCH
> configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
> 
> Paolo

I did, it seems to look for device at 0,0:

	static int i915_get_bridge_dev(struct drm_device *dev)
	{
		struct drm_i915_private *dev_priv = dev->dev_private;

		dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
		if (!dev_priv->bridge_dev) {
			DRM_ERROR("bridge device not found\n");
			return -1;
		}
		return 0;
	}

are you sure this is the ISA bridge device? these patches put it at 1f.

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 11:59:21AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >> You're saying we will reserve a free BAR to address those information to
> >> expose to guest, but which device does this free BAR belong to? The video
> >> device? Or PCH/MCH?
> >
> >If you just want to pass a couple of IDs, then don't, it's a waste.
> >But I still don't know what problem you are trying to solve,
> >looking at guest driver did not help.
> 
> It's not just a couple of IDs, it's also random fields of the MCH
> configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
> 
> Paolo

I did, it seems to look for device at 0,0:

	static int i915_get_bridge_dev(struct drm_device *dev)
	{
		struct drm_i915_private *dev_priv = dev->dev_private;

		dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
		if (!dev_priv->bridge_dev) {
			DRM_ERROR("bridge device not found\n");
			return -1;
		}
		return 0;
	}

are you sure this is the ISA bridge device? these patches put it at 1f.

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 12:09, Michael S. Tsirkin ha scritto:
>> > It's not just a couple of IDs, it's also random fields of the MCH
>> > configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
>> >
>> > Paolo
> I did, it seems to look for device at 0,0:
>
> 	static int i915_get_bridge_dev(struct drm_device *dev)
> 	{
> 		struct drm_i915_private *dev_priv = dev->dev_private;
>
> 		dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> 		if (!dev_priv->bridge_dev) {
> 			DRM_ERROR("bridge device not found\n");
> 			return -1;
> 		}
> 		return 0;
> 	}
>
> are you sure this is the ISA bridge device? these patches put it at 1f.
>

For the PCH it's just the ids, but there are also accesses to the MCH 
config space.

Paolo

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Paolo Bonzini]

Il 25/06/2014 12:09, Michael S. Tsirkin ha scritto:
>> > It's not just a couple of IDs, it's also random fields of the MCH
>> > configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
>> >
>> > Paolo
> I did, it seems to look for device at 0,0:
>
> 	static int i915_get_bridge_dev(struct drm_device *dev)
> 	{
> 		struct drm_i915_private *dev_priv = dev->dev_private;
>
> 		dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> 		if (!dev_priv->bridge_dev) {
> 			DRM_ERROR("bridge device not found\n");
> 			return -1;
> 		}
> 		return 0;
> 	}
>
> are you sure this is the ISA bridge device? these patches put it at 1f.
>

For the PCH it's just the ids, but there are also accesses to the MCH 
config space.

Paolo

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 18:09, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 11:59:21AM +0200, Paolo Bonzini wrote:
>> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
>>>> You're saying we will reserve a free BAR to address those information to
>>>> expose to guest, but which device does this free BAR belong to? The video
>>>> device? Or PCH/MCH?
>>>
>>> If you just want to pass a couple of IDs, then don't, it's a waste.
>>> But I still don't know what problem you are trying to solve,
>>> looking at guest driver did not help.
>>
>> It's not just a couple of IDs, it's also random fields of the MCH
>> configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
>>
>> Paolo
>
> I did, it seems to look for device at 0,0:
>
> 	static int i915_get_bridge_dev(struct drm_device *dev)
> 	{
> 		struct drm_i915_private *dev_priv = dev->dev_private;
>
> 		dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> 		if (!dev_priv->bridge_dev) {
> 			DRM_ERROR("bridge device not found\n");
> 			return -1;
> 		}
> 		return 0;
> 	}
>
> are you sure this is the ISA bridge device? these patches put it at 1f.
>

:) The IGD is too complex to understand.

The i915 driver needs to access that host bridge at 00:00.0, and this is 
addressed in patch #3.

Also the i915 needs that ISA bridge at 00:1f.0, this is just what we're 
discussing now.

Thanks
Tiejun

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Chen, Tiejun]

On 2014/6/25 18:09, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2014 at 11:59:21AM +0200, Paolo Bonzini wrote:
>> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
>>>> You're saying we will reserve a free BAR to address those information to
>>>> expose to guest, but which device does this free BAR belong to? The video
>>>> device? Or PCH/MCH?
>>>
>>> If you just want to pass a couple of IDs, then don't, it's a waste.
>>> But I still don't know what problem you are trying to solve,
>>> looking at guest driver did not help.
>>
>> It's not just a couple of IDs, it's also random fields of the MCH
>> configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
>>
>> Paolo
>
> I did, it seems to look for device at 0,0:
>
> 	static int i915_get_bridge_dev(struct drm_device *dev)
> 	{
> 		struct drm_i915_private *dev_priv = dev->dev_private;
>
> 		dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> 		if (!dev_priv->bridge_dev) {
> 			DRM_ERROR("bridge device not found\n");
> 			return -1;
> 		}
> 		return 0;
> 	}
>
> are you sure this is the ISA bridge device? these patches put it at 1f.
>

:) The IGD is too complex to understand.

The i915 driver needs to access that host bridge at 00:00.0, and this is 
addressed in patch #3.

Also the i915 needs that ISA bridge at 00:1f.0, this is just what we're 
discussing now.

Thanks
Tiejun

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 06:15:29PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 18:09, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 11:59:21AM +0200, Paolo Bonzini wrote:
> >>Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >>>>You're saying we will reserve a free BAR to address those information to
> >>>>expose to guest, but which device does this free BAR belong to? The video
> >>>>device? Or PCH/MCH?
> >>>
> >>>If you just want to pass a couple of IDs, then don't, it's a waste.
> >>>But I still don't know what problem you are trying to solve,
> >>>looking at guest driver did not help.
> >>
> >>It's not just a couple of IDs, it's also random fields of the MCH
> >>configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
> >>
> >>Paolo
> >
> >I did, it seems to look for device at 0,0:
> >
> >	static int i915_get_bridge_dev(struct drm_device *dev)
> >	{
> >		struct drm_i915_private *dev_priv = dev->dev_private;
> >
> >		dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> >		if (!dev_priv->bridge_dev) {
> >			DRM_ERROR("bridge device not found\n");
> >			return -1;
> >		}
> >		return 0;
> >	}
> >
> >are you sure this is the ISA bridge device? these patches put it at 1f.
> >
> 
> :) The IGD is too complex to understand.
> 
> The i915 driver needs to access that host bridge at 00:00.0, and this is
> addressed in patch #3.

You mean patch #4.

> Also the i915 needs that ISA bridge at 00:1f.0, this is just what we're
> discussing now.
> 
> Thanks
> Tiejun

Yea. That vile thing seems to mostly be safe to ignore.

-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 06:15:29PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 18:09, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 11:59:21AM +0200, Paolo Bonzini wrote:
> >>Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >>>>You're saying we will reserve a free BAR to address those information to
> >>>>expose to guest, but which device does this free BAR belong to? The video
> >>>>device? Or PCH/MCH?
> >>>
> >>>If you just want to pass a couple of IDs, then don't, it's a waste.
> >>>But I still don't know what problem you are trying to solve,
> >>>looking at guest driver did not help.
> >>
> >>It's not just a couple of IDs, it's also random fields of the MCH
> >>configuration space.  Grep drivers/gpu/drm/i915 for bridge_dev.
> >>
> >>Paolo
> >
> >I did, it seems to look for device at 0,0:
> >
> >	static int i915_get_bridge_dev(struct drm_device *dev)
> >	{
> >		struct drm_i915_private *dev_priv = dev->dev_private;
> >
> >		dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> >		if (!dev_priv->bridge_dev) {
> >			DRM_ERROR("bridge device not found\n");
> >			return -1;
> >		}
> >		return 0;
> >	}
> >
> >are you sure this is the ISA bridge device? these patches put it at 1f.
> >
> 
> :) The IGD is too complex to understand.
> 
> The i915 driver needs to access that host bridge at 00:00.0, and this is
> addressed in patch #3.

You mean patch #4.

> Also the i915 needs that ISA bridge at 00:1f.0, this is just what we're
> discussing now.
> 
> Thanks
> Tiejun

Yea. That vile thing seems to mostly be safe to ignore.

-- 
MST

Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 05:21:04PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:09, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 16:48, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
> >>>>Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
> >>>>>It might be possible to move the Q35 bridge elsewhere.
> >>>>>seabios doesn't care where the host bridge is.
> >>>>>ACPI tables in QEMU can be adjusted.
> >>>>
> >>>>But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver wants
> >>>>to run under virtual machines, it should stop acting as if it knows what the
> >>>>whole machine looks like.
> >>>>
> >>>>Paolo
> >>>
> >>>If guest driver can be fixed that seems ideal.
> >>>I don't know how it works but presumably you guys do?
> >>
> >>Paolo prefer we need to fix this in the driver like:
> >>
> >>"
> >>>>>The right way could be to make QEMU add a vendor-specific capability to
> >>>>>the video device. The driver can probe for that capability before
> >>>>
> >>>>Do you mean we can pick two unused offsets in the configuration space of
> >>>>the video device as a vendor-specific capability to hold the
> >>>>vendor/device ids of the PCH?
> >>>
> >>>Yes, either that or add a new capability (which lets you choose the
> >>>offsets more freely).
> >>>
> >>>If the IGD driver needs config space fields of the MCH, those fields
> >>>could also be mirrored in the new capability.  QEMU would forward them
> >>>automatically.
> >>>
> >>>It could even be a new BAR, which gives even more freedom to allocate
> >>>the fields.
> >>"
> >>
> >>Thanks
> >>Tiejun
> >
> >Adding a vendor-specific capability or BAR
> >in an existing device is painful - hard to find
> >free space for it.
> 
> Yes, this is a potential risk as well since we can't guarantee current free
> space is always valid for ever.
> 
> >We could add a dummy device in PCI or ACPI, but
> >driver should really look for it using device/vendor id,
> >not at a specific address.
> >What exactly is it that the driver wants to know?
> >
> 
> The i915 driver need to use the vendor/device ids to get what pch type is
> running, then go different paths.
> 
> Thanks
> Tiejun

That's all? Just the IDs? You seem to emulate a bunch of other registers, why?
If that's all, a clean way would be to set subsystem vendor ID to be one
specific to Xen, set subsystem device id to whatever you want.  Get an extra
virtual vendor ID for intel from pci sig, or ask citrix to get one.


However, looking at drivers/gpu/drm/i915/i915_drv.c,
I don't see it poking at a specific address:


         * The reason to probe ISA bridge instead of Dev31:Fun0 is to
         * make graphics device passthrough work easy for VMM, that only
         * need to expose ISA bridge to let driver know the real hardware
         * underneath. This is a requirement from virtualization team.
         *
         * In some virtualized environments (e.g. XEN), there is irrelevant
         * ISA bridge in the system. To work reliably, we should scan trhough
         * all the ISA bridge devices and check for the first match, instead
         * of only checking the first one.
         */
        while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {


while this is quite ugly as an extra bridge might
confuse non linux guests, as a shortcut I don't see
why you can't simply stick your fake bridge at
a random address.


-- 
MST

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Michael S. Tsirkin]

On Wed, Jun 25, 2014 at 05:21:04PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:09, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 16:48, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
> >>>>Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
> >>>>>It might be possible to move the Q35 bridge elsewhere.
> >>>>>seabios doesn't care where the host bridge is.
> >>>>>ACPI tables in QEMU can be adjusted.
> >>>>
> >>>>But why?  It's always in 00:1f.0 on real hardware.  If the i915 driver wants
> >>>>to run under virtual machines, it should stop acting as if it knows what the
> >>>>whole machine looks like.
> >>>>
> >>>>Paolo
> >>>
> >>>If guest driver can be fixed that seems ideal.
> >>>I don't know how it works but presumably you guys do?
> >>
> >>Paolo prefer we need to fix this in the driver like:
> >>
> >>"
> >>>>>The right way could be to make QEMU add a vendor-specific capability to
> >>>>>the video device. The driver can probe for that capability before
> >>>>
> >>>>Do you mean we can pick two unused offsets in the configuration space of
> >>>>the video device as a vendor-specific capability to hold the
> >>>>vendor/device ids of the PCH?
> >>>
> >>>Yes, either that or add a new capability (which lets you choose the
> >>>offsets more freely).
> >>>
> >>>If the IGD driver needs config space fields of the MCH, those fields
> >>>could also be mirrored in the new capability.  QEMU would forward them
> >>>automatically.
> >>>
> >>>It could even be a new BAR, which gives even more freedom to allocate
> >>>the fields.
> >>"
> >>
> >>Thanks
> >>Tiejun
> >
> >Adding a vendor-specific capability or BAR
> >in an existing device is painful - hard to find
> >free space for it.
> 
> Yes, this is a potential risk as well since we can't guarantee current free
> space is always valid for ever.
> 
> >We could add a dummy device in PCI or ACPI, but
> >driver should really look for it using device/vendor id,
> >not at a specific address.
> >What exactly is it that the driver wants to know?
> >
> 
> The i915 driver need to use the vendor/device ids to get what pch type is
> running, then go different paths.
> 
> Thanks
> Tiejun

That's all? Just the IDs? You seem to emulate a bunch of other registers, why?
If that's all, a clean way would be to set subsystem vendor ID to be one
specific to Xen, set subsystem device id to whatever you want.  Get an extra
virtual vendor ID for intel from pci sig, or ask citrix to get one.


However, looking at drivers/gpu/drm/i915/i915_drv.c,
I don't see it poking at a specific address:


         * The reason to probe ISA bridge instead of Dev31:Fun0 is to
         * make graphics device passthrough work easy for VMM, that only
         * need to expose ISA bridge to let driver know the real hardware
         * underneath. This is a requirement from virtualization team.
         *
         * In some virtualized environments (e.g. XEN), there is irrelevant
         * ISA bridge in the system. To work reliably, we should scan trhough
         * all the ISA bridge devices and check for the first match, instead
         * of only checking the first one.
         */
        while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {


while this is quite ugly as an extra bridge might
confuse non linux guests, as a shortcut I don't see
why you can't simply stick your fake bridge at
a random address.


-- 
MST

Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Andrew Barnes]

[-- Attachment #1: Type: text/plain, Size: 5076 bytes --]

Hi, I've been working on IGD passthrough using native qemu and VFIO,
(without any XEN components).

This work hasn't progressed in recent, but I am able to continue it again.
Late last year I was in discussions with Allen Kay, Vikas Shivappa from
Intel and Alex Williamson from Redhat, which resulted in successfully
loading the i915 driver with opregion support which provided Intel frame
buffer, but I did not get 2D or 3D acceleration working.

I did this using Q35.

The code is not without similar hacks that have been scrutinised here, and
most intellectual parts of the code come from XEN (like the opregion
location and size) - the code in parts should look similar. but Alex helped
me convert it from XEN to QEMU.

with the disclaimer that this is code is immature, has been written to
prove out the concept (not to be suggested as appropriate for upstream) and
may not even patch correctly. but as some indication of the direction I was
taking. please look here: https://github.com/UmbraMalison/qemu-igdvfio

I realise that this takes this conversation on yet another tangent, however
my justification for doing is that many of the root discussions and
potential flaws of cross xen implementation and use of piix are at least
addressed.

Also, if there is potential for further help in completing this task that
would be well received. I am still keen to complete this implementation and
hope to find some missing pieces in Tiejun's work, currently I am re-basing
on v2.0.0.

Best,

Andy


On 25 June 2014 03:17, Tiejun Chen <tiejun.chen@intel.com> wrote:

> V5 is generated just based on Paolo's some comments.
>
> v5:
>
> * Don't set that ISA class property, instead, just fake this ISA bridge
>   with 00:1f.0.
> * Don't pass vendor/device ids in igd_pci_read().
> * Add to support offset 0x44/0x48.
> * Just rebase.
>
> v4:
>
> * Fix some typos in the patch head description.
> * Improve some comments.
> * Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
>   are called unconditionally, so we just return 0 there.
> * Remove one spurious change.
> * Remove some unnecessary "return" in void foo().
> * Given that pci_create_pch() is called unconditionally, so we just return
> 0
>   even if its failed to check xen_has_gfx_passthru.
> * Use (xen_enabled() && xen_has_gfx_passthru) to make sure we only work
>   in this scenario.
>
> v3:
>
> * In this case, as we discussed we will give priority to devices to
>   reserve a specific devfn by passing
>   "device_model_args_hvm = ['-device', 'xen-platform,addr=0x3']" and
>   "vga=none", so withdraw patch #1, #2 and #4.
> * Fix some typos.
> * Add more comments to make that readable.
> * To unmap igd_opregion when call xen_pt_unregister_vga_regions().
> * Improve some return paths.
> * Force to convert igd_guest/host_opoegion as an unsigned long type
>   while calling xc_domain_memory_mapping().
> * We need to map 3 pages for opregion as hvmloader set.
>
> v2:
>
> * rebase on current qemu tree.
> * retrieve VGA bios from sysfs properly.
> * redefine some function name.
> * introduce bitmap to manage registe/runregister pci dev, and provide
>   a common way to reserve some specific devfn.
> * introduce is_igd_passthrough() to make sure we touch physical host
>   bridge only in IGD case.
> * We should return zero as an invalid address value while calling
>   igd_read_opregion().
>
> Additionally, now its also not necessary to recompile seabios with some
> extra steps like v1.
>
>
> The following patches are ported partially from Xen Qemu-traditional
> branch which are adding Intel IGD passthrough supporting to Qemu upstream.
>
> To pass through IGD to guest, user need to add following lines in Xen
> config file:
> gfx_passthru=1
> pci=['00:02.0@2']
>
> Now successfully boot Ubuntu 14.04/Windows 7 guests with IGD assigned in
> Haswell desktop with Latest Xen + Qemu upstream.
>
> ----------------------------------------------------------------
> Tiejun Chen (5):
>       xen, gfx passthrough: basic graphics passthrough support
>       xen, gfx passthrough: create pseudo intel isa bridge
>       xen, gfx passthrough: support Intel IGD passthrough with VT-D
>       xen, gfx passthrough: create host bridge to passthrough
>       xen, gfx passthrough: add opregion mapping
>
>  hw/pci-host/piix.c           |  56 +++++++++++++++-
>  hw/xen/Makefile.objs         |   2 +-
>  hw/xen/xen-host-pci-device.c |   5 ++
>  hw/xen/xen-host-pci-device.h |   1 +
>  hw/xen/xen_pt.c              |  10 +++
>  hw/xen/xen_pt.h              |  12 +++-
>  hw/xen/xen_pt_config_init.c  |  50 +++++++++++++-
>  hw/xen/xen_pt_graphics.c     | 513
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  qemu-options.hx              |   9 +++
>  vl.c                         |  10 +++
>  10 files changed, 663 insertions(+), 5 deletion
>
> Thanks
> Tiejun
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

[-- Attachment #2: Type: text/html, Size: 6210 bytes --]

Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support

[Andrew Barnes]

[-- Attachment #1.1: Type: text/plain, Size: 5076 bytes --]

Hi, I've been working on IGD passthrough using native qemu and VFIO,
(without any XEN components).

This work hasn't progressed in recent, but I am able to continue it again.
Late last year I was in discussions with Allen Kay, Vikas Shivappa from
Intel and Alex Williamson from Redhat, which resulted in successfully
loading the i915 driver with opregion support which provided Intel frame
buffer, but I did not get 2D or 3D acceleration working.

I did this using Q35.

The code is not without similar hacks that have been scrutinised here, and
most intellectual parts of the code come from XEN (like the opregion
location and size) - the code in parts should look similar. but Alex helped
me convert it from XEN to QEMU.

with the disclaimer that this is code is immature, has been written to
prove out the concept (not to be suggested as appropriate for upstream) and
may not even patch correctly. but as some indication of the direction I was
taking. please look here: https://github.com/UmbraMalison/qemu-igdvfio

I realise that this takes this conversation on yet another tangent, however
my justification for doing is that many of the root discussions and
potential flaws of cross xen implementation and use of piix are at least
addressed.

Also, if there is potential for further help in completing this task that
would be well received. I am still keen to complete this implementation and
hope to find some missing pieces in Tiejun's work, currently I am re-basing
on v2.0.0.

Best,

Andy


On 25 June 2014 03:17, Tiejun Chen <tiejun.chen@intel.com> wrote:

> V5 is generated just based on Paolo's some comments.
>
> v5:
>
> * Don't set that ISA class property, instead, just fake this ISA bridge
>   with 00:1f.0.
> * Don't pass vendor/device ids in igd_pci_read().
> * Add to support offset 0x44/0x48.
> * Just rebase.
>
> v4:
>
> * Fix some typos in the patch head description.
> * Improve some comments.
> * Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions()
>   are called unconditionally, so we just return 0 there.
> * Remove one spurious change.
> * Remove some unnecessary "return" in void foo().
> * Given that pci_create_pch() is called unconditionally, so we just return
> 0
>   even if its failed to check xen_has_gfx_passthru.
> * Use (xen_enabled() && xen_has_gfx_passthru) to make sure we only work
>   in this scenario.
>
> v3:
>
> * In this case, as we discussed we will give priority to devices to
>   reserve a specific devfn by passing
>   "device_model_args_hvm = ['-device', 'xen-platform,addr=0x3']" and
>   "vga=none", so withdraw patch #1, #2 and #4.
> * Fix some typos.
> * Add more comments to make that readable.
> * To unmap igd_opregion when call xen_pt_unregister_vga_regions().
> * Improve some return paths.
> * Force to convert igd_guest/host_opoegion as an unsigned long type
>   while calling xc_domain_memory_mapping().
> * We need to map 3 pages for opregion as hvmloader set.
>
> v2:
>
> * rebase on current qemu tree.
> * retrieve VGA bios from sysfs properly.
> * redefine some function name.
> * introduce bitmap to manage registe/runregister pci dev, and provide
>   a common way to reserve some specific devfn.
> * introduce is_igd_passthrough() to make sure we touch physical host
>   bridge only in IGD case.
> * We should return zero as an invalid address value while calling
>   igd_read_opregion().
>
> Additionally, now its also not necessary to recompile seabios with some
> extra steps like v1.
>
>
> The following patches are ported partially from Xen Qemu-traditional
> branch which are adding Intel IGD passthrough supporting to Qemu upstream.
>
> To pass through IGD to guest, user need to add following lines in Xen
> config file:
> gfx_passthru=1
> pci=['00:02.0@2']
>
> Now successfully boot Ubuntu 14.04/Windows 7 guests with IGD assigned in
> Haswell desktop with Latest Xen + Qemu upstream.
>
> ----------------------------------------------------------------
> Tiejun Chen (5):
>       xen, gfx passthrough: basic graphics passthrough support
>       xen, gfx passthrough: create pseudo intel isa bridge
>       xen, gfx passthrough: support Intel IGD passthrough with VT-D
>       xen, gfx passthrough: create host bridge to passthrough
>       xen, gfx passthrough: add opregion mapping
>
>  hw/pci-host/piix.c           |  56 +++++++++++++++-
>  hw/xen/Makefile.objs         |   2 +-
>  hw/xen/xen-host-pci-device.c |   5 ++
>  hw/xen/xen-host-pci-device.h |   1 +
>  hw/xen/xen_pt.c              |  10 +++
>  hw/xen/xen_pt.h              |  12 +++-
>  hw/xen/xen_pt_config_init.c  |  50 +++++++++++++-
>  hw/xen/xen_pt_graphics.c     | 513
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  qemu-options.hx              |   9 +++
>  vl.c                         |  10 +++
>  10 files changed, 663 insertions(+), 5 deletion
>
> Thanks
> Tiejun
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 6210 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel