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=-7.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,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 BF957C433ED for ; Wed, 7 Apr 2021 15:30:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 884D361382 for ; Wed, 7 Apr 2021 15:30:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353604AbhDGPab (ORCPT ); Wed, 7 Apr 2021 11:30:31 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:57270 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353563AbhDGPa2 (ORCPT ); Wed, 7 Apr 2021 11:30:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617809418; 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: in-reply-to:in-reply-to:references:references; bh=rHuby28rSVBEts9hw5b8nEC5zGAh17eoAFfYGcwxu7Q=; b=g2AgWffpn6TO+hohi/KwachzJcLKc8nwRf+xbuNds2r5tLGItbf5tJpit5VIF7oxb6MPR8 X4e2gC22ibsysWraW/OYUspBU0LY4j0j48ccQOjRHX/a0/yJVz2hHn9LIockHAjuARdSKJ OfqWPQzcDMMzR+v4pLFwg40rNvxm2Z0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-180-H2GLtm1WMquhgnK143jYrw-1; Wed, 07 Apr 2021 11:30:14 -0400 X-MC-Unique: H2GLtm1WMquhgnK143jYrw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 08789107ACF2; Wed, 7 Apr 2021 15:30:12 +0000 (UTC) Received: from [10.36.114.68] (ovpn-114-68.ams2.redhat.com [10.36.114.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1B45419C78; Wed, 7 Apr 2021 15:30:06 +0000 (UTC) To: Catalin Marinas , Steven Price Cc: Mark Rutland , Peter Maydell , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , qemu-devel@nongnu.org, Marc Zyngier , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , James Morse , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> <20210407151458.GC21451@arm.com> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature Message-ID: <396423df-5c30-67f6-fcba-c041c08eef7e@redhat.com> Date: Wed, 7 Apr 2021 17:30:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210407151458.GC21451@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07.04.21 17:14, Catalin Marinas wrote: > On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote: >> On 31/03/2021 19:43, Catalin Marinas wrote: >>> When a slot is added by the VMM, if it asked for MTE in guest (I guess >>> that's an opt-in by the VMM, haven't checked the other patches), can we >>> reject it if it's is going to be mapped as Normal Cacheable but it is a >>> ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to >>> check for ZONE_DEVICE)? This way we don't need to do more expensive >>> checks in set_pte_at(). >> >> The problem is that KVM allows the VMM to change the memory backing a slot >> while the guest is running. This is obviously useful for the likes of >> migration, but ultimately means that even if you were to do checks at the >> time of slot creation, you would need to repeat the checks at set_pte_at() >> time to ensure a mischievous VMM didn't swap the page for a problematic one. > > Does changing the slot require some KVM API call? Can we intercept it > and do the checks there? User space can simply mmap(MAP_FIXED) the user space area registered in a KVM memory slot. You cannot really intercept that. You can only check in the KVM MMU code at fault time that the VMA which you hold in your hands is still in a proper state. The KVM MMU is synchronous, which means that updates to the VMA layout are reflected in the KVM MMU page tables -- e.g., via mmu notifier calls. E.g., in s390x code we cannot handle VMAs with gigantic pages. We check that when faulting (creating the links in the page table) via __gmap_link(). You could either check the page itself (ZONE_DEVICE) or might even be able to check via the VMA/file. -- Thanks, David / dhildenb 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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 4C729C433ED for ; Wed, 7 Apr 2021 15:33:00 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 AFA8F6138B for ; Wed, 7 Apr 2021 15:32:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFA8F6138B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:43966 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUAAs-0000jC-Da for qemu-devel@archiver.kernel.org; Wed, 07 Apr 2021 11:32:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUA8M-0007i2-Kq for qemu-devel@nongnu.org; Wed, 07 Apr 2021 11:30:23 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:42260) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUA8I-0004EP-7z for qemu-devel@nongnu.org; Wed, 07 Apr 2021 11:30:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617809416; 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: in-reply-to:in-reply-to:references:references; bh=rHuby28rSVBEts9hw5b8nEC5zGAh17eoAFfYGcwxu7Q=; b=awPx9a2vwTN4p952M82G/jwtY58/A8s3b1z/Rzq0iPWs9JdDHx9ReGBuG2gwV/Civb5YCt 0lGD3e8wMmWpyusy/8DpKxc3M49gQ5acuaA6TJBGHgrR8//zQlR3HTyyc0f2aI3/8mZZ1P WVGfosDMASoqudRJwFRuOwldUPvdhNw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-180-H2GLtm1WMquhgnK143jYrw-1; Wed, 07 Apr 2021 11:30:14 -0400 X-MC-Unique: H2GLtm1WMquhgnK143jYrw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 08789107ACF2; Wed, 7 Apr 2021 15:30:12 +0000 (UTC) Received: from [10.36.114.68] (ovpn-114-68.ams2.redhat.com [10.36.114.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1B45419C78; Wed, 7 Apr 2021 15:30:06 +0000 (UTC) To: Catalin Marinas , Steven Price References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> <20210407151458.GC21451@arm.com> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature Message-ID: <396423df-5c30-67f6-fcba-c041c08eef7e@redhat.com> Date: Wed, 7 Apr 2021 17:30:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210407151458.GC21451@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Received-SPF: pass client-ip=170.10.133.124; envelope-from=david@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Peter Maydell , Andrew Jones , Haibo Xu , Suzuki K Poulose , Marc Zyngier , Juan Quintela , Richard Henderson , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, James Morse , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Thomas Gleixner , Julien Thierry , Will Deacon , Dave Martin , linux-kernel@vger.kernel.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 07.04.21 17:14, Catalin Marinas wrote: > On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote: >> On 31/03/2021 19:43, Catalin Marinas wrote: >>> When a slot is added by the VMM, if it asked for MTE in guest (I guess >>> that's an opt-in by the VMM, haven't checked the other patches), can we >>> reject it if it's is going to be mapped as Normal Cacheable but it is a >>> ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to >>> check for ZONE_DEVICE)? This way we don't need to do more expensive >>> checks in set_pte_at(). >> >> The problem is that KVM allows the VMM to change the memory backing a slot >> while the guest is running. This is obviously useful for the likes of >> migration, but ultimately means that even if you were to do checks at the >> time of slot creation, you would need to repeat the checks at set_pte_at() >> time to ensure a mischievous VMM didn't swap the page for a problematic one. > > Does changing the slot require some KVM API call? Can we intercept it > and do the checks there? User space can simply mmap(MAP_FIXED) the user space area registered in a KVM memory slot. You cannot really intercept that. You can only check in the KVM MMU code at fault time that the VMA which you hold in your hands is still in a proper state. The KVM MMU is synchronous, which means that updates to the VMA layout are reflected in the KVM MMU page tables -- e.g., via mmu notifier calls. E.g., in s390x code we cannot handle VMAs with gigantic pages. We check that when faulting (creating the links in the page table) via __gmap_link(). You could either check the page itself (ZONE_DEVICE) or might even be able to check via the VMA/file. -- Thanks, David / dhildenb 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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 689CAC433ED for ; Wed, 7 Apr 2021 15:30:21 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id D571F61262 for ; Wed, 7 Apr 2021 15:30:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D571F61262 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 34B554B94D; Wed, 7 Apr 2021 11:30:20 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@redhat.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+U1-kuoPyyT; Wed, 7 Apr 2021 11:30:19 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1EAC94B93C; Wed, 7 Apr 2021 11:30:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id BD6884B93C for ; Wed, 7 Apr 2021 11:30:17 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb-9hqh+ZIKX for ; Wed, 7 Apr 2021 11:30:16 -0400 (EDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C89A64B902 for ; Wed, 7 Apr 2021 11:30:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617809416; 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: in-reply-to:in-reply-to:references:references; bh=rHuby28rSVBEts9hw5b8nEC5zGAh17eoAFfYGcwxu7Q=; b=awPx9a2vwTN4p952M82G/jwtY58/A8s3b1z/Rzq0iPWs9JdDHx9ReGBuG2gwV/Civb5YCt 0lGD3e8wMmWpyusy/8DpKxc3M49gQ5acuaA6TJBGHgrR8//zQlR3HTyyc0f2aI3/8mZZ1P WVGfosDMASoqudRJwFRuOwldUPvdhNw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-180-H2GLtm1WMquhgnK143jYrw-1; Wed, 07 Apr 2021 11:30:14 -0400 X-MC-Unique: H2GLtm1WMquhgnK143jYrw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 08789107ACF2; Wed, 7 Apr 2021 15:30:12 +0000 (UTC) Received: from [10.36.114.68] (ovpn-114-68.ams2.redhat.com [10.36.114.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1B45419C78; Wed, 7 Apr 2021 15:30:06 +0000 (UTC) To: Catalin Marinas , Steven Price References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> <20210407151458.GC21451@arm.com> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature Message-ID: <396423df-5c30-67f6-fcba-c041c08eef7e@redhat.com> Date: Wed, 7 Apr 2021 17:30:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210407151458.GC21451@arm.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Cc: Marc Zyngier , Juan Quintela , Richard Henderson , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Thomas Gleixner , Will Deacon , Dave Martin , linux-kernel@vger.kernel.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On 07.04.21 17:14, Catalin Marinas wrote: > On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote: >> On 31/03/2021 19:43, Catalin Marinas wrote: >>> When a slot is added by the VMM, if it asked for MTE in guest (I guess >>> that's an opt-in by the VMM, haven't checked the other patches), can we >>> reject it if it's is going to be mapped as Normal Cacheable but it is a >>> ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to >>> check for ZONE_DEVICE)? This way we don't need to do more expensive >>> checks in set_pte_at(). >> >> The problem is that KVM allows the VMM to change the memory backing a slot >> while the guest is running. This is obviously useful for the likes of >> migration, but ultimately means that even if you were to do checks at the >> time of slot creation, you would need to repeat the checks at set_pte_at() >> time to ensure a mischievous VMM didn't swap the page for a problematic one. > > Does changing the slot require some KVM API call? Can we intercept it > and do the checks there? User space can simply mmap(MAP_FIXED) the user space area registered in a KVM memory slot. You cannot really intercept that. You can only check in the KVM MMU code at fault time that the VMA which you hold in your hands is still in a proper state. The KVM MMU is synchronous, which means that updates to the VMA layout are reflected in the KVM MMU page tables -- e.g., via mmu notifier calls. E.g., in s390x code we cannot handle VMAs with gigantic pages. We check that when faulting (creating the links in the page table) via __gmap_link(). You could either check the page itself (ZONE_DEVICE) or might even be able to check via the VMA/file. -- Thanks, David / dhildenb _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 87C9DC433ED for ; Wed, 7 Apr 2021 15:32:25 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 18A046138B for ; Wed, 7 Apr 2021 15:32:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18A046138B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:Cc:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lO1HsAghdX8LA8Ghfgs5+WcrVpCDpl/3bYILlJ7UbF4=; b=hgnouv3LkuNuVWKsTsLPiYTCC EOmzvukoe/J3wEtbgWnIxWBvVYxVjOCCLG4VcNEGhcxjPoAc7Lof58wwjcVbs0ekZddZwQMTk4pZp foleink4Xmvml7LUI0YBd7bZquSXbGRUb1YJqDoW2cGiMKZBGyWZEZ9Lq6Bxx5KICO2N4YAZKW7UT o52mpI+sVi+ZPeuFHOfVH7hjObX+F6RGjFnhTZRHIQikyKwkQlFvS4mzfVL9NC/sqU9+ypmDQDOUL wnW53+gzfs0UQJI6UVKIb16xUYMpmyRMebsyyY0qzMU0FyvRv417YqoCuz2rJe+dAEvc5RldMn2Fp n2ZO6B1xw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lUA8Q-005HG7-3r; Wed, 07 Apr 2021 15:30:26 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lUA8L-005HFf-M4 for linux-arm-kernel@lists.infradead.org; Wed, 07 Apr 2021 15:30:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617809418; 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: in-reply-to:in-reply-to:references:references; bh=rHuby28rSVBEts9hw5b8nEC5zGAh17eoAFfYGcwxu7Q=; b=g2AgWffpn6TO+hohi/KwachzJcLKc8nwRf+xbuNds2r5tLGItbf5tJpit5VIF7oxb6MPR8 X4e2gC22ibsysWraW/OYUspBU0LY4j0j48ccQOjRHX/a0/yJVz2hHn9LIockHAjuARdSKJ OfqWPQzcDMMzR+v4pLFwg40rNvxm2Z0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-180-H2GLtm1WMquhgnK143jYrw-1; Wed, 07 Apr 2021 11:30:14 -0400 X-MC-Unique: H2GLtm1WMquhgnK143jYrw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 08789107ACF2; Wed, 7 Apr 2021 15:30:12 +0000 (UTC) Received: from [10.36.114.68] (ovpn-114-68.ams2.redhat.com [10.36.114.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1B45419C78; Wed, 7 Apr 2021 15:30:06 +0000 (UTC) To: Catalin Marinas , Steven Price Cc: Mark Rutland , Peter Maydell , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , qemu-devel@nongnu.org, Marc Zyngier , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , James Morse , linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com> <20210330103013.GD18075@arm.com> <8977120b-841d-4882-2472-6e403bc9c797@redhat.com> <20210331092109.GA21921@arm.com> <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com> <20210331184311.GA10737@arm.com> <20210407151458.GC21451@arm.com> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature Message-ID: <396423df-5c30-67f6-fcba-c041c08eef7e@redhat.com> Date: Wed, 7 Apr 2021 17:30:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210407151458.GC21451@arm.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210407_163021_952646_D713B4A0 X-CRM114-Status: GOOD ( 23.74 ) 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-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 07.04.21 17:14, Catalin Marinas wrote: > On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote: >> On 31/03/2021 19:43, Catalin Marinas wrote: >>> When a slot is added by the VMM, if it asked for MTE in guest (I guess >>> that's an opt-in by the VMM, haven't checked the other patches), can we >>> reject it if it's is going to be mapped as Normal Cacheable but it is a >>> ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to >>> check for ZONE_DEVICE)? This way we don't need to do more expensive >>> checks in set_pte_at(). >> >> The problem is that KVM allows the VMM to change the memory backing a slot >> while the guest is running. This is obviously useful for the likes of >> migration, but ultimately means that even if you were to do checks at the >> time of slot creation, you would need to repeat the checks at set_pte_at() >> time to ensure a mischievous VMM didn't swap the page for a problematic one. > > Does changing the slot require some KVM API call? Can we intercept it > and do the checks there? User space can simply mmap(MAP_FIXED) the user space area registered in a KVM memory slot. You cannot really intercept that. You can only check in the KVM MMU code at fault time that the VMA which you hold in your hands is still in a proper state. The KVM MMU is synchronous, which means that updates to the VMA layout are reflected in the KVM MMU page tables -- e.g., via mmu notifier calls. E.g., in s390x code we cannot handle VMAs with gigantic pages. We check that when faulting (creating the links in the page table) via __gmap_link(). You could either check the page itself (ZONE_DEVICE) or might even be able to check via the VMA/file. -- Thanks, David / dhildenb _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel