Re: [PATCH] i915: Add module option to support VGA arbiter on HD devices

[Alex Williamson]

On Mon, 2014-05-12 at 21:08 +0200, Daniel Vetter wrote:
> On Fri, May 09, 2014 at 02:20:41PM -0600, Alex Williamson wrote:
> > Commit 81b5c7bc found that the current VGA arbiter support in i915
> > only works for ancient GMCH-based IGD devices and attempted to update
> > support for newer HD devices.  Unfortunately newer devices cannot
> > completely opt-out of VGA arbitration like the old devices could.
> > The VGA I/O space cannot be disabled internally.  The only way to
> > route VGA I/O elsewhere is by disabling I/O at the device PCI command
> > register.  This means that with commit 81b5c7bc and multiple VGA
> > adapters, the VGA arbiter will report that multiple VGA devices are
> > participating in arbitration, Xorg will notice this and disable DRI.
> > Therefore, 81b5c7bc was reverted because DRI is more important than
> > being correct.
> > 
> > There is however an actual need for i915 to correctly participate in
> > VGA arbitration; VGA device assignment.  If we want to use VFIO to
> > assign a VGA device to a virtual machine, we need to be able to
> > access the VGA resources of that device.  By adding an i915 module
> > option we can allow i915 to continue with its charade by default, but
> > also allow an easy path for users who require working VGA arbitration.
> > Hopefully Xorg can someday be taught to behave better with multiple
> > VGA devices.
> > 
> > This also rolls in reverted commit 6e1b4fda, which corrected an
> > ordering issue with 81b5c7bc by delaying the disabling of VGA memory
> > until after vgacon->fbcon handoff.
> > 
> > Signed-off-by: Alex Williamson <alex.williamson@xxxxxxxxxx>
> > Cc: Ville SyrjÃlà <ville.syrjala@xxxxxxxxxxxxxxx>
> > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
> > Cc: Dave Airlie <airlied@xxxxxxxxxx>
> > ---
> > 
> > This should be a nop with the default module setting, so if there's
> > any opportunity to get this into v3.15, it would be appreciated.
> 
> I really don't like module options to work around bugs elsewhere. It means
> the 5 users who know about a given bug are now happen, and the 3
> bazillion without enough clue/savy/time still suffer from problems.
> 
> My goal is to actually add a bit of support to the core kernel's module
> option parsing code so that most of the options we have can spit warnings
> into dmesg and taint the kernel.
> 
> Can't we fix this in any other way?

Do you have any suggestions?  I proposed creating a new VGA arbiter
interface that would allow Xorg to mmap the legacy VGA MMIO space
regardless of the number of VGA arbitration participants, but didn't get
any nibbles on supporting that through the rest of the stack.  Dave
suggested maybe he could rip out the VGA arbiter support from Xorg and
nobody would notice.  In either case, at what point do we get to flip
i915 to behave correctly with arbitration?  It seems like anything we do
has a compatibility period where we must leave i915 in it's current
broken state, which means that anyone wanting VGA arbitration needs to
patch their kernel.  In the best case, that compatibility window could
extend for years.  Since we don't seem to be making progress on any of
the other fronts, it seemed time to propose a module switch.  It's not a
good solution, but it's better than leaving it broken.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/