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

[Chen, Tiejun]

On 2014/8/20 5:51, Michael S. Tsirkin wrote:
> 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.
>
>
>> 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.

Michael and Allen,

As I concern, now we may not take a consideration of supporting those 
existing drivers, just leave to qemu-traditional in Xen code repertory.

I think what we should do here just focus on supporting all platforms 
including those legacy platforms.

>
> To me, quick hacks that need minor changes
> in driver but don't avoid poking at MCH/PCH don't seem to have value,

So to me, that subsystem id way is more clear rather than others because 
I'm not sure its really possible not to poke MCH/PCH theoretically both 
Windows and Linux driver.

Allen,

I think Michael is saying this,

http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258

What about your opinion?

> I know I proposed some of these myself but this was before I
> realised a cleaner solution is possible.
>

I think all we are fine if this really come true :)

Tiejun