From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 3CFF51A1DFE for ; Thu, 1 Sep 2016 13:44:53 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 BA9954E4C2; Thu, 1 Sep 2016 20:44:52 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-28.phx2.redhat.com [10.3.116.28]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u81KipHP023443; Thu, 1 Sep 2016 16:44:51 -0400 To: Jordan Justen 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> Cc: Ard Biesheuvel , edk2-devel-01 From: Laszlo Ersek Message-ID: Date: Thu, 1 Sep 2016 22:44:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147275957055.21562.7750188759462698423@jljusten-ivb> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 01 Sep 2016 20:44:52 +0000 (UTC) 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:44:53 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 09/01/16 21: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. I believe your suggestion concerns the spec itself (that is, what it should specify, and how the QEMU-side VirtIo GPU Device should be designed). I didn't partake in the design of, nor QEMU's implementation of, the VirtIo GPU Device, so I can't comment (Gerd Hoffmann and David Airlie could, I assume). The current design is certainly sufficient for the ARM issue. > 1. You don't have to deal with the PCI bus > > 2. The OS re-enumerating the PCI bus would not break the framebuffer > > Is there no chance that ARM KVM might someday also be able to support > a framebuffer? > > 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. Well, I can't (and shouldn't) comment, due to the above, but I might try speculating. If I understand correctly, you are proposing a device that is somewhere "between" virtio-gpu-pci and virtio-vga, in the sense that it'd have a framebuffer, but (a) the framebuffer wouldn't live in a PCI MMIO BAR, and (b) it wouldn't have any of the other "VGA baggage". In my experience (which may or may not be authoritative), devices that "own" a subset of the guest-phyisical address space but are *not* PCI devices, are platform devices. Platform devices are hard to enumerate and to manage. They usually have ties to fw_cfg and/or ACPI and/or DT (Device Tree). Virtio-mmio is a good example I believe. People seem to frown upon platform devices, and prefer buses that are enumerable via hw access (for example, virtio-pci is considered vastly superior to virtio-mmio). In my mind (as I perceive others' opinions), PCI is a clear winner. Arguing that a PCI graphics device present its framebuffer differently from an MMIO BAR would be an uphill battle, I think. But, again, as you are commenting on the design of the VirtIo GPU Device, I'm not the right person to talk to. Thanks Laszlo