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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 1BA0EC4338F for ; Wed, 18 Aug 2021 05:08:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DF9D36109E for ; Wed, 18 Aug 2021 05:08:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231976AbhHRFJM (ORCPT ); Wed, 18 Aug 2021 01:09:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231267AbhHRFJK (ORCPT ); Wed, 18 Aug 2021 01:09:10 -0400 Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5BA2DC061764 for ; Tue, 17 Aug 2021 22:08:36 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id s19so993305vsl.11 for ; Tue, 17 Aug 2021 22:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UnXThZRC3fAssEX0f0mLCZ6Q9w2tlCC2Smhk9kY/6CA=; b=gCuCVqPtp3VcrqtAtdQ9/T1hLISv/SoLG3FxW0WozJv9qF+VkP6lJy5+8o4RK3PHGe B/zhH0L3cY3+1C7tiCUx+apwtps1Hr63DN6B7vtkdtGE4R8dIUDR/DOrbruYk3WODqTS rS+LP7odFUxNB+5/Y04KwmguxE/ql3g3O/SRA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UnXThZRC3fAssEX0f0mLCZ6Q9w2tlCC2Smhk9kY/6CA=; b=P9Lbt9VG67ofdC9oECtNY2O9GozW9+1/fCSCM8BOglMfPjszWbuEpCfHj3nClCj2/V 57qM10W+fL23HH/26HocFC6PDoXiybjf1gbSyjczdV3FgOlwQeBTAmQhyDCuPubXI+LD Fs4ADM6hXdl/U0bu06y9f54SVIfKqt2SpMe76IlUkiluoFZWuUwqJ59+JvGdY1XVgqCZ 45H4AjpYMVPw/3afhg1pd4XydlHhJsvoPeft8DeMYko8RdcdR0i94wvKq2OldBIRgzif tNhp3iPZdfZ9YqJ6AlCzRzkCkHfo92ijll9DztcZXqdz4ypqk4qWi4W3srG2J0IjCSFZ PbNg== X-Gm-Message-State: AOAM531sB/cAFMCR4nzgc7/+VH2RT84x2Js+UMy8tfEChAoCM9hKwr2y czRUnH+Ju+jBtOUzfUd1sKGDwY9ZjgMPL4dX8k0SGrK0idE= X-Google-Smtp-Source: ABdhPJwwzsw1fw1YBDJLxjFxkuCGfq67iXSTVfBq6nF0q13DJIhPofNJc6jdv4S5vqn0kEPMQ9X7LN1beeitaFiS0Rw= X-Received: by 2002:a67:c009:: with SMTP id v9mr6217355vsi.47.1629263315510; Tue, 17 Aug 2021 22:08:35 -0700 (PDT) MIME-Version: 1.0 References: <20210817022220.17574-1-jefflexu@linux.alibaba.com> <6043c0b8-0ff1-2e11-0dd0-e23f9ff6b952@linux.alibaba.com> <1100b711-012d-d68b-7078-20eea6fa4bab@linux.alibaba.com> In-Reply-To: <1100b711-012d-d68b-7078-20eea6fa4bab@linux.alibaba.com> From: Miklos Szeredi Date: Wed, 18 Aug 2021 07:08:24 +0200 Message-ID: Subject: Re: [PATCH v4 0/8] fuse,virtiofs: support per-file DAX To: JeffleXu Cc: Vivek Goyal , Stefan Hajnoczi , linux-fsdevel@vger.kernel.org, virtualization@lists.linux-foundation.org, virtio-fs-list , Joseph Qi , Liu Bo Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, 18 Aug 2021 at 05:40, JeffleXu wrote: > I'm not sure if I fully understand your idea. Then in this case, host > daemon only prepares 4KB while guest thinks that the whole DAX window > (e.g., 2MB) has been fully mapped. Then when guest really accesses the > remained part (2MB - 4KB), page fault is triggered, and now host daemon > is responsible for downloading the remained part? Yes. Mapping an area just means setting up the page tables, it does not result in actual data transfer. Thanks, Miklos From mboxrd@z Thu Jan 1 00:00:00 1970 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UnXThZRC3fAssEX0f0mLCZ6Q9w2tlCC2Smhk9kY/6CA=; b=gCuCVqPtp3VcrqtAtdQ9/T1hLISv/SoLG3FxW0WozJv9qF+VkP6lJy5+8o4RK3PHGe B/zhH0L3cY3+1C7tiCUx+apwtps1Hr63DN6B7vtkdtGE4R8dIUDR/DOrbruYk3WODqTS rS+LP7odFUxNB+5/Y04KwmguxE/ql3g3O/SRA= MIME-Version: 1.0 References: <20210817022220.17574-1-jefflexu@linux.alibaba.com> <6043c0b8-0ff1-2e11-0dd0-e23f9ff6b952@linux.alibaba.com> <1100b711-012d-d68b-7078-20eea6fa4bab@linux.alibaba.com> In-Reply-To: <1100b711-012d-d68b-7078-20eea6fa4bab@linux.alibaba.com> From: Miklos Szeredi Date: Wed, 18 Aug 2021 07:08:24 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Virtio-fs] [PATCH v4 0/8] fuse,virtiofs: support per-file DAX List-Id: Development discussions about virtio-fs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: JeffleXu Cc: virtualization@lists.linux-foundation.org, virtio-fs-list , Joseph Qi , linux-fsdevel@vger.kernel.org, Vivek Goyal On Wed, 18 Aug 2021 at 05:40, JeffleXu wrote: > I'm not sure if I fully understand your idea. Then in this case, host > daemon only prepares 4KB while guest thinks that the whole DAX window > (e.g., 2MB) has been fully mapped. Then when guest really accesses the > remained part (2MB - 4KB), page fault is triggered, and now host daemon > is responsible for downloading the remained part? Yes. Mapping an area just means setting up the page tables, it does not result in actual data transfer. Thanks, Miklos