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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx