From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 AE6661A1E76 for ; Thu, 1 Sep 2016 13:26:37 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id i184so1653736itf.1 for ; Thu, 01 Sep 2016 13:26:37 -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=4LDYhLvlK0nRGEvENjIY7LtoF8kh+IDpCNqZkX07vBE=; b=GJHAytxlCk/he2DFSA/BLZ6tGvllDnXMhs0rhOE2JM+6p6BlBFwJ3dNKOKVMslWr8W K/CUtcGYqBiHkdJnH00d6ZW54Acv1wOBwOkeCncoMyw+R24jIvaVHSMlTuW3Xf8pHhyx YRPKyDvl8v8K1PwUBpAEAgW9nmtQsRnaF6POk= 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=4LDYhLvlK0nRGEvENjIY7LtoF8kh+IDpCNqZkX07vBE=; b=mmqSpWI8UccMM4nXMMuPVIAhOgTM+SUl+Jud4cEv21+DqGXJHzRZ+1kDCkUotvULmO Z/z0rEIRcQG/lYGl7goCZ46V+xjF+6RfmQiIJ2TXS3k4OrmmK9dHkvfN/NTIo44TpARm 9e3Gm+KQGjgV5o0HwPq79ZSlILQIJSoG++65yx2kt65GmFcg9v8cWbpAHX+HcscnkZ6I /5OZDumPW6VEMWW93l3XQOZ1KwuHt5vsqvxn8A+ll4/fHfRD4fcj7HX2/bOowKpYqxY4 Env2w2nUWFcyp6skGtl+4jptXr/8QKdI2Nk+gn/OfuUPsAOvnTp7UKzQ4xMeCvfUT9yv TLZw== X-Gm-Message-State: AE9vXwOo9lfvBWUXdSsz/6GvuqimQJ9XK1trldQIVENdLAVtkIRTUUFYHmAw5T/5ijgEHrpXOdcdC8H0unoode7b X-Received: by 10.36.25.144 with SMTP id b138mr40057598itb.29.1472761596964; Thu, 01 Sep 2016 13:26:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Thu, 1 Sep 2016 13:26:36 -0700 (PDT) In-Reply-To: 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:26:36 +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:26:37 -0000 Content-Type: text/plain; charset=UTF-8 On 1 September 2016 at 21:23, Ard Biesheuvel wrote: > 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 ... of performance > 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.