qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: airlied@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/4] vga: new display devices
Date: Wed, 12 Mar 2014 19:14:36 +0100	[thread overview]
Message-ID: <5320A40C.4060908@redhat.com> (raw)
In-Reply-To: <1394639220.17393.44.camel@nilsson.home.kraxel.org>

On 03/12/14 16:47, Gerd Hoffmann wrote:
>
> On Mi, 2014-03-12 at 14:55 +0100, Laszlo Ersek wrote:
>> On 03/12/14 13:55, Gerd Hoffmann wrote:
>>>   Hi,
>>>
>>> This patch series adds new display devices.
>>>
>>> Number one is secondary-vga.  That is identical to VGA (aka -vga
>>> std), except that it doesn't occupy all the legacy vga stuff
>>> (ioports, memory window @ 0xa0000), so you can have more than one of
>>> these in the system. It has one pci memory bar for the framebuffer
>>> and one mmio bar for registers.  OVMF can drive it.  Doesn't use it
>>> as console for some reason, but initializes it and the linux kernel
>>> will see it as efifb.
>>
>> My take is, due to the UEFI driver model, QemuVideoDxe is connected
>> to this secondary VGA (and so another GOP instance is created). It's
>> then probably up to GraphicsConsoleDxe to provide a SimpleTextOutput
>> on top. My guess (without looking) is that this too happens, again
>> thanks to the UEFI driver model.
>>
>> What could be amiss is likely something in ConSplitterDxe, which
>> accepts input from all consoles, and mirrors output to all of them as
>> well. Perhaps it doesn't expect multiple GOPs.
>
> Must be something else, I see this behavior with secondary-vga being
> the only display device.  It prints a single line saying something
> along the lines "display initialized", so SimpleTextOutput seems to be
> active.

OK, maybe I got some further clues; see
"OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".

  PlatformBdsPolicyBehavior()
    PlatformBdsConnectConsole()
      DetectAndPreparePlatformPciDevicePaths()
        VisitAllPciInstances()
          VisitAllInstancesOfProtocol()
            VisitingAPciInstance()
              DetectAndPreparePlatformPciDevicePath()
    +---------->IS_PCI_VGA (Pci):
    |             "Found PCI VGA device"
    |             PreparePciVgaDevicePath()
    |               GetGopDevicePath()
    |               BdsLibUpdateConsoleVariable()
    |
The IS_PCI_VGA() macro in "MdePkg/Include/IndustryStandard/Pci22.h"
says:

> /**
>   Macro that checks whether device is a VGA-compatible controller.
>
>   @param  _p      Specified device.
>
>   @retval TRUE    Device is a VGA-compatible controller.
>   @retval FALSE   Device is not a VGA-compatible controller.
>
> **/
> #define IS_PCI_VGA(_p)                IS_CLASS3 (_p, PCI_CLASS_DISPLAY, PCI_CLASS_DISPLAY_VGA, PCI_IF_VGA_VGA)

Plus

> #define PCI_CLASS_DISPLAY             0x03
> #define   PCI_CLASS_DISPLAY_VGA         0x00
> #define     PCI_IF_VGA_VGA                0x00

In your patch 2/4 (secondary_class_init()):

> +    k->class_id = PCI_CLASS_DISPLAY_OTHER;

and from qemu's "include/hw/pci/pci_ids.h":

> #define PCI_CLASS_DISPLAY_VGA            0x0300
> #define PCI_CLASS_DISPLAY_OTHER          0x0380

I think this is the cause of the mismatch.

In vga_class_init(), PCI_CLASS_DISPLAY_VGA is used.

Note: build_pci_bus_end() [hw/i386/acpi-build.c] also seems to depend on
PCI_CLASS_DISPLAY_VGA. (Of course you could be wanting to avoid exactly
that branch, by setting the class to "other".)

In edk2, there's another relevant-looking (laxer) macro:

> /**
>   Macro that checks whether device is a display controller.
>
>   @param  _p      Specified device.
>
>   @retval TRUE    Device is a display controller.
>   @retval FALSE   Device is not a display controller.
>
> **/
> #define IS_PCI_DISPLAY(_p)            IS_CLASS1 (_p, PCI_CLASS_DISPLAY)

Does the following OVMF patch help?

> diff --git a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
> index 9f953ac..33d8c5d 100644
> --- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
> @@ -593,7 +593,7 @@ DetectAndPreparePlatformPciDevicePath (
>    //
>    // Here we decide which VGA device to enable in PCI bus
>    //
> -  if (IS_PCI_VGA (Pci)) {
> +  if (IS_PCI_DISPLAY (Pci)) {
>      //
>      // Add them to ConOut.
>      //

Thanks
Laszlo

  reply	other threads:[~2014-03-12 18:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-12 12:55 [Qemu-devel] [PATCH 0/4] vga: new display devices Gerd Hoffmann
2014-03-12 12:55 ` [Qemu-devel] [PATCH 1/4] vga: allow non-global vmstate Gerd Hoffmann
2014-03-12 12:55 ` [Qemu-devel] [PATCH 2/4] vga: add secondary stdvga variant Gerd Hoffmann
2014-03-12 13:11   ` Eric Blake
2014-03-12 12:55 ` [Qemu-devel] [PATCH 3/4] virtio-gpu: v0.3 of the virtio based GPU code Gerd Hoffmann
2014-03-12 20:26   ` Michael S. Tsirkin
2014-03-13  9:08     ` Gerd Hoffmann
2014-03-14 11:13       ` Gerd Hoffmann
2014-03-16 12:21         ` Michael S. Tsirkin
2014-03-13 10:40     ` Paolo Bonzini
2014-03-14 11:18       ` Gerd Hoffmann
2014-03-16 12:28         ` Michael S. Tsirkin
2014-03-17  4:36       ` Dave Airlie
2014-03-17  5:21         ` Dave Airlie
2014-03-17  9:50           ` Paolo Bonzini
2014-03-17  9:27         ` Paolo Bonzini
2014-03-17 11:01         ` Michael S. Tsirkin
2014-03-12 12:55 ` [Qemu-devel] [PATCH 4/4] virtio-vga: v1 Gerd Hoffmann
2014-03-12 13:55 ` [Qemu-devel] [PATCH 0/4] vga: new display devices Laszlo Ersek
2014-03-12 15:47   ` Gerd Hoffmann
2014-03-12 18:14     ` Laszlo Ersek [this message]
2014-03-13  8:22       ` Gerd Hoffmann
2014-03-13  8:41         ` Laszlo Ersek

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=5320A40C.4060908@redhat.com \
    --to=lersek@redhat.com \
    --cc=airlied@redhat.com \
    --cc=kraxel@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).