From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:43446 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727754AbeLMJfJ (ORCPT ); Thu, 13 Dec 2018 04:35:09 -0500 Subject: Re: [PATCH 18/52] virtio-fs: Map cache using the values from the capabilities To: "Dr. David Alan Gilbert" Cc: Vivek Goyal , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, miklos@szeredi.hu, stefanha@redhat.com, sweil@redhat.com, swhiteho@redhat.com References: <20181210171318.16998-1-vgoyal@redhat.com> <20181210171318.16998-19-vgoyal@redhat.com> <20181213091320.GA2313@work-vm> From: David Hildenbrand Message-ID: Date: Thu, 13 Dec 2018 10:34:57 +0100 MIME-Version: 1.0 In-Reply-To: <20181213091320.GA2313@work-vm> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 13.12.18 10:13, Dr. David Alan Gilbert wrote: > * David Hildenbrand (david@redhat.com) wrote: >> On 10.12.18 18:12, 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? */ >> >> For virtio-pmem we decided to not go via BARs as this would effectively >> make it only usable for virtio-pci implementers. Instead, we are going >> to export the applicable physical device region directly (e.g. >> phys_start, phys_size in virtio config), so it is decoupled from PCI >> details. Doing the same for virtio-fs would allow e.g. also virtio-ccw >> to make eventually use of this. > > That makes it a very odd looking PCI device; I can see that with > virtio-pmem it makes some sense, given that it's job is to expose > arbitrary chunks of memory. > > Dave Well, the fact that your are - including - adding pci related code in/to fs/fuse/virtio_fs.c tells me that these properties might be better communicated on the virtio layer, not on the PCI layer. Or do you really want to glue virtio-fs to virtio-pci for all eternity? -- Thanks, David / dhildenb