Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp428422img; Wed, 20 Mar 2019 03:43:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqzLcvQxzL5nwHY2aESOKzhtgmOoPghnThuEN7ZvphbklATU4QPN9Tboxo4KKeDpDVuTYYvZ X-Received: by 2002:a63:5659:: with SMTP id g25mr6391931pgm.436.1553078625608; Wed, 20 Mar 2019 03:43:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553078625; cv=none; d=google.com; s=arc-20160816; b=TDTmrGcKEr8s3rAkjGaxEeabxy46d4gZvpXWONu4wk5g8JpMmHfIIRMxlhcC9M4Q5q 48w9aUW+fekpIPcrURgbA3oQx8ObYG2OHqbbXMFPKN9OCA9MCVwKoXOtJXbjTP/KI4Ej vgQcQJSTFZzXCyHL1tHulBTt2FBexyCOILxFwEXfGT+7lek82jGSqNDfqD0ilsL6lxyY FrzwWyp+nIiYIowcucQJzh3XUa2pWDkNuQQvVSHVmCJdpuUuSwT56pNMBnF892AKd1fT v12mLeV6RBKwHUWH1bmbwfHtbRirPDkJbkTR0lWF2l34UpCAQAK7Nq+bx2uzWd7ek+09 mPkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=eSuBByXHzSerM9KdpHKe0QgMi116hbzSLzAsS2bhSLQ=; b=va+ex6eNm8QbvOKHHDhS1ZiYXKrw/wcwsQP1qwWneub4SnooVzYo2icWEeQACpezKt 1wLRcKmW6EuP9wqR1QONM7Q+BlYJn2Bx2mEP0N6IBqCoEJWkrnqnCBDAwBz8p24RmEjB Ta6W2oB0Hj+GWLa01hPvowiQWr2G1I5wPogH5v4BH82bmaV5cwRnsssFFhGQf6Gy0SoJ 93a9n5Pc8q4llQNTjOw1f4bm7l9Bq8wUwSYArPDHOtmEVeB0q9uL5ptLVPZ7vI2UnqZs oEawjhmMDWIru9npH22UTgsXAvdkM35DIqWoxLJ5nWs83kufTt2E63fd6dTwlc672+Aa fEgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f5si1380931pgo.394.2019.03.20.03.43.30; Wed, 20 Mar 2019 03:43:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727598AbfCTKmx (ORCPT + 99 others); Wed, 20 Mar 2019 06:42:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53476 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727215AbfCTKmu (ORCPT ); Wed, 20 Mar 2019 06:42:50 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BC3692D7E4; Wed, 20 Mar 2019 10:42:49 +0000 (UTC) Received: from work-vm (unknown [10.36.118.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E2B7E5D9C4; Wed, 20 Mar 2019 10:42:45 +0000 (UTC) Date: Wed, 20 Mar 2019 10:42:43 +0000 From: "Dr. David Alan Gilbert" To: Liu Bo Cc: Vivek Goyal , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, miklos@szeredi.hu, Stefan Hajnoczi , sweil@redhat.com, swhiteho@redhat.com Subject: Re: [PATCH 18/52] virtio-fs: Map cache using the values from the capabilities Message-ID: <20190320104242.GC2791@work-vm> References: <20181210171318.16998-1-vgoyal@redhat.com> <20181210171318.16998-19-vgoyal@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 20 Mar 2019 10:42:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Liu Bo (obuil.liubo@gmail.com) wrote: > On Mon, Dec 10, 2018 at 9:57 AM Vivek Goyal wrote: > > > > Instead of assuming we had the fixed bar for the cache, use the > > value from the capabilities. > > > > Signed-off-by: Dr. David Alan Gilbert > > --- > > fs/fuse/virtio_fs.c | 32 +++++++++++++++++--------------- > > 1 file changed, 17 insertions(+), 15 deletions(-) > > > > diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c > > index 60d496c16841..55bac1465536 100644 > > --- a/fs/fuse/virtio_fs.c > > +++ b/fs/fuse/virtio_fs.c > > @@ -14,11 +14,6 @@ > > #include > > #include "fuse_i.h" > > > > -enum { > > - /* PCI BAR number of the virtio-fs DAX window */ > > - VIRTIO_FS_WINDOW_BAR = 2, > > -}; > > - > > /* List of virtio-fs device instances and a lock for the list */ > > static DEFINE_MUTEX(virtio_fs_mutex); > > static LIST_HEAD(virtio_fs_instances); > > @@ -518,7 +513,7 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs) > > struct dev_pagemap *pgmap; > > struct pci_dev *pci_dev; > > phys_addr_t phys_addr; > > - size_t len; > > + size_t bar_len; > > int ret; > > u8 have_cache, cache_bar; > > u64 cache_offset, cache_len; > > @@ -551,17 +546,13 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs) > > } > > > > /* TODO handle case where device doesn't expose BAR? */ > > - ret = pci_request_region(pci_dev, VIRTIO_FS_WINDOW_BAR, > > - "virtio-fs-window"); > > + ret = pci_request_region(pci_dev, cache_bar, "virtio-fs-window"); > > if (ret < 0) { > > dev_err(&vdev->dev, "%s: failed to request window BAR\n", > > __func__); > > return ret; > > } > > > > - phys_addr = pci_resource_start(pci_dev, VIRTIO_FS_WINDOW_BAR); > > - len = pci_resource_len(pci_dev, VIRTIO_FS_WINDOW_BAR); > > - > > mi = devm_kzalloc(&pci_dev->dev, sizeof(*mi), GFP_KERNEL); > > if (!mi) > > return -ENOMEM; > > @@ -586,6 +577,17 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs) > > pgmap->ref = &mi->ref; > > pgmap->type = MEMORY_DEVICE_FS_DAX; > > > > + phys_addr = pci_resource_start(pci_dev, cache_bar); > > + bar_len = pci_resource_len(pci_dev, cache_bar); > > + > > + if (cache_offset + cache_len > bar_len) { > > + dev_err(&vdev->dev, > > + "%s: cache bar shorter than cap offset+len\n", > > + __func__); > > + return -EINVAL; > > + } > > + phys_addr += cache_offset; > > + > > /* Ideally we would directly use the PCI BAR resource but > > * devm_memremap_pages() wants its own copy in pgmap. So > > * initialize a struct resource from scratch (only the start > > @@ -594,7 +596,7 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs) > > pgmap->res = (struct resource){ > > .name = "virtio-fs dax window", > > .start = phys_addr, > > - .end = phys_addr + len, > > + .end = phys_addr + cache_len, > > Just in case you haven't noticed/fixed this problem, it should be > > + .end = phys_addr + cache_len - 1, > > because resource_size() counts %size as "end - start + 1". > The end result of the above is a "conflicting page map" warning when > specifying a second virtio-fs pci device. Thanks for spotting this! I think we'd seen that message once but not noticed where from. > I'll send a patch for this, and feel free to take it along with the > patchset if needed. > Dave > thanks, > liubo > > > }; > > > > fs->window_kaddr = devm_memremap_pages(&pci_dev->dev, pgmap); > > @@ -607,10 +609,10 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs) > > return ret; > > > > fs->window_phys_addr = phys_addr; > > - fs->window_len = len; > > + fs->window_len = cache_len; > > > > - dev_dbg(&vdev->dev, "%s: window kaddr 0x%px phys_addr 0x%llx len %zu\n", > > - __func__, fs->window_kaddr, phys_addr, len); > > + dev_dbg(&vdev->dev, "%s: cache kaddr 0x%px phys_addr 0x%llx len %llx\n", > > + __func__, fs->window_kaddr, phys_addr, cache_len); > > > > fs->dax_dev = alloc_dax(fs, NULL, &virtio_fs_dax_ops); > > if (!fs->dax_dev) > > -- > > 2.13.6 > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK