qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [v6][PATCH 08/10] xen, gfx passthrough: support Intel I


From: Kay, Allen M
Subject: Re: [Qemu-devel] [v6][PATCH 08/10] xen, gfx passthrough: support Intel IGD passthrough with VT-D
Date: Thu, 22 Jan 2015 02:21:23 +0000


> -----Original Message-----
> From: Chen, Tiejun
> Sent: Tuesday, January 20, 2015 7:17 PM
> To: Michael S. Tsirkin; Kay, Allen M
> Cc: address@hidden; address@hidden; address@hidden; Zhang,
> Yang Z; address@hidden
> Subject: Re: [v6][PATCH 08/10] xen, gfx passthrough: support Intel IGD
> passthrough with VT-D
> 
> >> +uint32_t xen_igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr,
> >> +int len) {
> >> +    XenHostPCIDevice dev;
> >> +    uint32_t val;
> >> +    int r;
> >> +
> >> +    /* IGD read/write is through the host bridge.
> >> +     */
> >> +    assert(pci_dev->devfn == 0x00);
> >> +
> >> +    if (!is_igd_passthrough(pci_dev)) {
> >> +        goto read_default;
> >> +    }
> >> +
> >> +    /* Just work for the i915 driver. */
> >> +    switch (config_addr) {
> >> +    case 0x08:        /* revision id */
> >> +    case 0x2c:        /* sybsystem vendor id */
> >> +    case 0x2e:        /* sybsystem id */
> >> +    case 0x50:        /* SNB: processor graphics control register */
> >> +    case 0x52:        /* processor graphics control register */
> >> +    case 0xa0:        /* top of memory */
> >
> > Is this host physical memory? If yes how can using it in guest work?
> 
> This is just a threshold value, not a start or end address :)
> 

"top of memory" is no longer used in new versions of Windows drivers.  Tiejun 
and I have tried BDW/HSW drivers and found they work without the need to 
passthrough 0xa0 register in the host bridge.  It can be removed.

> >
> >> +    case 0xa4:        /* SNB: graphics base of stolen memory */
> >> +    case 0xa8:        /* SNB: base of GTT stolen memory */
> >
> > Same question for above two.
> 
> I shouldn't matter since I remember we already discussed this previously but
> I can't sort out this from those emails now.
> 
> Allen,
> 
> Could you reexplain this?
> 

These two "stolen memory" regions are part of the VT-d RMRR region.  They are 
1:1 mapped in the guest (GPA == HPA).  Tiejun found they are needed by vBIOS 
during boot.  Modern Windows driver no longer need to access these two 
registers in MCH.

> >
> >> +        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;
> >> +}
> >
> > Do any of the above registers change with time?
> 
> Think about we just provide read ops, so they're not changed based on my
> experiential.
> 
> > Does it work if we just read them when device is created and put in
> > dev->config?
> 
> I think this is a good idea so I will go there and thank you.
> 
> Tiejun
> 

Allen



reply via email to

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