From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 522841A1E76 for ; Thu, 1 Sep 2016 13:23:28 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e124so1591747ith.0 for ; Thu, 01 Sep 2016 13:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0pHZHHtbMhuYFezDfTZLZ2ngY9B13PIZ2LsUK/9xuas=; b=aEoq4EoUBvvXBtCX31YEP4ZidUeElcFDFmuPE/GNp45bQJtwm4Blep0Pmu9HWsUeR/ L9qD97vWuXz9ZdhvAt7FW15juXwNTgYPFMyXvmp15U1LQ7324IFlzIxi5VMa4Jb4NKo+ 8kmVMT9lXpEzfcexkLhTVRdIaytSDmfv1VhZ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0pHZHHtbMhuYFezDfTZLZ2ngY9B13PIZ2LsUK/9xuas=; b=MVcL19kkpUO3dfnIlXMeOqJ0P3NhFtCwlngBMBgqRJOOtEAQDGoRva7MSqqXiOYuJp vHxUoKp0XeoD5VTOw2klx/wrzMmHzZRyDIdrU841wg2lJij8W69O5+v1iQitjSQU/CyF llWBe/hCuqUR1bb1aahm9BZxjN4YsJEbBKASwzAR0iVA8xpKS8r6KzUuMwJLLABhvps2 ReSxLprNWsqM95gv1KMbVfWfd03uhmgCE3dbJK4xKlZer+cvKwZFUfX1udS+vsLeDDQD w+Tj/q8k04XN3mxm/vPlGDztC1eJ5S6VNjM037ivT3lx9QtRJzo6clyaXJlgt8f8Pb0B Bq3A== X-Gm-Message-State: AE9vXwOm2zzxi2dLnwQ09B0u9YYveBES6M0rHOCvIfIJ1eZgwjBCzinHxRHJbS9n3OvznUicB/9X6sSiYnVCse8I X-Received: by 10.36.137.193 with SMTP id s184mr39573870itd.51.1472761407647; Thu, 01 Sep 2016 13:23:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Thu, 1 Sep 2016 13:23:27 -0700 (PDT) In-Reply-To: <147275957055.21562.7750188759462698423@jljusten-ivb> References: <20160819124932.29711-1-lersek@redhat.com> <147267618723.12178.11385591212119668150@jljusten-ivb> <2c5b6038-a51a-9206-392b-d391c0aabf51@redhat.com> <147275300806.20661.4606850370467291385@jljusten-ivb> <0500cc50-86f9-ab97-f22d-012ac1857ad0@redhat.com> <147275957055.21562.7750188759462698423@jljusten-ivb> From: Ard Biesheuvel Date: Thu, 1 Sep 2016 21:23:27 +0100 Message-ID: To: Jordan Justen Cc: Laszlo Ersek , edk2-devel-01 Subject: Re: [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci) 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: , X-List-Received-Date: Thu, 01 Sep 2016 20:23:28 -0000 Content-Type: text/plain; charset=UTF-8 On 1 September 2016 at 20:52, Jordan Justen wrote: > On 2016-09-01 11:46:04, Laszlo Ersek wrote: >> On 09/01/16 20:03, Jordan Justen wrote: >> >> > I think there would be value to have a non-VGA device that could still >> > configure a simple framebuffer. VGA does bring a fair amount of other >> > baggage. >> >> Ah, I see your point. You distinguish "VGA" from "non-VGA device with >> framebuffer". >> >> For this discussion however, this distinction makes no difference. The >> suggested "non-VGA device with framebuffer" would be broken exactly the >> same way. In other words, it's not the "other baggage" that is broken, >> it is the framebuffer. >> > > This is only focusing on the current ARM issue. I'm just pointing out > that I think virtio gpu without VGA, but with a framebuffer could be > useful on IA32/X64 as well. > > 1. You don't have to deal with the PCI bus > > 2. The OS re-enumerating the PCI bus would not break the framebuffer > How does adding a framebuffer to virtio-gpu solve any of that? virtio-gpu is a PCI device as well > Is there no chance that ARM KVM might someday also be able to support > a framebuffer? > There are workarounds imaginable, but none of them are feasible in terms. A new revision of the architecture may address this, but that will take years to turn up in real hardware. > Obviously this is not too important for IA32/X64 OVMF, because we have > reasonable alternatives. But, it seems like virtio gpu could be a > significantly better option for IA32/X64 OVMF if an optional > framebuffer was possible. > IIUC, not having a linear framebuffer was one of the design goals, since it is essentially a layering violation in the virtio stack. virtio-gpu is strictly ring based, like other virtio devices. If you want a framebuffer, you should use virtio-vga. Adding a framebuffer to virtio-gpu is a step back rather than a step forward. Also, the loader->OS handover already suffers from the issues you mention, since the PCI reconfiguration breaks GOP on almost every platform. The reason that it is less of a concern on ARM is that most systems use UART as the primary console.