[Intel-gfx] How to create PCH to support those existing driver

[Kay, Allen M]

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst at redhat.com]
> Sent: Tuesday, August 19, 2014 2:51 PM
> To: Kay, Allen M
> Cc: Chen, Tiejun; Paolo Bonzini; Wang, Yong Y; Don Dutile; Jesse Barnes;
> Konrad Rzeszutek Wilk; qemu-devel at nongnu.org; xen-
> devel at lists.xensource.com; intel-gfx; Stefano Stabellini
> (Stefano.Stabellini at citrix.com)
> Subject: Re: How to create PCH to support those existing driver
> 
> On Tue, Aug 19, 2014 at 09:24:03PM +0000, Kay, Allen M wrote:
> > > Allen,
> > >
> > > Could you reply this?
> >
> > Let me summarized what we have discussed and learned so far:
> >
> > 1) Future Windows/Linux IGD drivers will be modified to restrain from
> accessing MCH/PCH devices.  We are prototyping this in Windows driver right
> now and will pass the same methodology to Linux driver once we have a
> workable solution.  The goal is removing all MCH/PCH accesses in the IGD
> driver.
> >
> > 2) We want the same solution to work in both native and virtualization
> environments.  Given most driver developers test their changes only in
> native environment, doing anything specific for virtualization in the driver will
> cause frequent breakage for virtualization use cases.
> >
> > 3) Back porting this new code to support previous generations of HW will
> be problematic if not impossible.  Each Windows IGD driver release binary
> supports two generations of HW.  For example, 15.36 driver supports
> Broadwell/Haswell, 15.33 driver supports Haswell/IvyBridge, 15.31 driver
> supports Ivybridge/Sandybridge, etc.   Once the driver is product validated,
> there is little opportunity to  go back and make high impact changes that
> might affect stability in native environment.
> >
> > 4) I agree there is little reason to do anything that requires driver changes
> at this point,  unless it is the final desired solution.
> >
> > The question is whether/how to support IGD passthrough for previous
> generations of HW?
> >
> > 1) If we want to support SandyBridge/IvyBridge/Haswell/Broadwell, we will
> need most of the original QEMU patches.  We might be able to do without
> igd_pci_write().  I have tested QEMU changes without igd_pci_write() on
> both Haswell/Broadwell and Windows booted without any problems.  This
> will limit only read operations which should reduce a quite a bit of risk to the
> host platform.
> 
> Excellent. I was thinking about changing host's driver to do the writes in a
> safe manner, but if don't need that, all the better.
> As a next step, we need to limit read operations to specific set of registers
> that we can validate.
> We can't just pass through reads blindly to host, pci reads have side-effects
> and host chipset isn't protected by the iommu.
> Since these are legacy devices and drivers, it should be possible to
> enumerate all registers that they need.
> 

If we limit platform support to HSW/BDW the number of register reads is quite small.  I believe some of the register reads are for the old Ironlake platforms.  I will work with Tiejun to get the smaller set for HSW/BDW systems.

> 
> > 2) If we want the upstream QEMU only work with future driver version,
> then most of the IGD passthrough patch is probably not needed - with
> exception of opregion mapping handlers.  The downside is products that
> depend on this feature will need to apply private patches separately to re-
> enable IGD passthrough capability.
> >
> > Any advice on how should Tiejun proceed from here?
> >
> > Allen
> 
> I'm fine with either trying to make existing windows and linux drivers work,
> or waiting for future drivers.
> 
> To me, quick hacks that need minor changes in driver but don't avoid poking
> at MCH/PCH don't seem to have value, I know I proposed some of these
> myself but this was before I realised a cleaner solution is possible.
> 
> 
> --
> MST

Allen