Re: [PATCH 15/52] fuse: map virtio_fs DAX window BAR

[Stefan Hajnoczi]

On Wed, Dec 12, 2018 at 05:37:35PM +0100, Christian Borntraeger wrote:
> 
> 
> On 10.12.2018 18:12, Vivek Goyal wrote:
> > From: Stefan Hajnoczi <stefanha@xxxxxxxxxx>
> 
> > +static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs)
> > +{
> > +	struct virtio_fs_memremap_info *mi;
> > +	struct dev_pagemap *pgmap;
> > +	struct pci_dev *pci_dev;
> > +	phys_addr_t phys_addr;
> > +	size_t len;
> > +	int ret;
> > +
> > +	if (!IS_ENABLED(CONFIG_DAX_DRIVER))
> > +		return 0;
> > +
> > +	/* HACK implement VIRTIO shared memory regions instead of
> > +	 * directly accessing the PCI BAR from a virtio device driver.
> > +	 */
> > +	pci_dev = container_of(vdev->dev.parent, struct pci_dev, dev);
> > +
> > +	/* TODO Is this safe - the virtio_pci_* driver doesn't use managed
> > +	 * device APIs? */
> > +	ret = pcim_enable_device(pci_dev);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	/* TODO handle case where device doesn't expose BAR? */
> > +	ret = pci_request_region(pci_dev, VIRTIO_FS_WINDOW_BAR,
> > +				 "virtio-fs-window");
> > +	if (ret < 0) {
> > +		dev_err(&vdev->dev, "%s: failed to request window BAR\n",
> > +			__func__);
> > +		return ret;
> > +	}
> 
> Can we please have a generic virtio interface to map the address (the default can then
> fall back to PCI) instead of mapping a PCI bar? This would make it easier to implement
> virtio-ccw or virtio-mmio.

Yes, we'll define shared memory as a device resource in the VIRTIO
specification.  It will become part of the device model, alongside
virtqueues, configuration space, etc.  That means devices can use shared
memory without it being tied to PCI BARs explicitly.

But only the PCI transport will have a realization of shared memory
resources in the beginning.  We need to work together to add this
feature to the ccw and mmio transports.

Stefan

Attachment: signature.asc
Description: PGP signature