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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D73FC43334 for ; Fri, 8 Jul 2022 13:58:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238340AbiGHN6U (ORCPT ); Fri, 8 Jul 2022 09:58:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238288AbiGHN6T (ORCPT ); Fri, 8 Jul 2022 09:58:19 -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 ESMTP id 7531C2C640 for ; Fri, 8 Jul 2022 06:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657288696; 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: in-reply-to:in-reply-to:references:references; bh=DkINNwNj/wvMhz9e5/8WZEdU3d3i4BXmoSion7M+nwg=; b=IJ74h2yYZQIq80LWlxEiPjOdVIHUuFaZsMKFDSq886EjbuLdCIj0t/u4AP3IwUXii4AwW9 oQmx6TsKBSP4Cj5Zt34yV5xUhPOM5TVT34qaqtIKAnSgJZTzR2chQ41yh8OR5jZWqMLFkz xPAOMqV9uHTT1QJ+TTQsXSzryqF9g6w= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-669-4f3m1D48O16v5t6Q2FmGLQ-1; Fri, 08 Jul 2022 09:58:15 -0400 X-MC-Unique: 4f3m1D48O16v5t6Q2FmGLQ-1 Received: by mail-qt1-f199.google.com with SMTP id v4-20020ac873c4000000b0031ea1a9e8cfso3201435qtp.23 for ; Fri, 08 Jul 2022 06:58:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DkINNwNj/wvMhz9e5/8WZEdU3d3i4BXmoSion7M+nwg=; b=sgQQ427f1ts5BFOoJ+nwG7sidYxpUYAs+HR3yh5lwNjFCyJ/ADV1NzwrDLwOx/7XRl j6riXTZCvatiUAmWdvyRkVb9fu1rbh6P9CZDRiOFDQV7z/odG95LoAG/e/AGcNxTTUHw vQ/QmY+VfPYgNgdD0yVRHG6Y938njDVeTjFwXgjqPnPITX7OOyJOuHPxbkKNGLtoKB2M 8vBcJaObMGnydVg+/LAfnS088pgjkXgmKMqg1ZZNpFnvB9IkH8OuEvXNPvpQt/9tL3W5 t5osq3X0BJs2Jmil1krNjRVVSXE1PlFH99B/IUJX7EgXbjmnM1cLKQ25wAtbN+zsp+f0 v0ww== X-Gm-Message-State: AJIora8i8AS+N+ubN1x+YiYJkZpJ3iTSFRIvwlXXiQ4M2a3lOxCKhr4t GH9fAO+n46X83MoJTn6nXH3U1A8zajbU3Ohr7gL0vlMNfWUC9ghikWKl9pRBAOjfBi43lHXnnVh eaKXfry64GmhE X-Received: by 2002:a0c:dd11:0:b0:473:34ad:8e06 with SMTP id u17-20020a0cdd11000000b0047334ad8e06mr2839861qvk.4.1657288694404; Fri, 08 Jul 2022 06:58:14 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vxJv/NEyo15Tw1UQuhMw6BYWdDy7KEWS/QMrPgjBkRPoWXy9uvRkJMzNBM4QKpJ3PeU0utMg== X-Received: by 2002:a0c:dd11:0:b0:473:34ad:8e06 with SMTP id u17-20020a0cdd11000000b0047334ad8e06mr2839830qvk.4.1657288694053; Fri, 08 Jul 2022 06:58:14 -0700 (PDT) Received: from xz-m1.local (bras-base-aurron9127w-grc-37-74-12-30-48.dsl.bell.ca. [74.12.30.48]) by smtp.gmail.com with ESMTPSA id m14-20020a05620a24ce00b006af59e9ddeasm28327532qkn.18.2022.07.08.06.58.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Jul 2022 06:58:12 -0700 (PDT) Date: Fri, 8 Jul 2022 09:58:09 -0400 From: Peter Xu To: Cornelia Huck Cc: Steven Price , Catalin Marinas , Peter Collingbourne , kvmarm@lists.cs.columbia.edu, Marc Zyngier , kvm@vger.kernel.org, Andy Lutomirski , linux-arm-kernel@lists.infradead.org, Michael Roth , Chao Peng , Will Deacon , Evgenii Stepanov , Jean-Philippe Brucker , Gavin Shan , Eric Auger , "Dr. David Alan Gilbert" Subject: Re: [PATCH] KVM: arm64: permit MAP_SHARED mappings with MTE enabled Message-ID: References: <20220623234944.141869-1-pcc@google.com> <14f2a69e-4022-e463-1662-30032655e3d1@arm.com> <875ykmcd8q.fsf@redhat.com> <7a32fde7-611d-4649-2d74-f5e434497649@arm.com> <871qv12hqj.fsf@redhat.com> <87bktz7o49.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87bktz7o49.fsf@redhat.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Jul 08, 2022 at 03:03:34PM +0200, Cornelia Huck wrote: > On Mon, Jul 04 2022, Steven Price wrote: > > > On 04/07/2022 13:19, Cornelia Huck wrote: > >> On Mon, Jul 04 2022, Steven Price wrote: > >> > >>> On 29/06/2022 09:45, Catalin Marinas wrote: > >>>> On Mon, Jun 27, 2022 at 05:55:33PM +0200, Cornelia Huck wrote: > >>> > >>>>> [Postcopy needs a different interface, I guess, so that the migration > >>>>> target can atomically place a received page and its metadata. I see > >>>>> https://lore.kernel.org/all/CAJc+Z1FZxSYB_zJit4+0uTR-88VqQL+-01XNMSEfua-dXDy6Wg@mail.gmail.com/; > >>>>> has there been any follow-up?] > >>>> > >>>> I don't follow the qemu list, so I wasn't even aware of that thread. But > >>>> postcopy, the VMM needs to ensure that both the data and tags are up to > >>>> date before mapping such page into the guest address space. > >>>> > >>> > >>> I'm not sure I see how atomically updating data+tags is different from > >>> the existing issues around atomically updating the data. The VMM needs > >>> to ensure that the guest doesn't see the page before all the data+all > >>> the tags are written. It does mean lazy setting of the tags isn't > >>> possible in the VMM, but I'm not sure that's a worthwhile thing anyway. > >>> Perhaps I'm missing something? > >> > >> For postcopy, we basically want to fault in any not-yet-migrated page > >> via uffd once the guest accesses it. We only get the page data that way, > >> though, not the tag. I'm wondering whether we'd need a 'page+metadata' > >> uffd mode; not sure if that makes sense. Otherwise, we'd need to stop > >> the guest while grabbing the tags for the page as well, and stopping is > >> the thing we want to avoid here. > > > > Ah, I think I see now. UFFDIO_COPY atomically populates the (data) page > > and ensures that no thread will see the partially populated page. But > > there's currently no way of doing that with tags as well. > > Nod. > > > > > I'd not looked at the implementation of userfaultfd before and I'd > > assumed it avoided the need for an 'atomic' operation like this. But > > apparently not! AFAICT either a new ioctl would be needed (which can > > take a tag buffer) or a new flag to UFFDIO_COPY which would tighten the > > alignment requirements of `src` and would copy the tags along with the data. > > I was thinking about a new flag that implies "copy metadata"; not sure > how we would get the same atomicity with a separate ioctl. I've only > just started looking at userfaultfd, though, and I might be on a wrong > track... One thing I'd like to avoid is having something that is too > ARM-specific, I think there are other architecture features that might > have similar issues. Agreed, to propose such an interface we'd better make sure it'll be easily applicable to other similar memory protection mechanisms elsewhere. > > Maybe someone more familiar with uffd and/or postcopy can chime in? Hanving UFFDIO_COPY provide a new flag sounds reasonable to me. I'm curious what's the maximum possible size of the tags and whether they can be embeded already into struct uffdio_copy somehow. Thanks, -- Peter Xu 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 Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9957C433EF for ; Fri, 8 Jul 2022 13:58:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2274A4B5BD; Fri, 8 Jul 2022 09:58:23 -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 8X7VL-tAud0W; Fri, 8 Jul 2022 09:58:21 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A6D0740FD6; Fri, 8 Jul 2022 09:58:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A84364B765 for ; Fri, 8 Jul 2022 09:58:19 -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 VtSm7pxStYIz for ; Fri, 8 Jul 2022 09:58:18 -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 576164B736 for ; Fri, 8 Jul 2022 09:58:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657288698; 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: in-reply-to:in-reply-to:references:references; bh=DkINNwNj/wvMhz9e5/8WZEdU3d3i4BXmoSion7M+nwg=; b=Jrk0P2WhZsRj65XheLM9MApi7X2GAhQ4XGFGbDzkzF7eo9v+kx4JTSXKIAx8XmmAydsHCZ XPSgxF0v+1sX4mj+NXACcH0kP16zrUBUTe4MYPbhDQJdvtlLAMB8qN2z3cHPWuURwvGhyE CJyHsOUleEfsc9epm9K4DJhciZ5p3vo= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-296-rP_DfADkOJ2sDXu2R9Txgg-1; Fri, 08 Jul 2022 09:58:15 -0400 X-MC-Unique: rP_DfADkOJ2sDXu2R9Txgg-1 Received: by mail-qt1-f199.google.com with SMTP id f14-20020ac8068e000000b0031e899fabdcso9882477qth.5 for ; Fri, 08 Jul 2022 06:58:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DkINNwNj/wvMhz9e5/8WZEdU3d3i4BXmoSion7M+nwg=; b=WH5mp7E0jEr1mdHJ9unvr0riLpAnIfbTMWsD7xHsjKzz7x/LjsdoSu23sONTZ3a2vK NejwdGB6E4umSLHvV46F8LoyYvbE7dzkyzN0Tiy1YuYX3TKlUbDWAw+HLXPyMEI2YVjC UJwfTIXEuSb6JhQlcxUIvoWqBtw+3IsRO4S6zcRnyh9wDNQrn8Sz3Sukg6C/PdYTMvMU XdE1OFmGdQa1w4swJz+VAJehUxdeyZYcOyZBjh8ly49FrnQxs6sWe+B8JiMB/j75UBEr 7XCHlZN6X0tUMu2VtSlucEqhofljxiNIpqzxTf4WHh/nimQuFUjTTEp6cQ+QWolf48+A Mepw== X-Gm-Message-State: AJIora9oNtFsBEDNmAgVL+e4ZFtPioDHzBlG+Wc04zRoLiogNg4dR+6F bS/bw/8ZxOlfBiOL899/E1sqNmslQIn9uR/Ratw8tl+Ml/cLKdRrEDfeP5W7HB3Y+ANb7Rk+jgn s1q68RGeh+PinoAjBi8qlhBeE X-Received: by 2002:a0c:dd11:0:b0:473:34ad:8e06 with SMTP id u17-20020a0cdd11000000b0047334ad8e06mr2839866qvk.4.1657288694405; Fri, 08 Jul 2022 06:58:14 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vxJv/NEyo15Tw1UQuhMw6BYWdDy7KEWS/QMrPgjBkRPoWXy9uvRkJMzNBM4QKpJ3PeU0utMg== X-Received: by 2002:a0c:dd11:0:b0:473:34ad:8e06 with SMTP id u17-20020a0cdd11000000b0047334ad8e06mr2839830qvk.4.1657288694053; Fri, 08 Jul 2022 06:58:14 -0700 (PDT) Received: from xz-m1.local (bras-base-aurron9127w-grc-37-74-12-30-48.dsl.bell.ca. [74.12.30.48]) by smtp.gmail.com with ESMTPSA id m14-20020a05620a24ce00b006af59e9ddeasm28327532qkn.18.2022.07.08.06.58.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Jul 2022 06:58:12 -0700 (PDT) Date: Fri, 8 Jul 2022 09:58:09 -0400 From: Peter Xu To: Cornelia Huck Subject: Re: [PATCH] KVM: arm64: permit MAP_SHARED mappings with MTE enabled Message-ID: References: <20220623234944.141869-1-pcc@google.com> <14f2a69e-4022-e463-1662-30032655e3d1@arm.com> <875ykmcd8q.fsf@redhat.com> <7a32fde7-611d-4649-2d74-f5e434497649@arm.com> <871qv12hqj.fsf@redhat.com> <87bktz7o49.fsf@redhat.com> MIME-Version: 1.0 In-Reply-To: <87bktz7o49.fsf@redhat.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Cc: Jean-Philippe Brucker , kvm@vger.kernel.org, Catalin Marinas , "Dr. David Alan Gilbert" , Steven Price , Will Deacon , Evgenii Stepanov , Michael Roth , Marc Zyngier , Chao Peng , Andy Lutomirski , Peter Collingbourne , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Fri, Jul 08, 2022 at 03:03:34PM +0200, Cornelia Huck wrote: > On Mon, Jul 04 2022, Steven Price wrote: > > > On 04/07/2022 13:19, Cornelia Huck wrote: > >> On Mon, Jul 04 2022, Steven Price wrote: > >> > >>> On 29/06/2022 09:45, Catalin Marinas wrote: > >>>> On Mon, Jun 27, 2022 at 05:55:33PM +0200, Cornelia Huck wrote: > >>> > >>>>> [Postcopy needs a different interface, I guess, so that the migration > >>>>> target can atomically place a received page and its metadata. I see > >>>>> https://lore.kernel.org/all/CAJc+Z1FZxSYB_zJit4+0uTR-88VqQL+-01XNMSEfua-dXDy6Wg@mail.gmail.com/; > >>>>> has there been any follow-up?] > >>>> > >>>> I don't follow the qemu list, so I wasn't even aware of that thread. But > >>>> postcopy, the VMM needs to ensure that both the data and tags are up to > >>>> date before mapping such page into the guest address space. > >>>> > >>> > >>> I'm not sure I see how atomically updating data+tags is different from > >>> the existing issues around atomically updating the data. The VMM needs > >>> to ensure that the guest doesn't see the page before all the data+all > >>> the tags are written. It does mean lazy setting of the tags isn't > >>> possible in the VMM, but I'm not sure that's a worthwhile thing anyway. > >>> Perhaps I'm missing something? > >> > >> For postcopy, we basically want to fault in any not-yet-migrated page > >> via uffd once the guest accesses it. We only get the page data that way, > >> though, not the tag. I'm wondering whether we'd need a 'page+metadata' > >> uffd mode; not sure if that makes sense. Otherwise, we'd need to stop > >> the guest while grabbing the tags for the page as well, and stopping is > >> the thing we want to avoid here. > > > > Ah, I think I see now. UFFDIO_COPY atomically populates the (data) page > > and ensures that no thread will see the partially populated page. But > > there's currently no way of doing that with tags as well. > > Nod. > > > > > I'd not looked at the implementation of userfaultfd before and I'd > > assumed it avoided the need for an 'atomic' operation like this. But > > apparently not! AFAICT either a new ioctl would be needed (which can > > take a tag buffer) or a new flag to UFFDIO_COPY which would tighten the > > alignment requirements of `src` and would copy the tags along with the data. > > I was thinking about a new flag that implies "copy metadata"; not sure > how we would get the same atomicity with a separate ioctl. I've only > just started looking at userfaultfd, though, and I might be on a wrong > track... One thing I'd like to avoid is having something that is too > ARM-specific, I think there are other architecture features that might > have similar issues. Agreed, to propose such an interface we'd better make sure it'll be easily applicable to other similar memory protection mechanisms elsewhere. > > Maybe someone more familiar with uffd and/or postcopy can chime in? Hanving UFFDIO_COPY provide a new flag sounds reasonable to me. I'm curious what's the maximum possible size of the tags and whether they can be embeded already into struct uffdio_copy somehow. Thanks, -- Peter Xu _______________________________________________ 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 87542C43334 for ; Fri, 8 Jul 2022 13:59:21 +0000 (UTC) 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=qiyaKOrpMU2kYJUHAjTNwyC4WxKTIgAG+xqDW255EKc=; b=2foGLyIoxaU8J7 PNcH+Rnc4SnbrRm2d+B8KO9y5uvc2lNbNQB9XTKpHLavx3mPcMu7NgWNeBnNO6Lv0SAf+3pwVFPbe 667LJuhvCfhhYeGHbmFDBi29uo8Lip5cQMQnS69LE73FS8c+C7KIbgtcbrKpzyBRsdsy3RlBioFDE C9VoJUwzxrdzNK8aFwXxnNIrH/a7afSG5L0Kj6OLYNC8RUgjdYDykoJg1sZmIZlynWFK5aZTXHys4 UpZ83HH0J40sLaGNXAX1vSK++tntO0A+Wm40R/7fKkY8RBvH2i2TpTRpt3tZ79x4d5v7s/FBgcXrO kvN/cJkukgjh6dQBDSfw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9oUz-0041Yy-8A; Fri, 08 Jul 2022 13:58:25 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9oUv-0041Wm-CU for linux-arm-kernel@lists.infradead.org; Fri, 08 Jul 2022 13:58:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657288698; 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: in-reply-to:in-reply-to:references:references; bh=DkINNwNj/wvMhz9e5/8WZEdU3d3i4BXmoSion7M+nwg=; b=Jrk0P2WhZsRj65XheLM9MApi7X2GAhQ4XGFGbDzkzF7eo9v+kx4JTSXKIAx8XmmAydsHCZ XPSgxF0v+1sX4mj+NXACcH0kP16zrUBUTe4MYPbhDQJdvtlLAMB8qN2z3cHPWuURwvGhyE CJyHsOUleEfsc9epm9K4DJhciZ5p3vo= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-296-_3yb2RGTM5yiw2eWS83_VQ-1; Fri, 08 Jul 2022 09:58:15 -0400 X-MC-Unique: _3yb2RGTM5yiw2eWS83_VQ-1 Received: by mail-qt1-f199.google.com with SMTP id c22-20020ac81116000000b0031d25923ea8so17613560qtj.17 for ; Fri, 08 Jul 2022 06:58:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DkINNwNj/wvMhz9e5/8WZEdU3d3i4BXmoSion7M+nwg=; b=N8pZEWUVUzTXTvnh5K1tK8DqYUJ+7VBLzNapHln4y44rcbN8XfQS2lB5Ej78wlGWPd XHpzuqJ/MDXsXuN7MmtbkmLJx5U0BGcW9emXbl2cvRB87ZsSnz2JaMBqq4mOtjPET2V4 mvLwTcji4Vvoap/2w71pm14jXpMF5LCrgmHDba8V+cJ24qB/w88Pm1OVAbJ0/o+wEVAM GwqdJAzXPYOxd6fe9oYx91ZJer8zxpjCzKk+bUfuwi1rM0gWSQFGkUpe/DTNDlwGMbkZ hr8On5CEFhO8KH90kRlgcFOCcZu473fcFr4nJ0p9Zegm2FYz6KCIKZ1M8SZTOn4mfzbW VGDQ== X-Gm-Message-State: AJIora94OQlCBfTAwIdUPd6JsVaISVDBr1j7+B3hFrYcQT5O305OjvBx etKIqVbJgUqgQ9+0UFY4IXoAbkYYVcllnY9xxZEYvO1lVn56hUyMyd/2Th9576uiyljIAP0tkQ5 GJmP2nfb2VZhzoxdFyMDDfpuT4Sqgst3sbfo= X-Received: by 2002:a0c:dd11:0:b0:473:34ad:8e06 with SMTP id u17-20020a0cdd11000000b0047334ad8e06mr2839856qvk.4.1657288694404; Fri, 08 Jul 2022 06:58:14 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vxJv/NEyo15Tw1UQuhMw6BYWdDy7KEWS/QMrPgjBkRPoWXy9uvRkJMzNBM4QKpJ3PeU0utMg== X-Received: by 2002:a0c:dd11:0:b0:473:34ad:8e06 with SMTP id u17-20020a0cdd11000000b0047334ad8e06mr2839830qvk.4.1657288694053; Fri, 08 Jul 2022 06:58:14 -0700 (PDT) Received: from xz-m1.local (bras-base-aurron9127w-grc-37-74-12-30-48.dsl.bell.ca. [74.12.30.48]) by smtp.gmail.com with ESMTPSA id m14-20020a05620a24ce00b006af59e9ddeasm28327532qkn.18.2022.07.08.06.58.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Jul 2022 06:58:12 -0700 (PDT) Date: Fri, 8 Jul 2022 09:58:09 -0400 From: Peter Xu To: Cornelia Huck Cc: Steven Price , Catalin Marinas , Peter Collingbourne , kvmarm@lists.cs.columbia.edu, Marc Zyngier , kvm@vger.kernel.org, Andy Lutomirski , linux-arm-kernel@lists.infradead.org, Michael Roth , Chao Peng , Will Deacon , Evgenii Stepanov , Jean-Philippe Brucker , Gavin Shan , Eric Auger , "Dr. David Alan Gilbert" Subject: Re: [PATCH] KVM: arm64: permit MAP_SHARED mappings with MTE enabled Message-ID: References: <20220623234944.141869-1-pcc@google.com> <14f2a69e-4022-e463-1662-30032655e3d1@arm.com> <875ykmcd8q.fsf@redhat.com> <7a32fde7-611d-4649-2d74-f5e434497649@arm.com> <871qv12hqj.fsf@redhat.com> <87bktz7o49.fsf@redhat.com> MIME-Version: 1.0 In-Reply-To: <87bktz7o49.fsf@redhat.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220708_065821_572670_76CD9837 X-CRM114-Status: GOOD ( 31.59 ) 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 Fri, Jul 08, 2022 at 03:03:34PM +0200, Cornelia Huck wrote: > On Mon, Jul 04 2022, Steven Price wrote: > > > On 04/07/2022 13:19, Cornelia Huck wrote: > >> On Mon, Jul 04 2022, Steven Price wrote: > >> > >>> On 29/06/2022 09:45, Catalin Marinas wrote: > >>>> On Mon, Jun 27, 2022 at 05:55:33PM +0200, Cornelia Huck wrote: > >>> > >>>>> [Postcopy needs a different interface, I guess, so that the migration > >>>>> target can atomically place a received page and its metadata. I see > >>>>> https://lore.kernel.org/all/CAJc+Z1FZxSYB_zJit4+0uTR-88VqQL+-01XNMSEfua-dXDy6Wg@mail.gmail.com/; > >>>>> has there been any follow-up?] > >>>> > >>>> I don't follow the qemu list, so I wasn't even aware of that thread. But > >>>> postcopy, the VMM needs to ensure that both the data and tags are up to > >>>> date before mapping such page into the guest address space. > >>>> > >>> > >>> I'm not sure I see how atomically updating data+tags is different from > >>> the existing issues around atomically updating the data. The VMM needs > >>> to ensure that the guest doesn't see the page before all the data+all > >>> the tags are written. It does mean lazy setting of the tags isn't > >>> possible in the VMM, but I'm not sure that's a worthwhile thing anyway. > >>> Perhaps I'm missing something? > >> > >> For postcopy, we basically want to fault in any not-yet-migrated page > >> via uffd once the guest accesses it. We only get the page data that way, > >> though, not the tag. I'm wondering whether we'd need a 'page+metadata' > >> uffd mode; not sure if that makes sense. Otherwise, we'd need to stop > >> the guest while grabbing the tags for the page as well, and stopping is > >> the thing we want to avoid here. > > > > Ah, I think I see now. UFFDIO_COPY atomically populates the (data) page > > and ensures that no thread will see the partially populated page. But > > there's currently no way of doing that with tags as well. > > Nod. > > > > > I'd not looked at the implementation of userfaultfd before and I'd > > assumed it avoided the need for an 'atomic' operation like this. But > > apparently not! AFAICT either a new ioctl would be needed (which can > > take a tag buffer) or a new flag to UFFDIO_COPY which would tighten the > > alignment requirements of `src` and would copy the tags along with the data. > > I was thinking about a new flag that implies "copy metadata"; not sure > how we would get the same atomicity with a separate ioctl. I've only > just started looking at userfaultfd, though, and I might be on a wrong > track... One thing I'd like to avoid is having something that is too > ARM-specific, I think there are other architecture features that might > have similar issues. Agreed, to propose such an interface we'd better make sure it'll be easily applicable to other similar memory protection mechanisms elsewhere. > > Maybe someone more familiar with uffd and/or postcopy can chime in? Hanving UFFDIO_COPY provide a new flag sounds reasonable to me. I'm curious what's the maximum possible size of the tags and whether they can be embeded already into struct uffdio_copy somehow. Thanks, -- Peter Xu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel