From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.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 058A22117D26C for ; Tue, 23 Oct 2018 07:03:07 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D744681F0F; Tue, 23 Oct 2018 14:03:06 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-214.rdu2.redhat.com [10.10.120.214]) by smtp.corp.redhat.com (Postfix) with ESMTP id 22EB310018FB; Tue, 23 Oct 2018 14:02:58 +0000 (UTC) To: Gerd Hoffmann Cc: yuchenlin , edk2-devel@lists.01.org, jordan.l.justen@intel.com, ard.biesheuvel@linaro.org, anthony.perard@citrix.com, julien.grall@linaro.org, Phil Dennis-Jordan References: <20181023024057.21942-1-yuchenlin@synology.com> <3f1bacc3feaf1ce6de3b42f91cf689ea@synology.com> <917454c5-3420-aba3-097f-0ac46b6792c4@redhat.com> <20181023134225.k56ujprawo3qdjm7@lupin.home.kraxel.org> From: Laszlo Ersek Message-ID: Date: Tue, 23 Oct 2018 16:02:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181023134225.k56ujprawo3qdjm7@lupin.home.kraxel.org> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 23 Oct 2018 14:03:07 +0000 (UTC) Subject: Re: [PATCH] OvmfPkg: initialize bochs when initializing vmsvga X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 14:03:08 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/23/18 15:42, Gerd Hoffmann wrote: > Hi, > >> Please help me see the situation better. Here's my current >> understanding. >> >> (1) QemuVideoDxe doesn't set up the VMW SVGA FIFO, and does not store 1 >> to the SVGA_REG_CONFIG_DONE register. And this is not a "small >> missing step" -- the FIFO setup can be considered a separate >> feature. >> >> (2) We don't intend to implement the FIFO setup feature. (In particular >> because we don't intend to track changed rectangles and send updates >> via the FIFO.) >> >> (3) The intent of the original VMW SVGA enablement patch for >> QemuVideoDxe, namely commit c137d9508169, was to enable booting some >> UEFI operating systems on OVMF that had guest drivers only for VMW >> SVGA. >> >> (4) The QEMU device model now -- since commit 104bd1dc70 -- falls back >> to stdvga (that is, Bochs) in response to QemuVideoDxe's actions. >> >> (5) Your proposal is to set up the Bochs interface in QemuVideoDxe, *in >> addition* to the -- now dysfunctional! -- VMW SVGA interface. >> >> Is my understanding correct? > > I understand things the same way. > >> So, what do you think of the following approach, instead of your >> currently proposed patch: >> >> - revert commit c137d9508169 ("OvmfPkg/QemuVideoDxe: VMWare SVGA device >> support", 2017-04-07) >> >> - revert commit 05a537945872 ("OvmfPkg/QemuVideoDxe: Helper functions >> for unaligned port I/O.", 2017-04-07) >> >> - given that QEMU provides the Bochs interface anyway, with the VMW SVGA >> device model, simply recognize the "QEMU VMWare SVGA" card, in the >> "gQemuVideoCardList" array, as the QEMU_VIDEO_BOCHS_MMIO variant. > > Makes sense to me. Great, thank you. > Alternatively write a full-blown vmsvga driver which works simliar to > the virtio-gpu driver. I have my doubts this is worth the effort > though. Right, please let us *not* do this. > >> Before QEMU commit 104bd1dc70, was it really *required* to use the (now >> dead) QemuVideoDxe code for VMW SVGA, or would it always have been >> possible to simply use the Bochs interface, to drive the VMW SVGA >> device? > > I think bochs interface works works with all vmsvga version (in qemu). Great! > Didn't test though. That's fine; I think I haven't tested VMW SVGA, as in "ever". That's up to people that actually use the device model. As I wrote previously, it's quite telling that the consequences of QEMU commit 104bd1dc70, from release v2.10.0, are reported only now, more than a year after the release -- VMW SVGA must not be a very popular device model. Yuchenlin, can you then please investigate this approach, including testing the reverts (the Bochs-only implementation) against QEMU v2.9.1? (FWIW, upstream QEMU doesn't seem to support earlier releases than v2.10.2 any longer, according to . So even if the v2.9.1 test failed, maybe we shouldn't care, in *upstream* edk2. Still, knowing the status would be useful.) Thanks! Laszlo