From patchwork Fri Apr 28 09:55:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cornelia Huck X-Patchwork-Id: 13226187 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 830EDC77B60 for ; Fri, 28 Apr 2023 10:03:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345781AbjD1KDE (ORCPT ); Fri, 28 Apr 2023 06:03:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230198AbjD1KCw (ORCPT ); Fri, 28 Apr 2023 06:02:52 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 92BFA5BB9 for ; Fri, 28 Apr 2023 03:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682676120; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=beGSlsM1YO7VmD2gFWs75nRL02r/305Ahmeskyo8oHQ=; b=UzkviSKRYDF5k8yvIGm53PpBYD28wTzXwsmxEkQJ1XcKlVIJMdj26pStsc/r6R2Vuqpe0a BYDzpjHjzRlArF02qVRGG/dFymzpm1MUrk1C+aKvzpHGTz78tMINMSNUf8dPsBD4XH2iuM 9CL38Lv4ThHfR7rAdEwTNSgKQps8SGA= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-654-ZZNYkKpRNiuMLttegxqNmw-1; Fri, 28 Apr 2023 05:55:39 -0400 X-MC-Unique: ZZNYkKpRNiuMLttegxqNmw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 054CA1C0754D; Fri, 28 Apr 2023 09:55:39 +0000 (UTC) Received: from gondolin.redhat.com (unknown [10.39.193.17]) by smtp.corp.redhat.com (Postfix) with ESMTP id 178FB1121314; Fri, 28 Apr 2023 09:55:36 +0000 (UTC) From: Cornelia Huck To: Peter Maydell , Paolo Bonzini Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org, kvm@vger.kernel.org, Eric Auger , Juan Quintela , Gavin Shan , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Richard Henderson , Andrea Bolognani , Cornelia Huck Subject: [PATCH v7 0/1] arm: enable MTE for QEMU + kvm Date: Fri, 28 Apr 2023 11:55:32 +0200 Message-Id: <20230428095533.21747-1-cohuck@redhat.com> MIME-Version: 1.0 Content-type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org v7 takes a different approach to wiring up MTE, so I still include a cover letter where I can explain things better, even though it is now only a single patch :) Previous versions used a cpu property to control MTE enablement, while keeping the same semantics for the virt machine "mte" property as used with tcg. This version now uses the machine property for kvm as well; while it continues to control allocation of tag memory for tcg, it now also controls enablement of the kvm capability. Since the cpu prop is now gone, so is the testing via the arm cpu props test; I don't have a good idea for testing mte on kvm automatically, since it has a hard dependency on host support. (Should I tack some futher documentation somewhere? I'm not seeing an obvious place.) A kvm guest with mte enabled still cannot be migrated (we need some uffd interface enhancements before we can support postcopy), so it is still off per default. Another open problem is mte vs mte3: tcg emulates mte3, kvm gives the guest whatever the host supports. Without migration support, this is not too much of a problem yet, but for compatibility handling, we'll need a way to keep QEMU from handing out mte3 for guests that might be migrated to a mte3-less host. We could tack this unto the mte property (specifying the version or max supported), or we could handle this via cpu properties if we go with handling compatibility via cpu models (sorting this out for kvm is probably going to be interesting in general.) In any case, I think we'll need a way to inform kvm of it. Tested with kvm selftests on FVP (as I still don't have any hardware with MTE...) and some make check(-tcg) incantations. Hopefully, I haven't (re)- introduced too many issues. Cornelia Huck (1): arm/kvm: add support for MTE hw/arm/virt.c | 69 +++++++++++++++++++++++++------------------- target/arm/cpu.c | 9 +++--- target/arm/cpu.h | 4 +++ target/arm/kvm.c | 35 ++++++++++++++++++++++ target/arm/kvm64.c | 5 ++++ target/arm/kvm_arm.h | 19 ++++++++++++ 6 files changed, 107 insertions(+), 34 deletions(-)