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 DEA49202E53CF for ; Fri, 1 Mar 2019 06:59:17 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D4A0C301BED9; Fri, 1 Mar 2019 14:59:16 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-56.rdu2.redhat.com [10.10.120.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3B4EE5C1B5; Fri, 1 Mar 2019 14:59:15 +0000 (UTC) To: Heyi Guo , edk2-devel@lists.01.org Cc: Hao Wu , Julien Grall , wanghaibin.wang@huawei.com, Ard Biesheuvel , Peter Maydell References: <1551341112-21645-1-git-send-email-guoheyi@huawei.com> <668ad400-578a-672a-1df8-0ca72eb2a083@redhat.com> From: Laszlo Ersek Message-ID: Date: Fri, 1 Mar 2019 15:59:14 +0100 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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Fri, 01 Mar 2019 14:59:16 +0000 (UTC) Subject: Re: [RFC 0/3] Enable runtime serial debug for ArmVirtQemu 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: Fri, 01 Mar 2019 14:59:18 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit +Peter On 03/01/19 13:24, Heyi Guo wrote: > On 2019/2/28 21:39, Laszlo Ersek wrote: >> (4) What's most worrying is that this change would lead to an unexpected >> sharing of the PL011 device between the OS and the firmware. I don't >> think that's a great idea, especially if QEMU's ACPI payload explicitly >> advertises the port to the OS. > That's true, so I propose to disable the feature by default. It is only > used for UEFI runtime code debug. It is always painful when we don't a > handy debug tool for runtime services code. I think this is the only problem that we have at the design level. What I'd like to understand is whether it is safe to drive the PL011 serial port from both the firmware and the kernel. Consider a situation where one VCPU in the guest executes a runtime service call, and writes to PL011 from firmware code. Meanwhile a different VCPU in the guest executes some kernel code that produces a log message directly on the serial console. (Because, I don't think that a runtime service call on one CPU stops the world for *all* CPUs, in the Linux kernel.) For starters, the serial output could be garbled, as a consequence, but will the PL011 register state be messed up irrevocably as well? I don't know. This is why I'm not a big fan of this approach. Using separate devices for kernel and firmware would be a lot better. I remember that Peter did some work to enable two PL011 devices on the "virt" board. IIRC the issue was that the PL011 enumeration order / numbering in edk2, and in the Linux (guest) kernel, was exactly the opposite. And that caused both logs to go to different devices; you couldn't have a single log file that started with the firmware log, and continued (after a definite switch-over) with the kernel log. But in this case, where the firmware could produce log messages on serial during OS runtime, that's actually the setup I would recommend. A clean separation between the serial devices used by the firmware and the OS. The rest of the issues in this series should be more simple to clean up (rework some commit messages, remove stale code etc). Thanks Laszlo