On Thu, Mar 20, 2008 at 05:25:26PM +0100, Carsten Otte wrote:
> @@ -143,6 +143,10 @@ static noinline __init void detect_machi
> /* Running on a P/390 ? */
> if (cpuinfo->cpu_id.machine == 0x7490)
> machine_flags |= 4;
> +
> + /* Running under KVM ? */
> + if (cpuin
On Thu, Mar 20, 2008 at 09:37:19PM +0100, Carsten Otte wrote:
> Christoph Hellwig wrote:
>> On Thu, Mar 20, 2008 at 05:25:26PM +0100, Carsten Otte wrote:
>>> @@ -143,6 +143,10 @@ static noinline __init void detect_machi
>>> /* Running on a P/390 ? */
>>
On Thu, Aug 06, 2009 at 12:45:50PM +0100, Alasdair G Kergon wrote:
> On Thu, Aug 06, 2009 at 12:14:17PM +0100, Mark McLoughlin wrote:
> > We should error all barriers, even empty barriers, on devices like
> > virtio_blk which don't support them.
>
> Have you considered whether or not virtio_blk a
On Fri, Mar 16, 2007 at 10:26:55AM -0700, Jeremy Fitzhardinge wrote:
> +#ifdef CONFIG_HIGHPTE
> + .kmap_atomic_pte = native_kmap_atomic_pte,
> +#else
> + .kmap_atomic_pte = paravirt_nop,
> +#endif
This is ifdefing is quite ugly. Shouldn't native_kmap_atomic_pte
just be a noop in the !CONF
On Sun, Apr 29, 2007 at 10:29:02AM -0700, Jeremy Fitzhardinge wrote:
> +#include
not needed.
> +#include
> +#include
> +#include
> +#ifdef CONFIG_XEN_BALLOON
> +#include
> +#endif
> +#include
Please don't try to put such a fucked up include hierachy in.
Just move everything under include/x
> source "drivers/s390/block/Kconfig"
> +source "drivers/block/xen/Kconfig"
Please don't add a new subdirectory for a tiny new driver that
really should be only a single .c file.
> +config XEN_BLKDEV_FRONTEND
> + tristate "Block device frontend driver"
> + depends on XEN
> + default
On Fri, May 04, 2007 at 04:21:16PM -0700, Jeremy Fitzhardinge wrote:
> +/*
> + * Mutually-exclusive module options to select receive data path:
> + * rx_copy : Packets are copied by network backend into local memory
> + * rx_flip : Page containing packet data is transferred to our ownership
> + *
On Thu, May 10, 2007 at 01:14:55AM +1000, Rusty Russell wrote:
> > > + info->peer = (void *)ioremap(info->peer_phys, info->mapsize);
> >
> > check for NULL
>
> Erk, good catch!
Also the cast is bogus. ioremap already returns void already. Even
more importantly the lack of the __iomem annotatio
On Fri, May 11, 2007 at 11:17:26AM +1000, Rusty Russell wrote:
> - But the cost was high: lots of __force casts 8(
That sounds like something is very fishy.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linu
On Fri, May 11, 2007 at 11:21:30AM +1000, Rusty Russell wrote:
> 1) send-dma and bind-dma hypercall wrappers for drivers to use,
> 2) formalization of the convention that devices can use the irq
>corresponding to their index on the lguest_bus.
> 3) ___force to shut up sparse: guests *can* use i
On Fri, May 11, 2007 at 05:31:06PM +1000, Rusty Russell wrote:
> Well, without ioremap, the memory wouldn't normally be mapped. Is
> there something better to use?
Either use accessors or use your own lguest-specific remapping function that
doesn't return __iomem function
> > So instead of
On Mon, Jun 25, 2007 at 10:26:37AM -0500, Brian King wrote:
> 1. The add_inbuf interface passes an sg list. This causes problems for
>ibmveth since its rx buffers cannot be scatterlists.
> 2. The user of this API does not have access to the sk_buf. This causes
>issues for ibmveth since it n
As said before, please don't try to do weird runtime checks based
on the scatterlist. What you have works for now, but there are
plans to repalce the page + offset tuple in the scatterlist with
just a phys_addr_t. And with that your "clever" scheme will break
instantly.
__
ameter from GUP altogether.
>
> Acked-by: David Hildenbrand
> Acked-by: Dennis Dalessandro (for
> qib)
> Signed-off-by: Lorenzo Stoakes
Looks good:
Reviewed-by: Christoph Hellwig
___
Virtualization mailing list
Virtualization@li
On Wed, May 17, 2023 at 10:54:23AM +0800, zhenwei pi wrote:
> All the vring based virtqueue methods could be abstratct in theory,
> MST suggested that add/get bufs and kick functions are quite perfmance
> sensitive, so export these functions from virtio_ring.ko, drivers
> still call them in a fast
On Wed, May 17, 2023 at 03:43:03PM +0800, zhenwei pi wrote:
> I have a plan to introduce 'Virtio Over Fabrics'(TCP&RDMA) as Virtio
> transport, as mentioned in cover letter of this series:
> 3 weeks ago, I posted a proposal 'Virtio Over Fabrics':
> https://lists.oasis-open.org/archives/virtio-comme
On Wed, May 17, 2023 at 10:22:38AM +0800, Xuan Zhuo wrote:
> -static dma_addr_t vring_map_one_sg(const struct vring_virtqueue *vq,
> -struct scatterlist *sg,
> -enum dma_data_direction direction)
> +static int vring_map_one_sg(const st
On Wed, May 17, 2023 at 10:22:41AM +0800, Xuan Zhuo wrote:
> virtuque_add() adds parameter premapped.
Well, I can see that. But why?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/lis
On Mon, Jun 05, 2023 at 09:58:21AM +0800, Xuan Zhuo wrote:
> On Fri, 2 Jun 2023 23:29:02 -0700, Jakub Kicinski wrote:
> > On Fri, 2 Jun 2023 17:21:56 +0800 Xuan Zhuo wrote:
> > > Thanks for the help from Christoph.
> >
> > That said you haven't CCed him on the series, isn't the general rule to
>
I think the proper minimal fix is to pass in a REQ_WRITE in addition to
REQ_PREFLUSH. We can than have a discussion on the merits of this
weird async pmem flush scheme separately.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
Please avoid the overly long line. With that fixe this looks good
to me.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Looks good:
Reviewed-by: Christoph Hellwig
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Wed, Jul 12, 2023 at 10:28:00AM +0200, Stefano Garzarella wrote:
> The problem is that the SCSI stack does not send this command, so we
> should do it in the driver. In fact we do it for
> VIRTIO_SCSI_EVT_RESET_RESCAN (hotplug), but not for
> VIRTIO_SCSI_EVT_RESET_REMOVED (hotunplug).
No, you s
On Mon, Jul 10, 2023 at 11:42:30AM +0800, Xuan Zhuo wrote:
> This helper allows the driver change the dma mode to premapped mode.
> Under the premapped mode, the virtio core do not do dma mapping
> internally.
>
> This just work when the use_dma_api is true. If the use_dma_api is false,
> the dma
On Mon, Jul 10, 2023 at 11:42:32AM +0800, Xuan Zhuo wrote:
> Added virtqueue_dma_dev() to get DMA device for virtio. Then the
> caller can do dma operation in advance. The purpose is to keep memory
> mapped across multiple add/get buf operations.
This is just poking holes into the abstraction..
_
On Thu, Jul 13, 2023 at 10:47:23AM -0400, Michael S. Tsirkin wrote:
> There are a gazillion virtio drivers and most of them just use the
> virtio API, without bothering with these micro-optimizations. virtio
> already tracks addresses so mapping/unmapping them for DMA is easier
> done in the core.
Hi Jason,
can you please resend your reply with proper quoting? I had to give
up after multiple pages of scrolling without finding anything that
you added to the full quote.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
http
On Thu, Jul 13, 2023 at 10:51:59AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 13, 2023 at 04:15:16AM -0700, Christoph Hellwig wrote:
> > On Mon, Jul 10, 2023 at 11:42:32AM +0800, Xuan Zhuo wrote:
> > > Added virtqueue_dma_dev() to get DMA device for virtio. Then the
>
On Thu, Jul 20, 2023 at 02:45:14PM +0800, Xuan Zhuo wrote:
> virtqueue_dma_dev() return the device that working with the DMA APIs.
> Then that can be used like other devices. So what is the problem.
>
> I always think the code path without the DMA APIs is the trouble for you.
Because we now ha
On Thu, Jul 20, 2023 at 03:41:56PM +0800, Jason Wang wrote:
> > Did you actually check that it works though?
> > Looks like with swiotlb you need to synch to trigger a copy
> > before unmap, and I don't see where it's done in the current
> > patch.
>
> And this is needed for XDP_REDIRECT as well.
On Thu, Jul 20, 2023 at 01:21:07PM -0400, Michael S. Tsirkin wrote:
> Well I think we can add wrappers like virtio_dma_sync and so on.
> There are NOP for non-dma so passing the dma device is harmless.
Yes, please.
___
Virtualization mailing list
Virtual
On Tue, Sep 26, 2023 at 07:41:44AM -0400, Michael S. Tsirkin wrote:
>
> Except, there's no reasonable way for virtio to know what is done with
> the device then. You are not using just 2 symbols at all, instead you
> are using the rich vq API which was explicitly designed for the driver
> running
On Mon, Oct 02, 2023 at 12:13:20PM -0300, Jason Gunthorpe wrote:
> ??? This patch series is an implementation of changes that OASIS
> approved.
I think you are fundamentally missing my point. This is not about
who publish a spec, but how we struture Linux code.
And the problem is that we trea vf
On Thu, Oct 05, 2023 at 08:10:04AM -0300, Jason Gunthorpe wrote:
> > But for all the augmented vfio use cases it doesn't, for them the
> > augmented vfio functionality is an integral part of the core driver.
> > That is true for nvme, virtio and I'd argue mlx5 as well.
>
> I don't agree with this.
On Tue, Oct 10, 2023 at 06:43:32PM +0300, Yishai Hadas wrote:
> > I suggest 3 but call it on the VF. commands will switch to PF
> > internally as needed. For example, intel might be interested in exposing
> > admin commands through a memory BAR of VF itself.
> >
> The driver who owns the VF is VFI
On Tue, Oct 10, 2023 at 12:59:37PM -0300, Jason Gunthorpe wrote:
> On Tue, Oct 10, 2023 at 11:14:56AM -0400, Michael S. Tsirkin wrote:
>
> > I suggest 3 but call it on the VF. commands will switch to PF
> > internally as needed. For example, intel might be interested in exposing
> > admin commands
On Tue, Oct 10, 2023 at 10:10:31AM -0300, Jason Gunthorpe wrote:
> We've talked around ideas like allowing the VF config space to do some
> of the work. For simple devices we could get away with 1 VF config
> space register. (VF config space is owned by the hypervisor, not the
> guest)
Which assum
On Wed, Oct 11, 2023 at 02:43:37AM -0400, Michael S. Tsirkin wrote:
> > Btw, what is that intel thing everyone is talking about? And why
> > would the virtio core support vendor specific behavior like that?
>
> It's not a thing it's Zhu Lingshan :) intel is just one of the vendors
> that implemen
On Wed, Oct 11, 2023 at 10:57:09AM -0300, Jason Gunthorpe wrote:
> > Independent of my above points on the doubts on VF-controlled live
> > migration for PCe device I absolutely agree with your that the Linux
> > abstraction and user interface should be VF based. Which further
> > reinforeces my p
eed to check it and remove the iommu parameter everywhere.
Yes, that's much better than exposing the iommu ops to a place that
should not care about them:
Acked-by: Christoph Hellwig
___
Virtualization mailing list
Virtualization@lists.linux-fou
Just as last time: This does not make any sense. ioremap is shared
by definition.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Tue, Oct 05, 2021 at 06:42:43AM -0400, Michael S. Tsirkin wrote:
> Stefan also pointed out this duplicates the logic from
>
> if (blksize < 512 || blksize > PAGE_SIZE || !is_power_of_2(blksize))
> return -EINVAL;
>
>
> and a bunch of other places.
>
>
> Would it be
On Mon, Oct 11, 2021 at 03:09:09PM -0400, Michael S. Tsirkin wrote:
> The reason we have trouble is that it's not clear what does the API mean
> outside the realm of TDX.
> If we really, truly want an API that says "ioremap and it's a hardened
> driver" then I guess ioremap_hardened_driver is what
The whole series looks good to me:
Reviewed-by: Christoph Hellwig
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
CONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it.
Signed-off-by: Christoph Hellwig
---
drivers/dax/Kconfig| 4
drivers/nvdimm/Kconfig | 2 +-
drivers/s390/block/Kconfig | 2 +-
fs/fuse/Kconfig| 2 +-
4 files changed, 3 insertions(+), 7 deletions(-)
diff
Hi Dan,
this series cleans up and simplifies the association between DAX and block
devices in preparation of allowing to mount file systems directly on DAX
devices without a detour through block devices.
Diffstat:
drivers/dax/Kconfig |4
drivers/dax/bus.c|2
driver
The device mapper DAX support is all hanging off a block device and thus
can't be used with device dax. Make it depend on CONFIG_FS_DAX instead
of CONFIG_DAX_DRIVER. This also means that bdev_dax_pgoff only needs to
be built under CONFIG_FS_DAX now.
Signed-off-by: Christoph He
Drivers that register a dax_dev should make sure it works, no need
to double check from the file system.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 49 +
1 file changed, 1 insertion(+), 48 deletions(-)
diff --git a/drivers/dax/super.c
fs_dax_get_by_bdev is the primary interface to find a dax device for a
block device, so move the partition alignment check there instead of
wiring it up through ->dax_supported.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 23 ++-
1 file changed, 6 inserti
Replace the dax_host_hash with an xarray indexed by the pointer value
of the gendisk, and require explicitl calls from the block drivers that
want to associate their gendisk with a dax_device.
Signed-off-by: Christoph Hellwig
---
drivers/dax/bus.c| 2 +-
drivers/dax/super.c
Add a helper to perform the entire remapping for DAX accesses. This
helper open codes bdev_dax_pgoff given that the alignment checks have
already been done by the submitting file system and don't need to be
repeated.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-linear.c
Just open code the block size and dax_dev == NULL checks in the callers.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 36
drivers/md/dm-table.c| 22 +++---
drivers/md/dm.c | 21
Factor out another DAX setup helper to simplify future changes. Also
move the experimental warning after the checks to not clutter the log
too much if the setup failed.
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_super.c | 47 +++---
1 file changed
Add a helper to perform the entire remapping for DAX accesses. This
helper open codes bdev_dax_pgoff given that the alignment checks have
already been done by the submitting file system and don't need to be
repeated.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-log-writes.c
Add a helper to perform the entire remapping for DAX accesses. This
helper open codes bdev_dax_pgoff given that the alignment checks have
already been done by the submitting file system and don't need to be
repeated.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm-stripe.c
No functional changet, but this will allow for a tighter integration
with the iomap code, including possible passing the partition offset
in the iomap in the future. For now it mostly avoids growing more
callers outside of fs/dax.c.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 14
On Mon, Oct 18, 2021 at 09:43:51AM -0700, Darrick J. Wong wrote:
> > --- a/fs/xfs/xfs_super.c
> > +++ b/fs/xfs/xfs_super.c
> > @@ -339,6 +339,32 @@ xfs_buftarg_is_dax(
> > bdev_nr_sectors(bt->bt_bdev));
> > }
> >
> > +static int
> > +xfs_setup_dax(
>
> /me wonders if this sh
On Mon, Oct 25, 2021 at 11:24:57AM +0300, Max Gurtovoy wrote:
> Maybe we can compare the returned status to BLK_STS_OK. But I see we don't
> do it also in NVMe subsystem so I guess we can assume BLK_STS_OK == 0
> forever.
Jes, BLK_STS_OK == 0 is an intentional allowed short cut. It is not
just
On Wed, Nov 03, 2021 at 12:59:31PM -0500, Eric Sandeen wrote:
> Christoph, can I ask what the end game looks like, here? If dax is completely
> decoupled from block devices, are there user-visible changes?
Yes.
> If I want to
> run fs-dax on a pmem device - what do I point mkfs at, if not a block
On Thu, Nov 04, 2021 at 10:34:17AM -0700, Darrick J. Wong wrote:
> /me wonders, are block devices going away? Will mkfs.xfs have to learn
> how to talk to certain chardevs? I guess jffs2 and others already do
> that kind of thing... but I suppose I can wait for the real draft to
> show up to ramb
Hi Dan,
this series decouples the DAX from the block layer so that the
block_device is not needed at all for the DAX I/O path.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/vi
The device mapper DAX support is all hanging off a block device and thus
can't be used with device dax. Make it depend on CONFIG_FS_DAX instead
of CONFIG_DAX_DRIVER. This also means that bdev_dax_pgoff only needs to
be built under CONFIG_FS_DAX now.
Signed-off-by: Christoph He
Drivers that register a dax_dev should make sure it works, no need
to double check from the file system.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 49 +
1 file changed, 1 insertion(+), 48 deletions(-)
diff --git a/drivers/dax/super.c
CONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it.
Signed-off-by: Christoph Hellwig
---
drivers/dax/Kconfig| 4
drivers/nvdimm/Kconfig | 2 +-
drivers/s390/block/Kconfig | 2 +-
fs/fuse/Kconfig| 2 +-
4 files changed, 3 insertions(+), 7 deletions(-)
diff
dax_attribute_group is only used by the pmem driver, and can avoid the
completely pointless lookup by the disk name if moved there. This
leaves just a single caller of dax_get_by_host, so move dax_get_by_host
into the same ifdef block as that caller.
Signed-off-by: Christoph Hellwig
Reviewed-by
fs_dax_get_by_bdev is the primary interface to find a dax device for a
block device, so move the partition alignment check there instead of
wiring it up through ->dax_supported.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 23 ++-
1 file changed, 6 inserti
Factor out another DAX setup helper to simplify future changes. Also
move the experimental warning after the checks to not clutter the log
too much if the setup failed.
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_super.c | 47 +++---
1 file changed
Replace the dax_host_hash with an xarray indexed by the pointer value
of the gendisk, and require explicitly calls from the block drivers that
want to associate their gendisk with a dax_device.
Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
---
drivers/dax/bus.c| 6
Add a helper to perform the entire remapping for DAX accesses. This
helper open codes bdev_dax_pgoff given that the alignment checks have
already been done by the submitting file system and don't need to be
repeated.
Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
---
drivers/
Just pass the vm_fault and iomap_iter structures, and figure out the rest
locally. Note that this requires moving dax_iomap_sector up in the file.
Signed-off-by: Christoph Hellwig
---
fs/dax.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a
Just open code the block size and dax_dev == NULL checks in the callers.
Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
---
drivers/dax/super.c | 36
drivers/md/dm-table.c| 22 +++---
drivers/md/dm.c
Add a helper to perform the entire remapping for DAX accesses. This
helper open codes bdev_dax_pgoff given that the alignment checks have
already been done by the submitting file system and don't need to be
repeated.
Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
---
drivers/
Despite its name copy_user_page expected kernel addresses, which is what
we already have.
Signed-off-by: Christoph Hellwig
---
fs/dax.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/dax.c b/fs/dax.c
index 4e3e5a283a916..73bd1439d8089 100644
--- a/fs/dax.c
+++ b/fs/dax.c
The file relative offset must have the same alignment as the storage
offset, so use that and get rid of the call to iomap_sector.
Signed-off-by: Christoph Hellwig
---
fs/dax.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 5364549d67a48
Add a helper to perform the entire remapping for DAX accesses. This
helper open codes bdev_dax_pgoff given that the alignment checks have
already been done by the submitting file system and don't need to be
repeated.
Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
---
drivers/
for reflink support as well.
Signed-off-by: Christoph Hellwig
---
fs/dax.c | 77 ++
fs/ext2/inode.c| 6 ++--
fs/ext4/inode.c| 4 +--
fs/iomap/buffered-io.c | 35 +++
fs/xfs/xfs_iomap.c | 6
include
Replace the two steps of dax_iomap_sector and bdev_dax_pgoff with a
single dax_iomap_pgoff helper that avoids lots of cumbersome sector
conversions.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 14 --
fs/dax.c| 35
From: Shiyang Ruan
Add helpers to prepare for using different DAX operations.
Signed-off-by: Shiyang Ruan
[hch: split from a larger patch + slight cleanups]
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_bmap_util.c | 7 +++
fs/xfs/xfs_file.c | 3 +--
fs/xfs/xfs_iomap.c | 25
Hide the DAX device lookup from the xfs_super.c code.
Reviewed-by: Christoph Hellwig
---
fs/xfs/xfs_buf.c | 8
fs/xfs/xfs_buf.h | 4 ++--
fs/xfs/xfs_super.c | 26 +-
3 files changed, 11 insertions(+), 27 deletions(-)
diff --git a/fs/xfs/xfs_buf.c b/fs/xfs
Only call fs_dax_get_by_bdev once the sbi has been allocated and remove
the need for the dax_dev local variable.
Signed-off-by: Christoph Hellwig
---
fs/ext4/super.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index eb4df43abd76e
Add a flag so that the file system can easily detect DAX operations.
Signed-off-by: Christoph Hellwig
---
fs/dax.c | 7 ---
include/linux/iomap.h | 1 +
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 5b52b878124ac..0bd6cdcbacfc4 100644
Only call fs_dax_get_by_bdev once the sbi has been allocated and remove
the need for the dax_dev local variable.
Signed-off-by: Christoph Hellwig
---
fs/ext2/super.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index
While the buffered write iomap ops do work due to the fact that zeroing
never allocates blocks, the DAX zeroing should use the direct ops just
like actual DAX I/O.
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_iomap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs
Factor out a helper for the "manual" zeroing of a DAX range to clean
up dax_iomap_zero a lot.
Signed-off-by: Christoph Hellwig
---
fs/dax.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index d7a
Prepare from removing the block_device from the DAX I/O path by returning
the partition offset from fs_dax_get_by_bdev so that the file systems
have it at hand for use during I/O.
Signed-off-by: Christoph Hellwig
---
drivers/dax/super.c | 9 ++---
drivers/md/dm.c | 4 ++--
fs/erofs
Use the explicit DAX flag instead of checking the inode flag in the
iomap code.
Signed-off-by: Christoph Hellwig
---
fs/xfs/xfs_iomap.c | 7 ---
fs/xfs/xfs_iomap.h | 3 ++-
fs/xfs/xfs_pnfs.c | 2 +-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs
Only build the block based iomap code if CONFIG_BLOCK is set. Currently
that is always the case, but it will change soon.
Signed-off-by: Christoph Hellwig
---
fs/Kconfig| 4 ++--
fs/iomap/Makefile | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/Kconfig b/fs
The file system DAX code now does not require the block code. So allow
building a kernel with fuse DAX but not block layer.
Signed-off-by: Christoph Hellwig
---
fs/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/Kconfig b/fs/Kconfig
index 6d608330a096e
Remove the last user of ->bdev in dax.c by requiring the file system to
pass in an address that already includes the DAX offset. As part of the
only set ->bdev or ->daxdev when actually required in the ->iomap_begin
methods.
Signed-off-by: Christoph Hellwig
---
fs/dax.c
The DAX device <-> block device association is only enabled if
CONFIG_BLOCK is enabled. Update dax.h to account for that and use
the right conditions for the fs_put_dax stub as well.
Signed-off-by: Christoph Hellwig
---
include/linux/dax.h | 41 -
On Wed, Nov 17, 2021 at 09:23:44AM -0800, Dan Williams wrote:
> Applied, fixed the spelling of 'dependent' in the subject and picked
> up Mike's Ack from the previous send:
>
> https://lore.kernel.org/r/yyasbvuorceds...@redhat.com
>
> Christoph, any particular reason you did not pick up the tags
On Wed, Nov 17, 2021 at 09:44:25AM -0800, Dan Williams wrote:
> On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
> >
> > dax_attribute_group is only used by the pmem driver, and can avoid the
> > completely pointless lookup by the disk name if moved there. This
>
On Mon, Nov 22, 2021 at 06:54:09PM -0800, Dan Williams wrote:
> On Thu, Nov 18, 2021 at 10:55 PM Christoph Hellwig wrote:
> >
> > On Wed, Nov 17, 2021 at 09:23:44AM -0800, Dan Williams wrote:
> > > Applied, fixed the spelling of 'dependent' in the subject and p
On Mon, Nov 22, 2021 at 07:33:06PM -0800, Dan Williams wrote:
> Is it time to add a "DAX" symbol namespace?
What would be the benefit?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/lis
On Tue, Nov 23, 2021 at 02:25:55PM -0800, Darrick J. Wong wrote:
> > + if ((get_start_sect(bdev) * SECTOR_SIZE) % PAGE_SIZE ||
> > + (bdev_nr_sectors(bdev) * SECTOR_SIZE) % PAGE_SIZE) {
>
> Do we have to be careful about 64-bit division here, or do we not
> support DAX on 32-bit?
I can't
On Tue, Nov 23, 2021 at 02:31:23PM -0800, Darrick J. Wong wrote:
> > - struct super_block *sb = mp->m_super;
> > -
> > - if (!xfs_buftarg_is_dax(sb, mp->m_ddev_targp) &&
> > - (!mp->m_rtdev_targp || !xfs_buftarg_is_dax(sb, mp->m_rtdev_targp))) {
> > + if (!mp->m_ddev_targp->bt_daxde
On Tue, Nov 23, 2021 at 02:36:42PM -0800, Darrick J. Wong wrote:
> > - phys_addr_t phys_off = (start_sect + sector) * 512;
> > -
> > - if (pgoff)
> > - *pgoff = PHYS_PFN(phys_off);
> > - if (phys_off % PAGE_SIZE || size % PAGE_SIZE)
>
> AFAICT, we're relying on fs_dax_get_by_bdev t
On Tue, Nov 23, 2021 at 01:22:13PM -0800, Dan Williams wrote:
> On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
> >
> > Factor out a helper for the "manual" zeroing of a DAX range to clean
> > up dax_iomap_zero a lot.
> >
>
>
On Tue, Nov 23, 2021 at 01:46:35PM -0800, Dan Williams wrote:
> > + const struct iomap_ops *ops)
> > +{
> > + unsigned int blocksize = i_blocksize(inode);
> > + unsigned int off = pos & (blocksize - 1);
> > +
> > + /* Block boundary? Nothing to do */
> > + if (
On Tue, Nov 23, 2021 at 02:53:15PM -0800, Darrick J. Wong wrote:
> > -s64 dax_iomap_zero(loff_t pos, u64 length, struct iomap *iomap)
> > +static loff_t dax_zero_iter(struct iomap_iter *iter, bool *did_zero)
>
> Shouldn't this return value remain s64 to match iomap_iter.processed?
I'll switch it
1 - 100 of 935 matches
Mail list logo
