From patchwork Fri Aug 19 12:49:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laszlo Ersek X-Patchwork-Id: 74240 Delivered-To: patch@linaro.org Received: by 10.140.29.52 with SMTP id a49csp295543qga; Fri, 19 Aug 2016 05:49:45 -0700 (PDT) X-Received: by 10.66.232.37 with SMTP id tl5mr13323231pac.13.1471610985560; Fri, 19 Aug 2016 05:49:45 -0700 (PDT) Return-Path: Received: from ml01.01.org (ml01.01.org. [198.145.21.10]) by mx.google.com with ESMTPS id k70si5037999pfk.85.2016.08.19.05.49.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Aug 2016 05:49:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) client-ip=198.145.21.10; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) smtp.mailfrom=edk2-devel-bounces@lists.01.org Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 24F101A1E15; Fri, 19 Aug 2016 05:49:45 -0700 (PDT) X-Original-To: edk2-devel@ml01.01.org Delivered-To: edk2-devel@ml01.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 94C4E1A1E14 for ; Fri, 19 Aug 2016 05:49:43 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2DDE66331E; Fri, 19 Aug 2016 12:49:43 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-13.phx2.redhat.com [10.3.116.13]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7JCnaSh011583; Fri, 19 Aug 2016 08:49:42 -0400 From: Laszlo Ersek To: edk2-devel-01 Date: Fri, 19 Aug 2016 14:49:23 +0200 Message-Id: <20160819124932.29711-3-lersek@redhat.com> In-Reply-To: <20160819124932.29711-1-lersek@redhat.com> References: <20160819124932.29711-1-lersek@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 19 Aug 2016 12:49:43 +0000 (UTC) Subject: [edk2] [PATCH 02/11] OvmfPkg/Virtio10Dxe: don't bind virtio-vga X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jordan Justen , Ard Biesheuvel Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" Commit 9399f68ae359 ("OvmfPkg: Virtio10Dxe: non-transitional driver for virtio-1.0 PCI devices") created a "competition" between Virtio10Dxe and QemuVideoDxe for virtio-vga devices. The binding order between these drivers is unspecified, and the wrong order effectively breaks commit 94210dc95e9f ("OvmfPkg: QemuVideoDxe: add virtio-vga support"). Thus, never bind virtio-vga in Virtio10Dxe; QemuVideoDxe provides better compatibility for guest OSes that insist on inheriting a linear framebuffer. Users who prefer the VirtIo GPU interface at boot time should specify virtio-gpu-pci, which is exactly virtio-vga, minus the VGA compatibility (such as the framebuffer). Cc: Ard Biesheuvel Cc: Jordan Justen Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Fixes: 9399f68ae359234b142c293ad1bef75f470ced30 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- OvmfPkg/Virtio10Dxe/Virtio10.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) -- 2.9.2 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel diff --git a/OvmfPkg/Virtio10Dxe/Virtio10.c b/OvmfPkg/Virtio10Dxe/Virtio10.c index 06f069907753..a8a6a58c3f1d 100644 --- a/OvmfPkg/Virtio10Dxe/Virtio10.c +++ b/OvmfPkg/Virtio10Dxe/Virtio10.c @@ -819,25 +819,37 @@ Virtio10BindingSupported ( Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint32, 0, sizeof Pci / sizeof (UINT32), &Pci); if (EFI_ERROR (Status)) { goto CloseProtocol; } + Status = EFI_UNSUPPORTED; // // Recognize non-transitional modern devices. Also, we'll have to parse the // PCI capability list, so make sure the CapabilityPtr field will be valid. // if (Pci.Hdr.VendorId == VIRTIO_VENDOR_ID && Pci.Hdr.DeviceId >= 0x1040 && Pci.Hdr.DeviceId <= 0x107F && Pci.Hdr.RevisionID >= 0x01 && Pci.Device.SubsystemID >= 0x40 && (Pci.Hdr.Status & EFI_PCI_STATUS_CAPABILITY) != 0) { - Status = EFI_SUCCESS; - } else { - Status = EFI_UNSUPPORTED; + // + // The virtio-vga device is special. It can be driven both as a VGA device + // with a linear framebuffer, and through its underlying, modern, + // virtio-gpu-pci device, which has no linear framebuffer itself. For + // compatibility with guest OSes that insist on inheriting a linear + // framebuffer from the firmware, we should leave virtio-vga to + // QemuVideoDxe, and support only virtio-gpu-pci here. + // + // Both virtio-vga and virtio-gpu-pci have DeviceId 0x1050, but only the + // former has device class PCI_CLASS_DISPLAY_VGA. + // + if (Pci.Hdr.DeviceId != 0x1050 || !IS_PCI_VGA (&Pci)) { + Status = EFI_SUCCESS; + } } CloseProtocol: gBS->CloseProtocol (DeviceHandle, &gEfiPciIoProtocolGuid, This->DriverBindingHandle, DeviceHandle);