From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web10.16259.1586963149739508190 for ; Wed, 15 Apr 2020 08:05:50 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EtthFDrk; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586963148; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JlKM9ajWSzF3P6aqVkPpHugIcNnh/KmfZskQVp5TCQM=; b=EtthFDrkJTcg2mSwIh4n8gpkMthvR8o8HZtm2HC0yS/4Fqi4roYgj/WKKsKPOFHuNYgpfn IEMcFjoPRFcJZmwkNNAcVD0F4aWF8X5pCTgAiOyvh43ybTh4uhUelTi8Xv+ILBu+fXb4J5 /3xPd3m9hC2FlhiMWpudbOEx+p9qih4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-458-51BGrbO1MZWntTetEXcUvw-1; Wed, 15 Apr 2020 11:05:43 -0400 X-MC-Unique: 51BGrbO1MZWntTetEXcUvw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 023EC18C35B5; Wed, 15 Apr 2020 15:05:42 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-155.ams2.redhat.com [10.36.112.155]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0B7F5272C4; Wed, 15 Apr 2020 15:05:35 +0000 (UTC) Subject: Re: [edk2-discuss] Load Option passing. Either bugs or my confusion. To: valerij zaporogeci , Hou Qiming References: <623b1855-285c-cce3-c806-c17e5fd217ea@redhat.com> <5211.1586899245384995995@groups.io> Cc: discuss@edk2.groups.io, Gerd Hoffmann , "Marcel Apfelbaum (GMail address)" , edk2-devel-groups-io , qemu devel list From: "Laszlo Ersek" Message-ID: Date: Wed, 15 Apr 2020 17:05:35 +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: <5211.1586899245384995995@groups.io> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit (CC Gerd, Qiming, Marcel, qemu-devel for ramfb:) On 04/14/20 23:20, valerij zaporogeci wrote: [snip] > There is a Boot Manager UI display problem, I don't know if this is > qemu problem, but with the ARM (both 32 and 64 bits, the qemu version > is 4.2.0, the OVMF is fresh), and using "ramfb" device, the Boot > Manager has troubles with drawing - it's interfase looks entirely > broken, like this (I'll try to attach the screenshot). UEFI shell > doesn't have this problem. switching to "serial" (which is -serial vc) > doesn't produce it too. Only when ramfb is chosen, the Boot Manager UI > gets smeared. But it takes input and presumable works properly, except > displaying things. qemu writes these messages in the command prompt: > ramfb_fw_cfg_write: 640x480 @ 0x4bd00000 > ramfb_fw_cfg_write: resolution locked, change rejected > ramfb_fw_cfg_write: 800x600 @ 0x4bd00000 > ramfb_fw_cfg_write: resolution locked, change rejected Gerd contributed the OVMF QemuRamfbDxe driver in edk2 commit 1d25ff51af5c ("OvmfPkg: add QemuRamfbDxe", 2018-06-14). Note the date: June 2018. The then-latest (released) QEMU version was v2.12.0, and v2.12.1 / v3.0.0 were in the making. At that time, the resolution change definitely worked -- note my "Tested-by" on the edk2 commit message. Running "git blame" on the QEMU source, I now find commit a9e0cb67b7f4 ("hw/display/ramfb: lock guest resolution after it's set", 2019-05-24). Again, note the date: May 2019 (and this commit was released with QEMU v4.1.0). So I would say that the symptom you see is a QEMU v4.1.0 regression. The QemuRamfbGraphicsOutputSetMode() function in the OVMF ramfb driver certainly needs the QemuFwCfgWriteBytes() call to work, for changing the resolution. Now, I'm not familiar with the reasons behind QEMU commit a9e0cb67b7f4. It says it intends to "prevent[] a crash when the guest writes garbage to the configuration space (e.g. when rebooting)". But I don't understand why locking the resolution was necessary for preventing "a crash": (1) Registering a device reset handler in QEMU seems sufficient, so that QEMU forget about the currently shared RAMFB area at platform reset. (2) The crash in question is apparently not a *QEMU* crash -- which might otherwise justify a heavy-handed approach. Instead, it is a *guest* crash. See the references below: (2a) http://mid.mail-archive.com/CABSdmrmU7FK90Bupq_ySowcc9Uk=8nQxNLHgzvDsNYdp_QLogA@mail.gmail.com https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02299.html (2b) https://github.com/intel/gvt-linux/issues/23#issuecomment-483651476 Therefore, I don't think that locking the resolution was justified! Importantly: - The QemuRamfbDxe driver allocates the framebuffer in *reserved* memory, therefore any well-behaving OS will *never* touch the framebuffer. - The QemuRamfbDxe driver allocates the framebuffer memory only once, namely for such a resolution that needs the largest amount of framebuffer memory. Therefore, framebuffer re-allocations in the guest driver -- and thereby guest RAM *re-mapping* in QEMU -- are *not* necessary, upon resolution change. The ramfb device reset handler in QEMU is justified (for unmapping / forgetting the previously shared RAMFB area). The resolution locking is *NOT* justified, and it breaks the OVMF driver. I suggest backing out the resolution locking from QEMU. Reference (2a) above indicates 'It could be a misguided attempt to "resize ramfb" by the guest Intel driver'. If that is the case, then please fix the Intel guest driver, without regressing the QEMU device model. I'm sad that the QEMU device model change was not regression-tested against the *upstream* OVMF driver (which, by then, had been upstream for almost a year). Laszlo