From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=59.124.61.242; helo=synology.com; envelope-from=yuchenlin@synology.com; receiver=edk2-devel@lists.01.org Received: from synology.com (synology.com [59.124.61.242]) (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 6FAEE21163DFE for ; Tue, 23 Oct 2018 18:33:40 -0700 (PDT) Received: from _ (localhost [127.0.0.1]) by synology.com (Postfix) with ESMTPA id 697131FF5F11; Wed, 24 Oct 2018 09:33:38 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synology.com; s=123; t=1540344818; bh=F6oyu4UjGY8arHogKab/7pMWaxSfwrwLs/8YHrsXqf4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=af9YqUHQGkUAkqeVjmutNvP2IUQY70R2o0Q7mdM4JkXJZVx9Mebjwf/rXg8u0a5cK /C7ok3WupmFIZsWnx3TomA2DT1UQh25EFM9GXLzmwmVhjnlfTtv87teKVT90ifOqiy bRkm9eFVU63qcI5SjokY9q4607YtRUnod3qRIm6o= MIME-Version: 1.0 Date: Wed, 24 Oct 2018 09:33:38 +0800 From: yuchenlin To: Laszlo Ersek Cc: Gerd Hoffmann , 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 In-Reply-To: References: <20181023024057.21942-1-yuchenlin@synology.com> <3f1bacc3feaf1ce6de3b42f91cf689ea@synology.com> <917454c5-3420-aba3-097f-0ac46b6792c4@redhat.com> <20181023134225.k56ujprawo3qdjm7@lupin.home.kraxel.org> Message-ID: <441901c727f480df877c261f1e1e1279@synology.com> X-Sender: yuchenlin@synology.com User-Agent: Roundcube Webmail/1.1.2 X-Synology-MCP-Status: no X-Synology-Spam-Flag: no X-Synology-Spam-Status: score=0, required 6, WHITELIST_FROM_ADDRESS 0 X-Synology-Virus-Status: no 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: Wed, 24 Oct 2018 01:33:42 -0000 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2018-10-23 22:02, Laszlo Ersek wrote: > 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? > Sure! Thanks, yuchenlin > (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