From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::143; helo=mail-it1-x143.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 6C3B7211D07AD for ; Fri, 1 Mar 2019 07:14:23 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id l66so21822776itg.3 for ; Fri, 01 Mar 2019 07:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lPYV2IkGO/+LbfeB5dilLD6bVPIc6bDl+onfjxGgFYE=; b=oEDYDMvrOKukewtghnBn7PD8Bx/4MXHi/ppSXqHsAeE0biSHBwz2AqWTX1TcP/27dx fcRQst8FSu37xOzj2OpxDUsRALPN+0MBzL2Q4sxZxkaCoj5WoRJGdakpURh4yN87PeXz cAa1BbhcDT6SGC7mgslf9dapEe8218Onm73bP00l2h32mM9ytxLrWnhdUb+Lliep8qqU 75qT1yM+S4sL9gmC6Q6qH7ZA66l8hHey6mKzb7tOF70fJj7JBdrhDzKYg3LSqbriPao1 zVb8H7Fa2IiJkMXOw6p+xfIqm9UAvjZe8V50xJujJ773LZmQkmBO5XEtWTroPLdv8muT V1vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lPYV2IkGO/+LbfeB5dilLD6bVPIc6bDl+onfjxGgFYE=; b=lMEVbQgBk92wU0dNQTcfyEhLZv4LesjfYFCycP19lww2frYcPBnwtyYdwHlfZ7kdDp FqTlaePCcRZGl6MBa5ulwcTcmWZAdOA2B/QNzItgQ26ua7s/ksQ7p5KMU9JLF+6stbGg sOJq9Ov8tiMN7UpRhimAriguyHWO76ZCdCCb06OKnFaEim/GwJ2QorTTq2aUITEDOeqU kC7T2gjscpuNQMWOyrckBzvHrhnPEIeNcx3Oiqba2M8ZPQwnaT1SXd8ujd6atwix9dVv yzTMOaucaSDUyHxTFmYQ0P39VVAeK5TP9zd5iRCO4SMi0IU5VDPBArtSgAIvzU4sQjRq 8z9Q== X-Gm-Message-State: APjAAAUi8M7+4V/SkND/s/RKM/ttIx6gb6kkQ7qwwb6M2jyq2DKDzdNA oei+q0g+4em4RhcHfwjNgoe9sjV6ivhs2dFzhdZoCA== X-Google-Smtp-Source: APXvYqywNQA9BiskfZbEWiZvyNNZG1JLortN0XtBJ0Uo1o0D2qJ/Eexvc8vzWdigfN42ZrxY//w86xioLhn5sIPjDBY= X-Received: by 2002:a02:3342:: with SMTP id k2mr2764282jak.62.1551453262074; Fri, 01 Mar 2019 07:14:22 -0800 (PST) MIME-Version: 1.0 References: <1551341112-21645-1-git-send-email-guoheyi@huawei.com> <668ad400-578a-672a-1df8-0ca72eb2a083@redhat.com> In-Reply-To: From: Ard Biesheuvel Date: Fri, 1 Mar 2019 16:14:10 +0100 Message-ID: To: Laszlo Ersek Cc: Heyi Guo , "edk2-devel@lists.01.org" , Hao Wu , Julien Grall , wanghaibin 00208455 , Peter Maydell 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 15:14:23 -0000 Content-Type: text/plain; charset="UTF-8" On Fri, 1 Mar 2019 at 15:59, Laszlo Ersek wrote: > > +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 fundamentally broken. The OS will drive the PL011 in interrupt mode, while the firmware will poll the FIFO registers directly. > This is why I'm not a big fan of this approach. Using separate devices > for kernel and firmware would be a lot better. > +1 > 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