From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>, intel-gfx@lists.freedesktop.org
Subject: Re: VGA arbiter support for Intel HD?
Date: Wed, 14 Aug 2013 23:01:52 +0300 [thread overview]
Message-ID: <20130814200152.GB7159@intel.com> (raw)
In-Reply-To: <1376509195.13642.14.camel@ul30vt.home>
On Wed, Aug 14, 2013 at 01:39:55PM -0600, Alex Williamson wrote:
> On Wed, 2013-08-14 at 21:30 +0300, Ville Syrjälä wrote:
> > On Wed, Aug 14, 2013 at 11:14:48AM -0600, Alex Williamson wrote:
> > > On Wed, 2013-08-14 at 17:47 +0300, Ville Syrjälä wrote:
> > > > On Wed, Aug 14, 2013 at 07:23:57AM -0600, Alex Williamson wrote:
> > > > > Hi,
> > > > >
> > > > > I'm trying to add support for device assignment of PCI VGA devices with
> > > > > VFIO and QEMU. For normal, discrete discrete graphics the Linux VGA
> > > > > arbiter works fairly well, disabling VGA on one bridge and adding it to
> > > > > another (though I wish all the kernel VGA drivers made use of it). The
> > > > > i915 driver only seems to support disabling VGA on really old GMCH
> > > > > devices (see intel_modeset_vga_set_state). This means that if I boot
> > > > > with IGD as the primary graphics and attempt to assign a discrete
> > > > > graphics device, all the VGA range accesses are still routed to IGD, I
> > > > > end up getting some error messages from the IGD interrupt handler, and
> > > > > the discrete card never initializes.
> > > > >
> > > > > I spent some time looking through the Sand Bridge, Ivy Bridge, and
> > > > > Haswell datasheets, and I'm a bit concerned whether the hardware even
> > > > > provides a reasonable way to disable VGA anymore. Quoting 2.17 from the
> > > > > Haswell docs:
> > > > >
> > > > > Accesses to the VGA memory range are directed to IGD depend on
> > > > > the configuration. The configuration is specified by:
> > > > > * Internal graphics controller in Device 2 is enabled
> > > > > (DEVEN.D2EN bit 4)
> > > > > * Internal graphics VGA in Device 0 Function 0 is enabled
> > > > > through register GGC bit 1.
> > > > > * IGD's memory accesses (PCICMD2 04 – 05h, MAE bit 1) in
> > > > > Device 2 configuration space are enabled.
> > > > > * VGA compatibility memory accesses (VGA Miscellaneous
> > > > > Output register – MSR Register, bit 1) are enabled.
> > > > > * Software sets the proper value for VGA Memory Map Mode
> > > > > register (VGA GR06 Register, bits 3-2). See the
> > > > > following table for translations.
> > > > >
> > > > > (There's a similar list for VGA I/O range) I've found that if I disable
> > > > > memory and I/O in the PCI command register for IGD then I do get VGA
> > > > > routing to the PEG device and the discrete VBIOS works. This obviously
> > > > > isn't a good option for the VGA arbiter since it entirely disables IGD.
> > > > >
> > > > > The GGC registers aren't meant for runtime switching and are actually
> > > > > locked. Disabling IGD via the device 2 enable bit doesn't seem like and
> > > > > option. I don't quite understand the VGA miscellaneous output register
> > > > > and VGA memory map mode, but the table provided for the latter makes me
> > > > > think they just augment the VGA ranges and don't disable them.
> > > >
> > > > Bit 1 of MSR (0x3c2/0x3cc) should allow you to turn off VGA mem
> > > > access while leaving other memory space access working.
> > > >
> > > > As for VGA I/O decode, IIRC there's no standard bit for that in VGA
> > > > or PCI config registers, and I can't see any other bit for it in the
> > > > docs. But I guess you could just turn off I/O space completely
> > > > via the PCI_COMMAND register. We shouldn't need it for anything beyond
> > > > i915_disable_vga() and that has the necessary vgaarb calls already.
> > >
> > > Thanks Ville. The MSR seems to work for VGA memory. Disabling I/O via
> > > PCI_COMMAND does works, but something is re-enabling it after
> > > intel_modeset_vga_set_state(). If I manually disable I/O with setpci
> > > then I do have VGA routing to PEG and can still interact with the KMS
> > > console on IGD. It's unfortunate that the MSR bit for I/O only disables
> > > pieces of the range. If we have no other options, I'll try to hunt down
> > > where I/O is being re-enabled and see how feasible it is to avoid.
> > > Thanks,
> >
> > Hmm. Now that I look at vgaarb more it seems I misunderstood the way it
> > works. Based on the code it looks like it will permanently remove the
> > device from the arbiration if set_vga_decode indicates that it doesn't
> > decode legacy resources. And it calls set_vga_decode w/ decode=false
> > if there are more than two VGA cards in the system. That means
>
> s/more than two/two or more/
>
> > i915_disable_vga() is actually broken whenever there is another
> > VGA card in the system.
>
> I didn't follow why i915_disable_vga is broken. It seems like the
> intention is to disable VGA regardless of how many VGA devices are
> present.
I suppose that's the original intention, but i915_disable_vga() needs
VGA I/O access, so it is currently broken if VGA I/O is disabled.
Originally i915_disable_vga() used MMIO access, but there's a hardware
workaround (since ILK IIRC) stating that VGA registers must be
accessed w/ port I/O. That's progress for you :(
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2013-08-14 20:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-14 13:23 VGA arbiter support for Intel HD? Alex Williamson
2013-08-14 14:47 ` Ville Syrjälä
2013-08-14 17:14 ` Alex Williamson
2013-08-14 18:30 ` Ville Syrjälä
2013-08-14 19:39 ` Alex Williamson
2013-08-14 20:01 ` Ville Syrjälä [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-04-03 17:47 Friedrich Oslage
2014-04-03 18:28 ` Alex Williamson
2014-04-05 9:42 ` Friedrich Oslage
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130814200152.GB7159@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=airlied@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.