From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNnfz-0001Ue-Hc for qemu-devel@nongnu.org; Wed, 12 Mar 2014 14:14:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WNnfr-0000WS-Vr for qemu-devel@nongnu.org; Wed, 12 Mar 2014 14:14:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNnfr-0000WO-NT for qemu-devel@nongnu.org; Wed, 12 Mar 2014 14:14:39 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2CIEc0g032414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 12 Mar 2014 14:14:39 -0400 Message-ID: <5320A40C.4060908@redhat.com> Date: Wed, 12 Mar 2014 19:14:36 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1394628914-10758-1-git-send-email-kraxel@redhat.com> <53206765.708@redhat.com> <1394639220.17393.44.camel@nilsson.home.kraxel.org> In-Reply-To: <1394639220.17393.44.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] vga: new display devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: airlied@redhat.com, qemu-devel@nongnu.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