From nobody Tue May 7 14:05:23 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=linaro.org ARC-Seal: i=1; a=rsa-sha256; t=1575905177; cv=none; d=zohomail.com; s=zohoarc; b=egwP2WREPgVN9x4P2thm+hp+I2iZXRnj3htZlEXFm7xDpkbySKJ2weZArBIh8u1ae6GgjBNA1eykP8KxeVGzMwbbVnuodWeKFkGoAwhB8P0zsRwQSVjZuw7bAs9M1HqQiw5MOI7Yemmafsy2iN5Zg1Dk5be0J7Vzjsv62diziTw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1575905177; h=Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=aGde4CZaZE2g83epTJ24+hkZLk06bQgpmJ+TMTkjII4=; b=JmuOgbzFYKPRwMEXTJANjYyJf/eDMb+EeJl/k59JFzB3Hp2735W5Mm278+wbb2zIbQcohBetfJPb2WcnVx0abEvgULPgPz5RWYidO9abquwqggsc0sJNgeLqaTlosUj7SbxwzNSwTKNFXZlKb2iRpRZH+DoD3hTfBDOJXwKemHU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 157590517738793.41287249840525; Mon, 9 Dec 2019 07:26:17 -0800 (PST) Received: from localhost ([::1]:41566 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieKvP-0003qs-5b for importer@patchew.org; Mon, 09 Dec 2019 10:26:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53642) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieKuS-0002ms-4h for qemu-devel@nongnu.org; Mon, 09 Dec 2019 10:25:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ieKuN-0006VL-2g for qemu-devel@nongnu.org; Mon, 09 Dec 2019 10:25:16 -0500 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]:32811) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ieKuM-0006U7-Pd for qemu-devel@nongnu.org; Mon, 09 Dec 2019 10:25:11 -0500 Received: by mail-wr1-x443.google.com with SMTP id b6so16686993wrq.0 for ; Mon, 09 Dec 2019 07:25:10 -0800 (PST) Received: from wychelm.lan (cpc141214-aztw34-2-0-cust773.18-1.cable.virginm.net. [86.9.19.6]) by smtp.gmail.com with ESMTPSA id u18sm27606386wrt.26.2019.12.09.07.25.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2019 07:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=aGde4CZaZE2g83epTJ24+hkZLk06bQgpmJ+TMTkjII4=; b=LnvACBIHHIl30sTRb/r3Cefu+ncKuO1uJiadFQydWCKRSfsIH42wpHy5X3aaSWou6R INMnkPlJxvep/tztrMzqi/mL/I36D+JWuXHJOruImZZ7u+80R37hujLCZFTLlMQnMyCN wuM0W9J1mLZBTlobHENItkSuzeXQoslito/jYxvr5JQn1YTAo936/AVoDWFIqxe8r9BF 6eCmeZw2F9j5pa6S4A308zbIaZ4aE+shSWcpNG5aa1+6l+jgZq0qvtgvI5vEdGgD6RU6 y367pRB00srhm6/onSWkHugDp4q9eeJhrT6zPPmPTz/VEuz0ZyxpjCHx7oP04WlmdZIc qvrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=aGde4CZaZE2g83epTJ24+hkZLk06bQgpmJ+TMTkjII4=; b=RpCjGcru/MRz9uPEWn8vl37J9oTrcp1fkoN7DlumcQUvPt6o2fHUGR1Eu/XFL1LpOJ 0uXb0p8v5BGD+D1bApq2e/GKMCaPH9CFT5T8dwqbBkLc96Zzfsak87k9vY0GmpTt3EZa AW0dzrerRdh79kj1XfbEkaVFyAOIYslJSDYjA4jQS/i2pw24GiAoLYSlDNzz3YozkdHL MD2NBKSVRH6lG6G4OAm3uQ1Ziokh/8rDnthDRGm8+h6OPVKuacu3z/nHm2sVnM4z9LjJ 5vRRBhWpCkPPl7Bcqxm9iSrKUiVbz9GD/YFuhzbVsa8R7dppFz2ZubfOdgGbm2uxGTqZ rMvg== X-Gm-Message-State: APjAAAXZIXelDrHejjmD8RyV+dCk/NYUaRqBFABx6Ii7psv5leWztt03 1j/8ZP+qGe7SBse1SHcnh/csmw== X-Google-Smtp-Source: APXvYqzuy/laWjexzdEipuxFiA5531SrDLRRfqUM2bZmR0ybwssZlMTDLKI1lDHCYXOpnQ6ujdse9A== X-Received: by 2002:adf:ca07:: with SMTP id o7mr2831505wrh.49.1575905108758; Mon, 09 Dec 2019 07:25:08 -0800 (PST) From: Daniel Thompson To: Peter Maydell Subject: [PATCH] hw/arm/virt: Second uart for normal-world Date: Mon, 9 Dec 2019 15:24:55 +0000 Message-Id: <20191209152456.977399-1-daniel.thompson@linaro.org> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::443 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daniel Thompson , qemu-arm@nongnu.org, qemu-devel@nongnu.org, patches@linaro.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: pass (identity @linaro.org) Content-Type: text/plain; charset="utf-8" The virt machine can have two UARTs but the second UART is only registered when secure-mode support is enabled. Change the machine so this UART is always registered bringing the behaviour of the virt machine closer to x86 land, where VMs can be expected to support two UARTs. This approach is also similar to how a TZPC would typically make a UART inaccessible to normal world on physical hardware. Signed-off-by: Daniel Thompson --- Notes: It is difficult to add a UART without some kind of odd difference of behaviour somewhere. As far as I could tell the choices are: =20 1. Move the secure UART from UART1 to UART2. This is a not-backward-compatible difference of behaviour (will likely break the command lines for existing users of the secure UART). =20 2. We tack the new UART on at the end, meaning UART1 will re-enumerates as UART2 when secure mode is enabled/disabled. This is rather surprising for users. =20 3. UART1 is registered and inaccessible when secure mode is not enabled (e.g. user must provide a dummy -serial argument to skip the missing UART) =20 4. Normal world can only use the second UART if there is no secure mode support. =20 5. Don't support an extra UART ;-) =20 Of these I concluded that #4 was least worst! Ultimately it is should be unsurprising for users because it is how most physical hardware works (e.g. a trustzone controller is used to make an existing UART inaccessible to normal world). hw/arm/virt.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index d4bedc260712..a5cca04dba7f 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -1721,6 +1721,12 @@ static void machvirt_init(MachineState *machine) if (vms->secure) { create_secure_ram(vms, secure_sysmem); create_uart(vms, pic, VIRT_SECURE_UART, secure_sysmem, serial_hd(1= )); + } else { + /* + * If secure mode is disabled then let's setup the "secure" + * UART so that normal world can use it. + */ + create_uart(vms, pic, VIRT_SECURE_UART, sysmem, serial_hd(1)); } vms->highmem_ecam &=3D vms->highmem && (!firmware_loaded || aarch64); base-commit: 8350b17be015bb872f28268bdeba1bac6c380efc -- 2.23.0