From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2CD0C433E1 for ; Tue, 28 Jul 2020 18:14:45 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BACAB2078E for ; Tue, 28 Jul 2020 18:14:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="JPD7xYi4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BACAB2078E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1k0U7O-0000IG-4e; Tue, 28 Jul 2020 18:14:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1k0U7M-0000IB-3d for xen-devel@lists.xenproject.org; Tue, 28 Jul 2020 18:14:24 +0000 X-Inumbo-ID: 28cb16c7-d0fe-11ea-a922-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 28cb16c7-d0fe-11ea-a922-12813bfff9fa; Tue, 28 Jul 2020 18:14:23 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1FB9E2070B; Tue, 28 Jul 2020 18:14:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595960062; bh=Ji1GHAO1Gn5m+jRIp21fZ0RWs5O53yohkzmTy0JAAqI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=JPD7xYi4lTHBB9Rfqm25yKAV5DyXF/IO9C3qQQG1x95wTYVsePitnutw7zGg3yUAD OB4BxzkEb82aM9Bl+bc4OgjIKO5zRY7e3Utp0dPD1DWq543zpl+VmqouBpIR+FNidZ FEuFRju8LBOHnx6XpwzKZqSGuwGb9Yhjtzlijq5c= Date: Tue, 28 Jul 2020 11:14:14 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: =?UTF-8?Q?Andr=C3=A9_Przywara?= Subject: Re: dom0 LInux 5.8-rc5 kernel failing to initialize cooling maps for Allwinner H6 SoC In-Reply-To: Message-ID: References: <1c5cee83-295e-cc02-d018-b53ddc6e3590@xen.org> <02b630bd-22e0-afde-6784-be068d0948ae@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-67695330-1595959176=:646" Content-ID: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Alejandro Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-67695330-1595959176=:646 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: On Tue, 28 Jul 2020, André Przywara wrote: > On 28/07/2020 11:39, Alejandro wrote: > > Hello, > > > > El dom., 26 jul. 2020 a las 22:25, André Przywara > > () escribió: > >> So this was actually my first thought: The firmware (U-Boot SPL) sets up > >> some basic CPU frequency (888 MHz for H6 [1]), which is known to never > >> overheat the chip, even under full load. So any concern from your side > >> about the board or SoC overheating could be dismissed, with the current > >> mainline code, at least. However you lose the full speed, by quite a > >> margin on the H6 (on the A64 it's only 816 vs 1200(ish) MHz). > >> However, without the clock entries in the CPU node, the frequency would > >> never be changed by Dom0 anyway (nor by Xen, which doesn't even know how > >> to do this). > >> So from a practical point of view: unless you hack Xen to pass on more > >> cpu node properties, you are stuck at 888 MHz anyway, and don't need to > >> worry about overheating. > > Thank you. Knowing that at least it won't overheat is a relief. But > > the performance definitely suffers from the current situation, and > > quite a bit. I'm thinking about using KVM instead: even if it does > > less paravirtualization of guests, > > What is this statement based on? I think on ARM this never really > applied, and in general whether you do virtio or xen front-end/back-end > does not really matter. IMHO any reasoning about performance just based > on software architecture is mostly flawed (because it's complex and > reality might have missed some memos ;-) So just measure your particular > use case, then you know. > > > I'm sure that the ability to use > > the maximum frequency of the CPU would offset the additional overhead, > > and in general offer better performance. But with KVM I lose the > > ability to have individual domU's dedicated to some device driver, > > which is a nice thing to have from a security standpoint. > > I understand the theoretical merits, but a) does this really work on > your board and b) is this really more secure? What do you want to > protect against? For "does it work on your board", the main obstacle is typically IOMMU support to be able to do device assignment properly. That's definitely something to check. If it doesn't work nowadays you can try to workaround it by using direct 1:1 memory mappings [1]. However, for security then you have to configure a MPU. I wonder if H6 has a MPU and how it can be configured. In any case, something to keep in mind in case the default IOMMU-based setup doesn't work for some reason for the device you care about. For "is this really more secure?", yes it is more secure as you are running larger portions of the codebase in unprivileged mode and isolated from each other with IOMMU (or MPU) protection. See what the OpenXT and Qubes OS guys have been doing. [1] https://marc.info/?l=xen-devel&m=158691258712815 --8323329-67695330-1595959176=:646--