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.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,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 5E342C2B9F4 for ; Thu, 17 Jun 2021 12:15:06 +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 2A66F610A2 for ; Thu, 17 Jun 2021 12:15:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A66F610A2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=DB9wzLavaOfv/zMC50NUkypV7sYxzty8MGFCCqN2M6s=; b=SAUbdLBeCCHwrl eY0MV8SABunD9vzWOuxEAVxTJOhTm0mDscnLLqEtKx4cmUgUQmbDF5kUAShLKYgTdiOmdsTOwOwLG as5DENxuVAdoHLVjl8FfSCGZZJwYCCgruS5tdxW5eveQgnJnXw9/S59cE/c1H27UR0SsNuTMkWMnp CPLbuWNnShk80CGmLqkbdhYU7O/8aYhKpdm7XnYd8RVo3wkm4yaQ6qIMqSBv2D+z9kROBbG1SBr0h KisZv2wcdeStJRJzQMwe/sZXjcf8ctRMpHJkfzUZjjb/mB6L6QZA2zI324PwqmQ+i7WdXpo8H1WPw 6LrZ2Yp0fQBIEA4uBDgw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltqto-00AEdj-U3; Thu, 17 Jun 2021 12:13:33 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltqtk-00AEcj-4s for linux-arm-kernel@lists.infradead.org; Thu, 17 Jun 2021 12:13:29 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id C580D610EA; Thu, 17 Jun 2021 12:13:24 +0000 (UTC) Date: Thu, 17 Jun 2021 13:13:22 +0100 From: Catalin Marinas To: Steven Price Cc: Marc Zyngier , Will Deacon , James Morse , Julien Thierry , Suzuki K Poulose , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , Mark Rutland , Thomas Gleixner , qemu-devel@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , Richard Henderson , Peter Maydell , Haibo Xu , Andrew Jones Subject: Re: [PATCH v15 0/7] MTE support for KVM guest Message-ID: <20210617121322.GC6314@arm.com> References: <20210614090525.4338-1-steven.price@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210614090525.4338-1-steven.price@arm.com> 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-20210617_051328_246847_40DEA65C X-CRM114-Status: GOOD ( 15.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jun 14, 2021 at 10:05:18AM +0100, Steven Price wrote: > I realise there are still open questions[1] around the performance of > this series (the 'big lock', tag_sync_lock, introduced in the first > patch). But there should be no impact on non-MTE workloads and until we > get real MTE-enabled hardware it's hard to know whether there is a need > for something more sophisticated or not. Peter Collingbourne's patch[3] > to clear the tags at page allocation time should hide more of the impact > for non-VM cases. So the remaining concern is around VM startup which > could be effectively serialised through the lock. [...] > [1]: https://lore.kernel.org/r/874ke7z3ng.wl-maz%40kernel.org Start-up, VM resume, migration could be affected by this lock, basically any time you fault a page into the guest. As you said, for now it should be fine as long as the hardware doesn't support MTE or qemu doesn't enable MTE in guests. But the problem won't go away. We have a partial solution with an array of locks to mitigate against this but there's still the question of whether we should actually bother for something that's unlikely to happen in practice: MAP_SHARED memory in guests (ignoring the stage 1 case for now). If MAP_SHARED in guests is not a realistic use-case, we have the vma in user_mem_abort() and if the VM_SHARED flag is set together with MTE enabled for guests, we can reject the mapping. We can discuss the stage 1 case separately from this series. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel