search for: vfio_device_op

...; > ops matching helper but it's not friendly to management. > > > > The ops matching helper is just to check whether a given > > > > vfio-device is based on a mdev device. > > > > > > > > > 3) A drawback of 1) and 2) is that it must follow vfio_device_ops that > > > > > assumes the parameter comes from userspace, it prevents support kernel > > > > > virtio drivers. > > > > > > > > > > 4) So comes the idea of method 3, since it register a new vhost-mdev driver, > > > > > we...

...; > ops matching helper but it's not friendly to management. > > > > The ops matching helper is just to check whether a given > > > > vfio-device is based on a mdev device. > > > > > > > > > 3) A drawback of 1) and 2) is that it must follow vfio_device_ops that > > > > > assumes the parameter comes from userspace, it prevents support kernel > > > > > virtio drivers. > > > > > > > > > > 4) So comes the idea of method 3, since it register a new vhost-mdev driver, > > > > > we...

...the container that > > > is attached. > > Yeah, that's what we are doing in this series. > > > > > We have two more choices: > > > > > > 2) Use vfio-mdev but do not create vhost-mdev device, instead, just > > > implement vhost ioctl on vfio_device_ops, and translate them into > > > virtio-mdev transport or just pass ioctl to parent. > > Yeah. Instead of introducing /dev/vhost-mdev char device, do > > vhost ioctls on VFIO device fd directly. That's what we did > > in RFC v3. > > > > > 3) Don't u...

...the container that > > > is attached. > > Yeah, that's what we are doing in this series. > > > > > We have two more choices: > > > > > > 2) Use vfio-mdev but do not create vhost-mdev device, instead, just > > > implement vhost ioctl on vfio_device_ops, and translate them into > > > virtio-mdev transport or just pass ioctl to parent. > > Yeah. Instead of introducing /dev/vhost-mdev char device, do > > vhost ioctls on VFIO device fd directly. That's what we did > > in RFC v3. > > > > > 3) Don't u...

...not friendly to management. > > > > > > The ops matching helper is just to check whether a given > > > > > > vfio-device is based on a mdev device. > > > > > > > > > > > > > 3) A drawback of 1) and 2) is that it must follow vfio_device_ops that > > > > > > > assumes the parameter comes from userspace, it prevents support kernel > > > > > > > virtio drivers. > > > > > > > > > > > > > > 4) So comes the idea of method 3, since it register a new vhost-m...

...> read/write). DMA was done through the VFIO DMA mapping on the container that > is attached. Yeah, that's what we are doing in this series. > > We have two more choices: > > 2) Use vfio-mdev but do not create vhost-mdev device, instead, just > implement vhost ioctl on vfio_device_ops, and translate them into > virtio-mdev transport or just pass ioctl to parent. Yeah. Instead of introducing /dev/vhost-mdev char device, do vhost ioctls on VFIO device fd directly. That's what we did in RFC v3. > > 3) Don't use vfio-mdev, create a new vhost-mdev driver, during...

...> read/write). DMA was done through the VFIO DMA mapping on the container that > is attached. Yeah, that's what we are doing in this series. > > We have two more choices: > > 2) Use vfio-mdev but do not create vhost-mdev device, instead, just > implement vhost ioctl on vfio_device_ops, and translate them into > virtio-mdev transport or just pass ioctl to parent. Yeah. Instead of introducing /dev/vhost-mdev char device, do vhost ioctls on VFIO device fd directly. That's what we did in RFC v3. > > 3) Don't use vfio-mdev, create a new vhost-mdev driver, during...

...> ops matching helper but it's not friendly to management. >>>>> The ops matching helper is just to check whether a given >>>>> vfio-device is based on a mdev device. >>>>> >>>>>> 3) A drawback of 1) and 2) is that it must follow vfio_device_ops that >>>>>> assumes the parameter comes from userspace, it prevents support kernel >>>>>> virtio drivers. >>>>>> >>>>>> 4) So comes the idea of method 3, since it register a new vhost-mdev driver, >>>>>> we c...

...A was done through the VFIO DMA mapping on the container that >> is attached. > Yeah, that's what we are doing in this series. > >> We have two more choices: >> >> 2) Use vfio-mdev but do not create vhost-mdev device, instead, just >> implement vhost ioctl on vfio_device_ops, and translate them into >> virtio-mdev transport or just pass ioctl to parent. > Yeah. Instead of introducing /dev/vhost-mdev char device, do > vhost ioctls on VFIO device fd directly. That's what we did > in RFC v3. > >> 3) Don't use vfio-mdev, create a new vhost-...

This RFC is to demonstrate below ideas, a) Build vhost-mdev on top of the same abstraction defined in the virtio-mdev series [1]; b) Introduce /dev/vhost-mdev to do vhost ioctls and support setting mdev device as backend; Now the userspace API looks like this: - Userspace generates a compatible mdev device; - Userspace opens this mdev device with VFIO API (including doing IOMMU

This RFC is to demonstrate below ideas, a) Build vhost-mdev on top of the same abstraction defined in the virtio-mdev series [1]; b) Introduce /dev/vhost-mdev to do vhost ioctls and support setting mdev device as backend; Now the userspace API looks like this: - Userspace generates a compatible mdev device; - Userspace opens this mdev device with VFIO API (including doing IOMMU

...I saw you introduce >>>> ops matching helper but it's not friendly to management. >>> The ops matching helper is just to check whether a given >>> vfio-device is based on a mdev device. >>> >>>> 3) A drawback of 1) and 2) is that it must follow vfio_device_ops that >>>> assumes the parameter comes from userspace, it prevents support kernel >>>> virtio drivers. >>>> >>>> 4) So comes the idea of method 3, since it register a new vhost-mdev driver, >>>> we can use device specific ops instead of VF...

...e fd to it as a backend and translate vhost-mdev ioctl to virtio mdev transport (e.g read/write). DMA was done through the VFIO DMA mapping on the container that is attached. We have two more choices: 2) Use vfio-mdev but do not create vhost-mdev device, instead, just implement vhost ioctl on vfio_device_ops, and translate them into virtio-mdev transport or just pass ioctl to parent. 3) Don't use vfio-mdev, create a new vhost-mdev driver, during probe still try to add dev to vfio group and talk to parent with device specific ops So I have some questions: 1) Compared to method 2, what's t...

...+ r = vhost_dev_ioctl(&m->dev, cmd, argp); > > + if (r == -ENOIOCTLCMD) > > + r = vhost_vring_ioctl(&m->dev, cmd, argp); > > + } > > + > > + mutex_unlock(&m->mutex); > > + return r; > > +} > > + > > +static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = { > > + .name = "vfio-vhost-mdev", > > + .open = vhost_mdev_open, > > + .release = vhost_mdev_release, > > + .ioctl = vhost_mdev_unlocked_ioctl, > > +}; > > + > > +static int vhost_mdev_probe(struct device *dev) >...

...+ r = vhost_dev_ioctl(&m->dev, cmd, argp); > > + if (r == -ENOIOCTLCMD) > > + r = vhost_vring_ioctl(&m->dev, cmd, argp); > > + } > > + > > + mutex_unlock(&m->mutex); > > + return r; > > +} > > + > > +static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = { > > + .name = "vfio-vhost-mdev", > > + .open = vhost_mdev_open, > > + .release = vhost_mdev_release, > > + .ioctl = vhost_mdev_unlocked_ioctl, > > +}; > > + > > +static int vhost_mdev_probe(struct device *dev) >...

...CTLCMD) > > > > + r = vhost_vring_ioctl(&m->dev, cmd, argp); > > > > + } > > > > + > > > > + mutex_unlock(&m->mutex); > > > > + return r; > > > > +} > > > > + > > > > +static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = { > > > > + .name = "vfio-vhost-mdev", > > > > + .open = vhost_mdev_open, > > > > + .release = vhost_mdev_release, > > > > + .ioctl = vhost_mdev_unlocked_ioctl, > > > > +}; > > > > + >...

...iver. The driver provides an ops structure for callbacks +a VFIO bus driver. A negative return value indicates failure. +A positive return value indicates that an unsafe noiommu mode +is in use. The driver provides an ops structure for callbacks similar to a file operations structure: struct vfio_device_ops { -- MST

...p;m->dev, cmd, argp); >>> + if (r == -ENOIOCTLCMD) >>> + r = vhost_vring_ioctl(&m->dev, cmd, argp); >>> + } >>> + >>> + mutex_unlock(&m->mutex); >>> + return r; >>> +} >>> + >>> +static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = { >>> + .name = "vfio-vhost-mdev", >>> + .open = vhost_mdev_open, >>> + .release = vhost_mdev_release, >>> + .ioctl = vhost_mdev_unlocked_ioctl, >>> +}; >>> + >>> +static int vhost_mdev_probe(stru...

...k; + case VHOST_GET_VRING_BASE: + r = vhost_get_vring_base(m, argp); + break; + default: + r = vhost_dev_ioctl(&m->dev, cmd, argp); + if (r == -ENOIOCTLCMD) + r = vhost_vring_ioctl(&m->dev, cmd, argp); + } + + mutex_unlock(&m->mutex); + return r; +} + +static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = { + .name = "vfio-vhost-mdev", + .open = vhost_mdev_open, + .release = vhost_mdev_release, + .ioctl = vhost_mdev_unlocked_ioctl, +}; + +static int vhost_mdev_probe(struct device *dev) +{ + struct mdev_device *mdev = mdev_from_dev(dev); + const struct virtio_m...

...k; + case VHOST_GET_VRING_BASE: + r = vhost_get_vring_base(m, argp); + break; + default: + r = vhost_dev_ioctl(&m->dev, cmd, argp); + if (r == -ENOIOCTLCMD) + r = vhost_vring_ioctl(&m->dev, cmd, argp); + } + + mutex_unlock(&m->mutex); + return r; +} + +static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = { + .name = "vfio-vhost-mdev", + .open = vhost_mdev_open, + .release = vhost_mdev_release, + .ioctl = vhost_mdev_unlocked_ioctl, +}; + +static int vhost_mdev_probe(struct device *dev) +{ + struct mdev_device *mdev = mdev_from_dev(dev); + const struct virtio_m...