qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chen, Tiejun
Subject: Re: [Qemu-devel] [v5][PATCH 3/5] xen, gfx passthrough: support Intel IGD passthrough with VT-D
Date: Thu, 26 Jun 2014 13:34:14 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

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 <address@hidden>

Signed-off-by: Yang Zhang <address@hidden>
Signed-off-by: Tiejun Chen <address@hidden>
Cc: Weidong Han <address@hidden>
---

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]