search for: read_iter

..._set_rw_locked(struct kiocb *iocb, int level) /* * Using a named enum representing lock types in terms of #N bit stored in * iocb->private, which is going to be used for communication between - * ocfs2_dio_end_io() and ocfs2_file_aio_write/read(). + * ocfs2_dio_end_io() and ocfs2_file_write/read_iter(). */ enum ocfs2_iocb_lock_bits { OCFS2_IOCB_RW_LOCK = 0, diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c index 41000f2..d2d203b 100644 --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -2220,15 +2220,13 @@ out: return ret; } -static ssize_t ocfs2_file_aio_write(struct kiocb *iocb, - c...

..._set_rw_locked(struct kiocb *iocb, int level) /* * Using a named enum representing lock types in terms of #N bit stored in * iocb->private, which is going to be used for communication between - * ocfs2_dio_end_io() and ocfs2_file_aio_write/read(). + * ocfs2_dio_end_io() and ocfs2_file_write/read_iter(). */ enum ocfs2_iocb_lock_bits { OCFS2_IOCB_RW_LOCK = 0, diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c index 37d313e..94fc309 100644 --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -2219,15 +2219,13 @@ out: return ret; } -static ssize_t ocfs2_file_aio_write(struct kiocb *iocb, - c...

...>? device if the feature is acked >>>>- implements VHOST_GET_BACKEND_FEATURES and >>>>? VHOST_SET_BACKEND_FEATURES ioctls >>>>- calls vq_meta_prefetch() before vq processing to prefetch vq >>>>? metadata address in IOTLB >>>>- provides .read_iter, .write_iter, and .poll callbacks for the >>>>? chardev; they are used by the userspace to exchange IOTLB messages >>>> >>>>This patch was tested with QEMU and a patch applied [1] to fix a >>>>simple issue: >>>>??? $ qemu -M q35,accel=kvm,...

Provide a splice_read stub for ocfs2. This emits trace lines and does an atime lock/update before calling filemap_splice_read(). It doesn't do this for around direct_splice_read() as that will call ->read_iter(). A couple of new tracepoints are added for this purpose. Signed-off-by: David Howells <dhowells at redhat.com> cc: Christoph Hellwig <hch at lst.de> cc: Al Viro <viro at zeniv.linux.org.uk> cc: Jens Axboe <axboe at kernel.dk> cc: Mark Fasheh <mark at fasheh.com> cc...

...unlock(&dsp->vrdev.dev.mutex); + + return ret; +} + +#ifdef CONFIG_COMPAT +static long vhost_dsp_compat_ioctl(struct file *filp, unsigned int ioctl, + unsigned long arg) +{ + return vhost_dsp_ioctl(filp, ioctl, (unsigned long)compat_ptr(arg)); +} +#endif + +static ssize_t vhost_dsp_chr_read_iter(struct kiocb *iocb, struct iov_iter *to) +{ + struct file *filp = iocb->ki_filp; + struct vhost_dsp *dsp = filp->private_data; + struct vhost_dev *dev = &dsp->vrdev.dev; + int noblock = filp->f_flags & O_NONBLOCK; + + return vhost_chr_read_iter(dev, to, noblock); +} + +static ss...

...) + return -EFAULT; + } + for (i = 0; i < VHOST_NET_VQ_MAX; ++i) { mutex_lock(&n->vqs[i].vq.mutex); n->vqs[i].vq.acked_features = features; @@ -1169,9 +1184,40 @@ static long vhost_net_compat_ioctl(struct file *f, unsigned int ioctl, } #endif +static ssize_t vhost_net_chr_read_iter(struct kiocb *iocb, struct iov_iter *to) +{ + struct file *file = iocb->ki_filp; + struct vhost_net *n = file->private_data; + struct vhost_dev *dev = &n->dev; + int noblock = file->f_flags & O_NONBLOCK; + + return vhost_chr_read_iter(dev, to, noblock); +} + +static ssize_t vhos...

This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace IOMMU implementation (qemu) for a secure DMA environment (DMAR) in guest. The idea is simple. When vhost meets an IOTLB miss, it will request the assistance of userspace to do the translation, this is done through: - when there's a IOTLB miss, it will notify userspace through

This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace IOMMU implementation (qemu) for a secure DMA environment (DMAR) in guest. The idea is simple. When vhost meets an IOTLB miss, it will request the assistance of userspace to do the translation, this is done through: - when there's a IOTLB miss, it will notify userspace through

This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace IOMMU implementation (qemu) for a secure DMA environment (DMAR) in guest. The idea is simple. When vhost meets an IOTLB miss, it will request the assistance of userspace to do the translation, this is done through: - when there's a IOTLB miss, it will notify userspace through

This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace IOMMU implementation (qemu) for a secure DMA environment (DMAR) in guest. The idea is simple. When vhost meets an IOTLB miss, it will request the assistance of userspace to do the translation, this is done through: - when there's a IOTLB miss, it will notify userspace through

This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace IOMMU implementation (qemu) for a secure DMA environment (DMAR) in guest. The idea is simple. When vhost meets an IOTLB miss, it will request the assistance of userspace to do the translation, this is done through: - when there's a IOTLB miss, it will notify userspace through

This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace IOMMU implementation (qemu) for a secure DMA environment (DMAR) in guest. The idea is simple. When vhost meets an IOTLB miss, it will request the assistance of userspace to do the translation, this is done through: - when there's a IOTLB miss, it will notify userspace through

This patch set is a follow up to "Add a vhost RPMsg API" [1], it is marked as an RFC because firstly it depends on the RPMsg API series and secondly it is currently being reviewed on ALSA and SOF mailing lists, but any early comments from virtualisation developers would be highly appreciated too! Thanks Guennadi [1]

This patch set is a follow up to "Add a vhost RPMsg API" [1], it is marked as an RFC because firstly it depends on the RPMsg API series and secondly it is currently being reviewed on ALSA and SOF mailing lists, but any early comments from virtualisation developers would be highly appreciated too! Thanks Guennadi [1]