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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 F05E4C43331 for ; Fri, 27 Mar 2020 16:59:45 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 B9ADD206E6 for ; Fri, 27 Mar 2020 16:59:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="WSYetWWs"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z0W/GFfj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9ADD206E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=X5s4es8umLkHSVxiPC2vyMJjGujYhYagoO5T8urPGTo=; b=WSYetWWsSOmZal qi4+JEcWbNLv5EFYaCg/+U54QGqgjPakQQwr2GzWyaS7BN84Y0nMFa3YT4fczz0x+BMg3ThU4Ug1j vpd40bzPr7mDAOLyqSS5R3K6Qetn/GTH9PmfaBgAjTu8RrgDx5Mcn4d6EgNmHp8/PY3yJ64wqJS5I +j40cQv+/4levIzg0UA448OKthNqalnkOTo5hTS+p0uV7o9QYeYhU5XVbCUCaxRArY3vjVO0Mum0e yk2PdU4lQ7f8CLDvF1tm/eJg+bs61QoQkQ+XfTjft++00k63CX7PTkVE1s95kPGHpxjmDTRHb1H+K HIIpAWeVnUvLDzkK5wzQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jHsKf-0006dN-4E; Fri, 27 Mar 2020 16:59:45 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jHsKc-0006cz-1i for linux-arm-kernel@lists.infradead.org; Fri, 27 Mar 2020 16:59:43 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (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 88AE8206E6; Fri, 27 Mar 2020 16:59:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585328381; bh=MvORsB1dXvIVi4W8/BF44aEMuNPoatu951ma4R+Bhj4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z0W/GFfjVghNGtgiyX/lazsrRNOG8cF7ZTfPdUa9Whbcb6+vCtT+MV7NU3NJGMMPS YS5wzuPN1pf0X4Le2OxCBz+OVqoBQWXP4l6++a732vJdT5WJKVUKgYNt1IMmiRiJ7K bVYUEumFyaZ7E+SvP9FdCNdDrAwCGbghojU7ipJU= Date: Fri, 27 Mar 2020 16:59:36 +0000 From: Will Deacon To: James Morse Subject: Re: [RFC PATCH] arm64: unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE} Message-ID: <20200327165935.GA8048@willie-the-truck> References: <20200327143941.195626-1-ascull@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200327_095942_114520_E22E5393 X-CRM114-Status: GOOD ( 13.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qwandor@google.com, qperret@google.com, Marc Zyngier , Suzuki K Poulose , tabba@google.com, Steven Price , wedsonaf@google.com, Andrew Scull , dbrazdil@google.com, kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi James, On Fri, Mar 27, 2020 at 04:11:56PM +0000, James Morse wrote: > On 3/27/20 2:39 PM, Andrew Scull wrote: > > Errata 1165522, 1319367 and 1530923 each allow TLB entries to be > > allocated as a result of a speculative AT instruction. In order to > > avoid mandating VHE on certain affected CPUs, apply the workaround to > > both the nVHE and the VHE case for all affected CPUs. > > You're booting a VHE capable system without VHE, and need KVM? > Do tell! I'll stick my neck out for this part... Basically, we're looking at enabling virtualisation on Android through KVM and we're going to be upstreaming more of this as it gets going. One of the goals of this work is to provide an environment where virtual machines can run in isolation from the KVM host; in such a design, the guest memory must not be accessible to the host, so this doesn't lend itself at all to VHE. Our current work is focussing on extending the nVHE __hyp_text so that things like stage-2 page table and vCPU state is all handled there, with a stage-2 put over the host kernel to prevent access to guest memory. The host is still responsible for scheduling vCPUs, so a compromised host can cause a DoS but it's the data integrity that we really care about. We're looking at implementing this on top of the SPCI spec from Arm, where the VMs are a lot less dynamic than a traditional KVM invocation but implement message passing and shared memory interfaces so that we can still use things like virtio. We're also aiming to support SPCI partitions alongside traditional VMs, although the stage-2 must still be handled at EL2 for both types of guest. It's a bit like a Type-1.5 hypervisor ;) Anyway, there's plenty to do, but one of the exercises is removing some of the artificial Kconfig dependencies we have on VHE. This erratum workaround is one of them, but there are others such as SVE and Pointer Auth. > Would enabling the nVHE workaround on a VHE capable part solve your problem? Could do, but it seems a bit weird to enable the workarounds independently once both VHE and nVHE are supported. We probably need to use has_vhe() to distinguish the two paths, rather than rely on the presence of the workaround as a proxy for that. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel