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 <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