From: "Michael S. Tsirkin" <mst@redhat.com>
To: Tiejun Chen <tiejun.chen@intel.com>
Cc: allen.m.kay@intel.com, qemu-devel@nongnu.org,
aliguori@amazon.com, yang.z.zhang@intel.com, pbonzini@redhat.com,
rth@twiddle.net
Subject: Re: [Qemu-devel] [v6][PATCH 07/10] xen, gfx passthrough: register a isa bridge
Date: Tue, 20 Jan 2015 12:46:21 +0200 [thread overview]
Message-ID: <20150120104621.GC26442@redhat.com> (raw)
In-Reply-To: <1421659723-2496-8-git-send-email-tiejun.chen@intel.com>
On Mon, Jan 19, 2015 at 05:28:40PM +0800, Tiejun Chen wrote:
> Currently IGD drivers always need to access PCH by 1f.0. But we
> don't want to poke that directly to get ID, and although in real
> world different GPU should have different PCH. But actually the
> different PCH DIDs likely map to different PCH SKUs. We do the
> same thing for the GPU. For PCH, the different SKUs are going to
> be all the same silicon design and implementation, just different
> features turn on and off with fuses. The SW interfaces should be
> consistent across all SKUs in a given family (eg LPT). But just
> same features may not be supported.
>
> Most of these different PCH features probably don't matter to the
> Gfx driver, but obviously any difference in display port connections
> will so it should be fine with any PCH in case of passthrough.
>
> So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
> scenarios, 0x9cc3 for BDW(Broadwell).
>
> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> ---
> hw/xen/xen_pt.c | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 126 insertions(+)
>
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> index fcc9f1c..5532d6f 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -632,6 +632,129 @@ static const MemoryListener xen_pt_io_listener = {
> .priority = 10,
> };
>
> +typedef struct {
> + uint16_t gpu_device_id;
> + uint16_t pch_device_id;
> + uint8_t pch_revision_id;
> +} XenIGDDeviceIDInfo;
> +
> +/* In real world different GPU should have different PCH. But actually
> + * the different PCH DIDs likely map to different PCH SKUs. We do the
> + * same thing for the GPU. For PCH, the different SKUs are going to be
> + * all the same silicon design and implementation, just different
> + * features turn on and off with fuses. The SW interfaces should be
> + * consistent across all SKUs in a given family (eg LPT). But just same
> + * features may not be supported.
> + *
> + * Most of these different PCH features probably don't matter to the
> + * Gfx driver, but obviously any difference in display port connections
> + * will so it should be fine with any PCH in case of passthrough.
> + *
> + * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
> + * scenarios, 0x9cc3 for BDW(Broadwell).
> + */
> +static const XenIGDDeviceIDInfo xen_igd_combo_id_infos[] = {
> + /* HSW Classic */
> + {0x0402, 0x8c4e, 0x04}, /* HSWGT1D, HSWD_w7 */
> + {0x0406, 0x8c4e, 0x04}, /* HSWGT1M, HSWM_w7 */
> + {0x0412, 0x8c4e, 0x04}, /* HSWGT2D, HSWD_w7 */
> + {0x0416, 0x8c4e, 0x04}, /* HSWGT2M, HSWM_w7 */
> + {0x041E, 0x8c4e, 0x04}, /* HSWGT15D, HSWD_w7 */
> + /* HSW ULT */
> + {0x0A06, 0x8c4e, 0x04}, /* HSWGT1UT, HSWM_w7 */
> + {0x0A16, 0x8c4e, 0x04}, /* HSWGT2UT, HSWM_w7 */
> + {0x0A26, 0x8c4e, 0x06}, /* HSWGT3UT, HSWM_w7 */
> + {0x0A2E, 0x8c4e, 0x04}, /* HSWGT3UT28W, HSWM_w7 */
> + {0x0A1E, 0x8c4e, 0x04}, /* HSWGT2UX, HSWM_w7 */
> + {0x0A0E, 0x8c4e, 0x04}, /* HSWGT1ULX, HSWM_w7 */
> + /* HSW CRW */
> + {0x0D26, 0x8c4e, 0x04}, /* HSWGT3CW, HSWM_w7 */
> + {0x0D22, 0x8c4e, 0x04}, /* HSWGT3CWDT, HSWD_w7 */
> + /* HSW Server */
> + {0x041A, 0x8c4e, 0x04}, /* HSWSVGT2, HSWD_w7 */
> + /* HSW SRVR */
> + {0x040A, 0x8c4e, 0x04}, /* HSWSVGT1, HSWD_w7 */
> + /* BSW */
> + {0x1606, 0x9cc3, 0x03}, /* BDWULTGT1, BDWM_w7 */
> + {0x1616, 0x9cc3, 0x03}, /* BDWULTGT2, BDWM_w7 */
> + {0x1626, 0x9cc3, 0x03}, /* BDWULTGT3, BDWM_w7 */
> + {0x160E, 0x9cc3, 0x03}, /* BDWULXGT1, BDWM_w7 */
> + {0x161E, 0x9cc3, 0x03}, /* BDWULXGT2, BDWM_w7 */
> + {0x1602, 0x9cc3, 0x03}, /* BDWHALOGT1, BDWM_w7 */
> + {0x1612, 0x9cc3, 0x03}, /* BDWHALOGT2, BDWM_w7 */
> + {0x1622, 0x9cc3, 0x03}, /* BDWHALOGT3, BDWM_w7 */
> + {0x162B, 0x9cc3, 0x03}, /* BDWHALO28W, BDWM_w7 */
> + {0x162A, 0x9cc3, 0x03}, /* BDWGT3WRKS, BDWM_w7 */
> + {0x162D, 0x9cc3, 0x03}, /* BDWGT3SRVR, BDWM_w7 */
> +};
> +
> +static void isa_bridge_class_init(ObjectClass *klass, void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> +
> + dc->desc = "ISA bridge faked to support IGD PT";
> + k->vendor_id = PCI_VENDOR_ID_INTEL;
> + k->class_id = PCI_CLASS_BRIDGE_ISA;
> +};
> +
> +static TypeInfo isa_bridge_info = {
> + .name = "xen-igd-passthrough-isa-bridge",
> + .parent = TYPE_PCI_DEVICE,
> + .instance_size = sizeof(PCIDevice),
> + .class_init = isa_bridge_class_init,
> +};
> +
> +static void xen_pt_graphics_register_types(void)
> +{
> + type_register_static(&isa_bridge_info);
> +}
> +type_init(xen_pt_graphics_register_types)
> +
> +static void
> +xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
> + XenHostPCIDevice *dev)
> +{
> + struct PCIDevice *pci_dev;
> + int i, num;
> + uint16_t gpu_dev_id, pch_dev_id = 0xffff;
> + uint8_t pch_rev_id;
> + PCIDevice *d = &s->dev;
> +
> + if (!is_igd_vga_passthrough(dev)) {
> + return;
> + }
> +
> + gpu_dev_id = dev->device_id;
> + num = ARRAY_SIZE(xen_igd_combo_id_infos);
> + for (i = 0; i < num; i++) {
> + if (gpu_dev_id == xen_igd_combo_id_infos[i].gpu_device_id) {
> + pch_dev_id = xen_igd_combo_id_infos[i].pch_device_id;
> + pch_rev_id = xen_igd_combo_id_infos[i].pch_revision_id;
> + }
> + }
> +
> + if (pch_dev_id == 0xffff) {
> + fprintf(stderr, "unsupported PCH!\n");
I would drop this fprintf: this likely means a newer
card, so the bridge is not necessary.
> + return;
> + }
> +
> + /* Currently IGD drivers always need to access PCH by 1f.0. */
> + pci_dev = pci_create_simple(d->bus, PCI_DEVFN(0x1f, 0),
> + "xen-igd-passthrough-isa-bridge");
> +
> + /*
> + * Identify PCH card with its own real vendor/device ids.
This no longer holds I think.
> + * Note that vendor id is always PCI_VENDOR_ID_INTEL.
> + */
> + if (!pci_dev) {
> + fprintf(stderr, "xen set xen-igd-passthrough-isa-bridge failed!\n");
> + return;
> + }
> + pci_config_set_device_id(pci_dev->config, pch_dev_id);
> + pci_config_set_revision(pci_dev->config, pch_rev_id);
> +}
> +
> /* init */
>
> static int xen_pt_initfn(PCIDevice *d)
> @@ -680,6 +803,9 @@ static int xen_pt_initfn(PCIDevice *d)
> xen_host_pci_device_put(&s->real_device);
> return -1;
> }
> +
> + /* Register ISA bridge for passthrough GFX. */
> + xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
> }
>
> /* Handle real device's MMIO/PIO BARs */
> --
> 1.9.1
next prev parent reply other threads:[~2015-01-20 10:46 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-19 9:28 [Qemu-devel] [v6][PATCH 00/10] xen: add Intel IGD passthrough support Tiejun Chen
2015-01-19 9:28 ` [Qemu-devel] [v6][PATCH 01/10] i440fx: make types configurable at run-time Tiejun Chen
2015-01-19 11:36 ` Gerd Hoffmann
2015-01-20 2:48 ` Chen, Tiejun
2015-01-20 8:25 ` Gerd Hoffmann
2015-01-20 8:32 ` Jike Song
2015-01-20 5:08 ` Chen, Tiejun
2015-01-19 9:28 ` [Qemu-devel] [v6][PATCH 02/10] pc_init1: pass parameters just with types Tiejun Chen
2015-01-19 9:28 ` [Qemu-devel] [v6][PATCH 03/10] piix: create host bridge to passthrough Tiejun Chen
2015-01-19 11:40 ` Gerd Hoffmann
2015-01-20 2:52 ` Chen, Tiejun
2015-01-20 4:28 ` Jike Song
2015-01-20 4:56 ` Chen, Tiejun
2015-01-19 9:28 ` [Qemu-devel] [v6][PATCH 04/10] hw/pci-assign: split pci-assign.c Tiejun Chen
2015-01-19 9:28 ` [Qemu-devel] [v6][PATCH 05/10] xen, gfx passthrough: basic graphics passthrough support Tiejun Chen
2015-01-19 11:45 ` Gerd Hoffmann
2015-01-20 3:14 ` Chen, Tiejun
2015-01-20 8:14 ` Gerd Hoffmann
2015-01-21 7:04 ` Chen, Tiejun
2015-01-19 9:28 ` [Qemu-devel] [v6][PATCH 06/10] xen, gfx passthrough: retrieve VGA BIOS to work Tiejun Chen
2015-01-19 9:28 ` [Qemu-devel] [v6][PATCH 07/10] xen, gfx passthrough: register a isa bridge Tiejun Chen
2015-01-19 11:57 ` Gerd Hoffmann
2015-01-19 13:58 ` Michael S. Tsirkin
2015-01-20 2:46 ` Chen, Tiejun
2015-01-20 10:46 ` Michael S. Tsirkin [this message]
2015-01-21 0:41 ` Chen, Tiejun
2015-01-20 11:03 ` Michael S. Tsirkin
2015-01-21 0:46 ` Chen, Tiejun
2015-01-19 9:28 ` [Qemu-devel] [v6][PATCH 08/10] xen, gfx passthrough: support Intel IGD passthrough with VT-D Tiejun Chen
2015-01-20 10:58 ` Michael S. Tsirkin
2015-01-21 3:16 ` Chen, Tiejun
2015-01-22 2:21 ` Kay, Allen M
2015-01-19 9:28 ` [Qemu-devel] [v6][PATCH 09/10] xen, gfx passthrough: register host bridge specific to passthrough Tiejun Chen
2015-01-19 9:28 ` [Qemu-devel] [v6][PATCH 10/10] xen, gfx passthrough: add opregion mapping Tiejun Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150120104621.GC26442@redhat.com \
--to=mst@redhat.com \
--cc=aliguori@amazon.com \
--cc=allen.m.kay@intel.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=tiejun.chen@intel.com \
--cc=yang.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).