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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 CF921C388F9 for ; Thu, 19 Nov 2020 19:13:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 4E1DD21D40 for ; Thu, 19 Nov 2020 19:13:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="26yaPzOO"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lXvWCxF8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E1DD21D40 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+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=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ehM47AQvqO4qF3O+T/xFBrbgSCkwBQ3paAou+q8WaUM=; b=26yaPzOOZ7UDqbq856lT4x4+6 Aa+CIyvWSPxhAeLoDe21UHzpNgJmOU/bULfYExrO58Hw/DtL5h+Qrktmh1UCUSCSRvewsd9yyaQmL s24+Uby/CxSZDxL9I8c31CeRofP53TPaVcLdolnxEDlAdENCODI5zt/Jaw5bHF4zKx9aU6O5HQ6/z UNwkQOCIChGcxnQWie1R6dLz5vpYt0HaU0YYrNocHoJKcK9Oq/iu5kTSoQGUO6P5/PMlJ+fRfinFE soOSLkWYOOrqPwldntRsknK5vp37XoKPBQBa3wZS2FJyZOy0KBD9BU99v62jYm/+PlVSG7TY6LHQ4 AqmTV0znw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfpMF-0004nc-RX; Thu, 19 Nov 2020 19:12:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfpLa-0004Yd-0o for linux-arm-kernel@lists.infradead.org; Thu, 19 Nov 2020 19:11:59 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (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 BB77A208D5; Thu, 19 Nov 2020 19:11:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605813116; bh=XyD+uyMaviImuATuD/h4kUXMXfBH+Udbo+OGArJdcB4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lXvWCxF8cD+nUERBpe5nbs32UMfizZuC8mx5wH0gw+SOer45PM7TBYg0vTztvJoke 9yb8vAB926OI2q0x6zS1+P/r/32sAjZ22cHmbqSbEnzy818YvqDRb3rfNmcKF8R6Op Qs7I7BYnH4Hb4+ikyoXYgmwJcfYVLv5DNTtzqy/M= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kfpLW-00C3aD-GL; Thu, 19 Nov 2020 19:11:54 +0000 MIME-Version: 1.0 Date: Thu, 19 Nov 2020 19:11:54 +0000 From: Marc Zyngier To: Andrew Jones Subject: Re: [PATCH v5 0/2] MTE support for KVM guest In-Reply-To: <20201119184248.4bycy6ouvaxqdiiy@kamzik.brq.redhat.com> References: <20201119153901.53705-1-steven.price@arm.com> <20201119184248.4bycy6ouvaxqdiiy@kamzik.brq.redhat.com> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: drjones@redhat.com, peter.maydell@linaro.org, steven.price@arm.com, mark.rutland@arm.com, dgilbert@redhat.com, Haibo.Xu@arm.com, suzuki.poulose@arm.com, qemu-devel@nongnu.org, catalin.marinas@arm.com, quintela@redhat.com, richard.henderson@linaro.org, linux-kernel@vger.kernel.org, Dave.Martin@arm.com, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, will@kernel.org, kvmarm@lists.cs.columbia.edu, julien.thierry.kdev@gmail.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201119_141158_299979_FF0CFCD6 X-CRM114-Status: GOOD ( 31.14 ) 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: Mark Rutland , Peter Maydell , Haibo Xu , Suzuki K Poulose , QEMU Developers , Catalin Marinas , Juan Quintela , Richard Henderson , "Dr. David Alan Gilbert" , Steven Price , James Morse , arm-mail-list , kvmarm , Thomas Gleixner , Julien Thierry , Will Deacon , Dave Martin , lkml - Kernel Mailing List Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-11-19 18:42, Andrew Jones wrote: > On Thu, Nov 19, 2020 at 03:45:40PM +0000, Peter Maydell wrote: >> On Thu, 19 Nov 2020 at 15:39, Steven Price >> wrote: >> > This series adds support for Arm's Memory Tagging Extension (MTE) to >> > KVM, allowing KVM guests to make use of it. This builds on the existing >> > user space support already in v5.10-rc1, see [1] for an overview. >> >> > The change to require the VMM to map all guest memory PROT_MTE is >> > significant as it means that the VMM has to deal with the MTE tags even >> > if it doesn't care about them (e.g. for virtual devices or if the VMM >> > doesn't support migration). Also unfortunately because the VMM can >> > change the memory layout at any time the check for PROT_MTE/VM_MTE has >> > to be done very late (at the point of faulting pages into stage 2). >> >> I'm a bit dubious about requring the VMM to map the guest memory >> PROT_MTE unless somebody's done at least a sketch of the design >> for how this would work on the QEMU side. Currently QEMU just >> assumes the guest memory is guest memory and it can access it >> without special precautions... >> > > There are two statements being made here: > > 1) Requiring the use of PROT_MTE when mapping guest memory may not fit > QEMU well. > > 2) New KVM features should be accompanied with supporting QEMU code in > order to prove that the APIs make sense. > > I strongly agree with (2). While kvmtool supports some quick testing, > it > doesn't support migration. We must test all new features with a > migration > supporting VMM. > > I'm not sure about (1). I don't feel like it should be a major problem, > but (2). > > I'd be happy to help with the QEMU prototype, but preferably when > there's > hardware available. Has all the current MTE testing just been done on > simulators? And, if so, are there regression tests regularly running on > the simulators too? And can they test migration? If hardware doesn't > show up quickly and simulators aren't used for regression tests, then > all this code will start rotting from day one. While I agree with the sentiment, the reality is pretty bleak. I'm pretty sure nobody will ever run a migration on emulation. I also doubt there is much overlap between MTE users and migration users, unfortunately. No HW is available today, and when it becomes available, it will be in the form of a closed system on which QEMU doesn't run, either because we are locked out of EL2 (as usual), or because migration is not part of the use case (like KVM on Android, for example). So we can wait another two (five?) years until general purpose HW becomes available, or we start merging what we can test today. I'm inclined to do the latter. And I think it is absolutely fine for QEMU to say "no MTE support with KVM" (we can remove all userspace visibility, except for the capability). M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel