From: Alex Williamson <alex.williamson@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>,
Kevin Locke <kevin@kevinlocke.name>,
qemu-devel@nongnu.org, Marcel Apfelbaum <marcel@redhat.com>,
Laine Stump <laine@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v2] docs: add PCIe root bus for VGA compat guideline
Date: Wed, 15 Jun 2022 14:05:50 -0600 [thread overview]
Message-ID: <20220615140550.25f94242.alex.williamson@redhat.com> (raw)
In-Reply-To: <20220614085252.fyogpqyf7cfcty4x@sirius.home.kraxel.org>
On Tue, 14 Jun 2022 10:52:52 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Mon, Jun 13, 2022 at 03:47:04PM +0200, Laszlo Ersek wrote:
> > On 06/12/22 19:32, Kevin Locke wrote:
> > > PCI Express devices which use legacy VGA compatibility should be placed
> > > on the Root Complex. This simplifies ioport access to VGA registers,
> > > which requires use of a special exception bit to work across PCI(e)
> > > bridges. It is also necessary for ioport access to VESA BIOS Extension
> > > (VBE) registers, which is not forwarded over PCI(e) bridges, even with
> > > the special exception bit for VGA register access.[1]
> > >
> > > Update the PCI Express Guidelines to add these to the list of devices
> > > which can be placed directly on the Root Complex.
> > >
> > > Note that the only PCI Express display devices currently supported
> > > (bochs-display and virtio-gpu-pci) do not offer VGA compatibility.
> > > Legacy PCI devices (e.g. vga, qxl-vga, virtio-vga) are already
> > > documented as allowed on the Root Complex by the first item in the list.
> > > However, this item documents an additional consideration for placing
> > > devices which was not previously mentioned, and may be relevant for PCIe
> > > devices offering VGA compatibility in the future.
>
> Well, the *key* problem is emulated VGA devices with VBE registers in
> io address space, because those are not forwarded over bridges.
>
> For normal VGA registers this isn't much of a problem (in theory, not
> fully sure whenever that holds in practice, Alex?). The linux kernel
> knows how to use the bridge control register to manage access to VGA
> registers.
Yes, AUIU the issue is entirely with the extended VBE requirements, the
VGA ranges are fully routable through the VGA control registers on the
bridge. The only bare metal issue I'm aware of with VGA routing is
that we cannot route around Intel IGD. IIRC, this latter quirk is the
only reason that enabling VGA routing for a vfio-pci device is
considered experimental, but it very much does work when there's no
host device silently consuming those ranges.
We've also historically had issues with AMD graphics drivers assuming
an express link which can lead to driver segfaults if those devices are
placed on the root complex. OTOH, I'm not aware of any specific issues
with placing assigned VGA class GPUs in configurations with a root port.
I'd therefore expect any configuration guidelines we're proposing to be
very specific to devices that make use of VBE, not just VGA devices in
general. Thanks,
Alex
next prev parent reply other threads:[~2022-06-15 20:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-09 2:00 [RFC][PATCH] docs: note exception for PCIe IO port access Kevin Locke
2022-06-09 7:45 ` Laszlo Ersek
2022-06-09 7:50 ` Laszlo Ersek
2022-06-09 8:41 ` Gerd Hoffmann
2022-06-09 14:03 ` Kevin Locke
2022-06-10 7:00 ` Laszlo Ersek
2022-06-12 17:32 ` [PATCH v2] docs: add PCIe root bus for VGA compat guideline Kevin Locke
2022-06-13 13:47 ` Laszlo Ersek
2022-06-14 8:52 ` Gerd Hoffmann
2022-06-14 18:14 ` Kevin Locke
2022-06-15 6:42 ` Gerd Hoffmann
2022-06-15 20:05 ` Alex Williamson [this message]
2022-06-13 13:55 ` [PATCH v3] " Kevin Locke
2022-06-22 0:56 ` [PATCH v4] docs: mention devices with VBE on Root Complex Kevin Locke
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=20220615140550.25f94242.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=kevin@kevinlocke.name \
--cc=kraxel@redhat.com \
--cc=laine@redhat.com \
--cc=lersek@redhat.com \
--cc=marcel@redhat.com \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).