Re: [PATCH v2 24/25] fuse: virtio: drop owner assignment
On Sun, Mar 31, 2024 at 10:44:11AM +0200, Krzysztof Kozlowski wrote: > virtio core already sets the .owner, so driver does not need to. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Depends on the first patch. > --- > fs/fuse/virtio_fs.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [PATCH v2 23/25] scsi: virtio: drop owner assignment
On Sun, Mar 31, 2024 at 10:44:10AM +0200, Krzysztof Kozlowski wrote: > virtio core already sets the .owner, so driver does not need to. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Depends on the first patch. > --- > drivers/scsi/virtio_scsi.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [PATCH v2 19/25] vsock/virtio: drop owner assignment
On Sun, Mar 31, 2024 at 10:44:06AM +0200, Krzysztof Kozlowski wrote: > virtio core already sets the .owner, so driver does not need to. > > Acked-by: Stefano Garzarella > Signed-off-by: Krzysztof Kozlowski > --- > > Depends on the first patch. > --- > net/vmw_vsock/virtio_transport.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [PATCH v2 06/25] virtio_blk: drop owner assignment
On Sun, Mar 31, 2024 at 10:43:53AM +0200, Krzysztof Kozlowski wrote: > virtio core already sets the .owner, so driver does not need to. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Depends on the first patch. > --- > drivers/block/virtio_blk.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [PATCH v2 2/4] eventfd: simplify eventfd_signal()
vhost and VIRTIO-related parts:
Reviewed-by: Stefan Hajnoczi
On Wed, 22 Nov 2023 at 07:50, Christian Brauner wrote:
>
> Ever since the evenfd type was introduced back in 2007 in commit
> e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
> function only ever passed 1 as a value for @n. There's no point in
> keeping that additional argument.
>
> Signed-off-by: Christian Brauner
> ---
> arch/x86/kvm/hyperv.c | 2 +-
> arch/x86/kvm/xen.c| 2 +-
> drivers/accel/habanalabs/common/device.c | 2 +-
> drivers/fpga/dfl.c| 2 +-
> drivers/gpu/drm/drm_syncobj.c | 6 +++---
> drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
> drivers/infiniband/hw/mlx5/devx.c | 2 +-
> drivers/misc/ocxl/file.c | 2 +-
> drivers/s390/cio/vfio_ccw_chp.c | 2 +-
> drivers/s390/cio/vfio_ccw_drv.c | 4 ++--
> drivers/s390/cio/vfio_ccw_ops.c | 6 +++---
> drivers/s390/crypto/vfio_ap_ops.c | 2 +-
> drivers/usb/gadget/function/f_fs.c| 4 ++--
> drivers/vdpa/vdpa_user/vduse_dev.c| 6 +++---
> drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c| 2 +-
> drivers/vfio/pci/vfio_pci_core.c | 6 +++---
> drivers/vfio/pci/vfio_pci_intrs.c | 12 ++--
> drivers/vfio/platform/vfio_platform_irq.c | 4 ++--
> drivers/vhost/vdpa.c | 4 ++--
> drivers/vhost/vhost.c | 10 +-
> drivers/vhost/vhost.h | 2 +-
> drivers/virt/acrn/ioeventfd.c | 2 +-
> drivers/xen/privcmd.c | 2 +-
> fs/aio.c | 2 +-
> fs/eventfd.c | 9 +++--
> include/linux/eventfd.h | 4 ++--
> mm/memcontrol.c | 10 +-
> mm/vmpressure.c | 2 +-
> samples/vfio-mdev/mtty.c | 4 ++--
> virt/kvm/eventfd.c| 4 ++--
> 30 files changed, 60 insertions(+), 63 deletions(-)
>
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index 238afd7335e4..4943f6b2bbee 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -2388,7 +2388,7 @@ static u16 kvm_hvcall_signal_event(struct kvm_vcpu
> *vcpu, struct kvm_hv_hcall *h
> if (!eventfd)
> return HV_STATUS_INVALID_PORT_ID;
>
> - eventfd_signal(eventfd, 1);
> + eventfd_signal(eventfd);
> return HV_STATUS_SUCCESS;
> }
>
> diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
> index e53fad915a62..523bb6df5ac9 100644
> --- a/arch/x86/kvm/xen.c
> +++ b/arch/x86/kvm/xen.c
> @@ -2088,7 +2088,7 @@ static bool kvm_xen_hcall_evtchn_send(struct kvm_vcpu
> *vcpu, u64 param, u64 *r)
> if (ret < 0 && ret != -ENOTCONN)
> return false;
> } else {
> - eventfd_signal(evtchnfd->deliver.eventfd.ctx, 1);
> + eventfd_signal(evtchnfd->deliver.eventfd.ctx);
> }
>
> *r = 0;
> diff --git a/drivers/accel/habanalabs/common/device.c
> b/drivers/accel/habanalabs/common/device.c
> index 9711e8fc979d..3a89644f087c 100644
> --- a/drivers/accel/habanalabs/common/device.c
> +++ b/drivers/accel/habanalabs/common/device.c
> @@ -2044,7 +2044,7 @@ static void hl_notifier_event_send(struct
> hl_notifier_event *notifier_event, u64
> notifier_event->events_mask |= event_mask;
>
> if (notifier_event->eventfd)
> - eventfd_signal(notifier_event->eventfd, 1);
> + eventfd_signal(notifier_event->eventfd);
>
> mutex_unlock(_event->lock);
> }
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index dd7a783d53b5..e73f88050f08 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -1872,7 +1872,7 @@ static irqreturn_t dfl_irq_handler(int irq, void *arg)
> {
> struct eventfd_ctx *trigger = arg;
>
> - eventfd_signal(trigger, 1);
> + eventfd_signal(trigger);
> return IRQ_HANDLED;
> }
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 01da6789d044..b9cc62982196 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -1365,7 +1365,7 @@ static void syncobj_eventfd_entry_fence_func(struct
> dma_fence *fence,
> struct syncobj_eventfd_entry *entry =
> container_of(cb, struct syncobj_eventfd_entry, fence_cb);
>
> - eventfd_signal(entry->ev_fd_ctx, 1);
> + eventfd_signa
Re: [RESEND v2 PATCH] init/do_mounts.c: add virtiofs root fs support
On Fri, Feb 24, 2023 at 03:37:51PM +0100, David Heidelberg wrote:
> From: Stefan Hajnoczi
>
> Make it possible to boot directly from a virtiofs file system with tag
> 'myfs' using the following kernel parameters:
>
> rootfstype=virtiofs root=myfs rw
>
> Booting directly from virtiofs makes it possible to use a directory on
> the host as the root file system. This is convenient for testing and
> situations where manipulating disk image files is cumbersome.
>
> Reviewed-by: Helen Koike
> Signed-off-by: Stefan Hajnoczi
> Signed-off-by: David Heidelberg
> ---
> v2: added Reviewed-by and CCed everyone interested.
>
> We have used this option in Mesa3D CI for testing crosvm for
> more than one years and it's proven to work reliably.
>
> We are working on effort to removing custom patches to be able to do
> automated apply and test of patches from any tree.
>
>
> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/.gitlab-ci/crosvm-runner.sh#L85
> init/do_mounts.c | 10 ++
> 1 file changed, 10 insertions(+)
Vivek, do you remember where we ended up with boot from virtiofs? I
thought a different solution was merged some time ago.
There is documentation from the virtiofs community here:
https://virtio-fs.gitlab.io/howto-boot.html
Stefan
>
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index 811e94daf0a8..11c11abe23d7 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -578,6 +578,16 @@ void __init mount_root(void)
> printk(KERN_ERR "VFS: Unable to mount root fs via
> SMB.\n");
> return;
> }
> +#endif
> +#ifdef CONFIG_VIRTIO_FS
> + if (root_fs_names && !strcmp(root_fs_names, "virtiofs")) {
> + if (!do_mount_root(root_device_name, "virtiofs",
> +root_mountflags, root_mount_data))
> + return;
> +
> + panic("VFS: Unable to mount root fs \"%s\" from virtiofs",
> + root_device_name);
> + }
> #endif
> if (ROOT_DEV == 0 && root_device_name && root_fs_names) {
> if (mount_nodev_root() == 0)
> --
> 2.39.1
>
signature.asc
Description: PGP signature
Re: [PATCH RFC] virtio: wrap config->reset calls
On Wed, Oct 13, 2021 at 06:55:31AM -0400, Michael S. Tsirkin wrote: > This will enable cleanups down the road. > The idea is to disable cbs, then add "flush_queued_cbs" callback > as a parameter, this way drivers can flush any work > queued after callbacks have been disabled. > > Signed-off-by: Michael S. Tsirkin > --- > arch/um/drivers/virt-pci.c | 2 +- > drivers/block/virtio_blk.c | 4 ++-- > drivers/bluetooth/virtio_bt.c | 2 +- > drivers/char/hw_random/virtio-rng.c| 2 +- > drivers/char/virtio_console.c | 4 ++-- > drivers/crypto/virtio/virtio_crypto_core.c | 8 > drivers/firmware/arm_scmi/virtio.c | 2 +- > drivers/gpio/gpio-virtio.c | 2 +- > drivers/gpu/drm/virtio/virtgpu_kms.c | 2 +- > drivers/i2c/busses/i2c-virtio.c| 2 +- > drivers/iommu/virtio-iommu.c | 2 +- > drivers/net/caif/caif_virtio.c | 2 +- > drivers/net/virtio_net.c | 4 ++-- > drivers/net/wireless/mac80211_hwsim.c | 2 +- > drivers/nvdimm/virtio_pmem.c | 2 +- > drivers/rpmsg/virtio_rpmsg_bus.c | 2 +- > drivers/scsi/virtio_scsi.c | 2 +- > drivers/virtio/virtio.c| 5 + > drivers/virtio/virtio_balloon.c| 2 +- > drivers/virtio/virtio_input.c | 2 +- > drivers/virtio/virtio_mem.c| 2 +- > fs/fuse/virtio_fs.c| 4 ++-- > include/linux/virtio.h | 1 + > net/9p/trans_virtio.c | 2 +- > net/vmw_vsock/virtio_transport.c | 4 ++-- > sound/virtio/virtio_card.c | 4 ++-- > 26 files changed, 39 insertions(+), 33 deletions(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [PATCH V3 0/7] mdev based hardware virtio offloading support
On Thu, Oct 17, 2019 at 09:42:53AM +0800, Jason Wang wrote: > > On 2019/10/15 下午10:37, Stefan Hajnoczi wrote: > > On Tue, Oct 15, 2019 at 11:37:17AM +0800, Jason Wang wrote: > > > On 2019/10/15 上午1:49, Stefan Hajnoczi wrote: > > > > On Fri, Oct 11, 2019 at 04:15:50PM +0800, Jason Wang wrote: > > > > > There are hardware that can do virtio datapath offloading while having > > > > > its own control path. This path tries to implement a mdev based > > > > > unified API to support using kernel virtio driver to drive those > > > > > devices. This is done by introducing a new mdev transport for virtio > > > > > (virtio_mdev) and register itself as a new kind of mdev driver. Then > > > > > it provides a unified way for kernel virtio driver to talk with mdev > > > > > device implementation. > > > > > > > > > > Though the series only contains kernel driver support, the goal is to > > > > > make the transport generic enough to support userspace drivers. This > > > > > means vhost-mdev[1] could be built on top as well by resuing the > > > > > transport. > > > > > > > > > > A sample driver is also implemented which simulate a virito-net > > > > > loopback ethernet device on top of vringh + workqueue. This could be > > > > > used as a reference implementation for real hardware driver. > > > > > > > > > > Consider mdev framework only support VFIO device and driver right now, > > > > > this series also extend it to support other types. This is done > > > > > through introducing class id to the device and pairing it with > > > > > id_talbe claimed by the driver. On top, this seris also decouple > > > > > device specific parents ops out of the common ones. > > > > I was curious so I took a quick look and posted comments. > > > > > > > > I guess this driver runs inside the guest since it registers virtio > > > > devices? > > > > > > It could run in either guest or host. But the main focus is to run in the > > > host then we can use virtio drivers in containers. > > > > > > > > > > If this is used with physical PCI devices that support datapath > > > > offloading then how are physical devices presented to the guest without > > > > SR-IOV? > > > > > > We will do control path meditation through vhost-mdev[1] and > > > vhost-vfio[2]. > > > Then we will present a full virtio compatible ethernet device for guest. > > > > > > SR-IOV is not a must, any mdev device that implements the API defined in > > > patch 5 can be used by this framework. > > What I'm trying to understand is: if you want to present a virtio-pci > > device to the guest (e.g. using vhost-mdev or vhost-vfio), then how is > > that related to this patch series? > > > This series introduce some infrastructure that would be used by vhost-mdev: > > 1) allow new type of mdev devices/drivers other than vfio (through class_id > and device ops) > > 2) a set of virtio specific callbacks that will be used by both vhost-mdev > and virtio-mdev defined in patch 5 > > Then vhost-mdev can be implemented on top: a new mdev class id but reuse the > callback defined in 2. Through this way the parent can provides a single set > of callbacks (device ops) for both kernel virtio driver (through > virtio-mdev) or userspace virtio driver (through vhost-mdev). Okay, thanks for explaining! Stefan signature.asc Description: PGP signature
Re: [PATCH V3 0/7] mdev based hardware virtio offloading support
On Tue, Oct 15, 2019 at 11:37:17AM +0800, Jason Wang wrote: > > On 2019/10/15 上午1:49, Stefan Hajnoczi wrote: > > On Fri, Oct 11, 2019 at 04:15:50PM +0800, Jason Wang wrote: > > > There are hardware that can do virtio datapath offloading while having > > > its own control path. This path tries to implement a mdev based > > > unified API to support using kernel virtio driver to drive those > > > devices. This is done by introducing a new mdev transport for virtio > > > (virtio_mdev) and register itself as a new kind of mdev driver. Then > > > it provides a unified way for kernel virtio driver to talk with mdev > > > device implementation. > > > > > > Though the series only contains kernel driver support, the goal is to > > > make the transport generic enough to support userspace drivers. This > > > means vhost-mdev[1] could be built on top as well by resuing the > > > transport. > > > > > > A sample driver is also implemented which simulate a virito-net > > > loopback ethernet device on top of vringh + workqueue. This could be > > > used as a reference implementation for real hardware driver. > > > > > > Consider mdev framework only support VFIO device and driver right now, > > > this series also extend it to support other types. This is done > > > through introducing class id to the device and pairing it with > > > id_talbe claimed by the driver. On top, this seris also decouple > > > device specific parents ops out of the common ones. > > I was curious so I took a quick look and posted comments. > > > > I guess this driver runs inside the guest since it registers virtio > > devices? > > > It could run in either guest or host. But the main focus is to run in the > host then we can use virtio drivers in containers. > > > > > > If this is used with physical PCI devices that support datapath > > offloading then how are physical devices presented to the guest without > > SR-IOV? > > > We will do control path meditation through vhost-mdev[1] and vhost-vfio[2]. > Then we will present a full virtio compatible ethernet device for guest. > > SR-IOV is not a must, any mdev device that implements the API defined in > patch 5 can be used by this framework. What I'm trying to understand is: if you want to present a virtio-pci device to the guest (e.g. using vhost-mdev or vhost-vfio), then how is that related to this patch series? Does this mean this patch series is useful mostly for presenting virtio devices to containers or the host? Stefan signature.asc Description: PGP signature
Re: [PATCH V3 0/7] mdev based hardware virtio offloading support
On Fri, Oct 11, 2019 at 04:15:50PM +0800, Jason Wang wrote: > There are hardware that can do virtio datapath offloading while having > its own control path. This path tries to implement a mdev based > unified API to support using kernel virtio driver to drive those > devices. This is done by introducing a new mdev transport for virtio > (virtio_mdev) and register itself as a new kind of mdev driver. Then > it provides a unified way for kernel virtio driver to talk with mdev > device implementation. > > Though the series only contains kernel driver support, the goal is to > make the transport generic enough to support userspace drivers. This > means vhost-mdev[1] could be built on top as well by resuing the > transport. > > A sample driver is also implemented which simulate a virito-net > loopback ethernet device on top of vringh + workqueue. This could be > used as a reference implementation for real hardware driver. > > Consider mdev framework only support VFIO device and driver right now, > this series also extend it to support other types. This is done > through introducing class id to the device and pairing it with > id_talbe claimed by the driver. On top, this seris also decouple > device specific parents ops out of the common ones. I was curious so I took a quick look and posted comments. I guess this driver runs inside the guest since it registers virtio devices? If this is used with physical PCI devices that support datapath offloading then how are physical devices presented to the guest without SR-IOV? Stefan signature.asc Description: PGP signature
Re: [PATCH V3 6/7] virtio: introduce a mdev based transport
On Fri, Oct 11, 2019 at 04:15:56PM +0800, Jason Wang wrote:
> +struct virtio_mdev_device {
> + struct virtio_device vdev;
> + struct mdev_device *mdev;
> + unsigned long version;
> +
> + struct virtqueue **vqs;
> + /* The lock to protect virtqueue list */
> + spinlock_t lock;
> + struct list_head virtqueues;
Is this a list of struct virtio_mdev_vq_info? Please document the
actual type in a comment.
> +static int virtio_mdev_find_vqs(struct virtio_device *vdev, unsigned nvqs,
> + struct virtqueue *vqs[],
> + vq_callback_t *callbacks[],
> + const char * const names[],
> + const bool *ctx,
> + struct irq_affinity *desc)
> +{
> + struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
> + struct mdev_device *mdev = vm_get_mdev(vdev);
> + const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
> + struct virtio_mdev_callback cb;
> + int i, err, queue_idx = 0;
> +
> + vm_dev->vqs = kmalloc_array(queue_idx, sizeof(*vm_dev->vqs),
> + GFP_KERNEL);
kmalloc_array(0, ...)? I would have expected nvqs instead of queue_idx
(0).
What is this the purpose of vm_dev->vqs and does anything ever access it?
signature.asc
Description: PGP signature
Re: [PATCH V3 5/7] mdev: introduce virtio device and its device ops
On Fri, Oct 11, 2019 at 04:15:55PM +0800, Jason Wang wrote: > + * @set_vq_cb: Set the interrut calback function for s/interrut/interrupt/ s/calback/callback/ signature.asc Description: PGP signature
[PATCH 10/10] virtio: enable endian checks for sparse builds
On Tue, Dec 06, 2016 at 05:41:05PM +0200, Michael S. Tsirkin wrote: > __CHECK_ENDIAN__ isn't on by default presumably because > it triggers too many sparse warnings for correct code. > But virtio is now clean of these warnings, and > we want to keep it this way - enable this for > sparse builds. > > Signed-off-by: Michael S. Tsirkin > --- > > It seems that there should be a better way to do it, > but this works too. > > drivers/block/Makefile | 1 + > drivers/char/Makefile | 1 + > drivers/char/hw_random/Makefile | 2 ++ > drivers/gpu/drm/virtio/Makefile | 1 + > drivers/net/Makefile| 3 +++ > drivers/net/caif/Makefile | 1 + > drivers/rpmsg/Makefile | 1 + > drivers/s390/virtio/Makefile| 2 ++ > drivers/scsi/Makefile | 1 + > drivers/vhost/Makefile | 1 + > drivers/virtio/Makefile | 3 +++ > net/9p/Makefile | 1 + > net/packet/Makefile | 1 + > net/vmw_vsock/Makefile | 2 ++ > 14 files changed, 21 insertions(+) Reviewed-by: Stefan Hajnoczi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/d7e15474/attachment.sig>
