search for: parent_ops

...evice is probed, it will register the device with > mdev based config ops. This means, unlike the exist hardware > transport, this is a software transport between mdev driver and mdev > device. The transport was implemented through: > > - configuration access was implemented through parent_ops->read()/write() > - vq/config callback was implemented through parent_ops->ioctl() > > This transport is derived from virtio MMIO protocol and was wrote for > kernel driver. But for the transport itself, but the design goal is to > be generic enough to support userspace driver...

...evice is probed, it will register the device with > mdev based config ops. This means, unlike the exist hardware > transport, this is a software transport between mdev driver and mdev > device. The transport was implemented through: > > - configuration access was implemented through parent_ops->read()/write() > - vq/config callback was implemented through parent_ops->ioctl() > > This transport is derived from virtio MMIO protocol and was wrote for > kernel driver. But for the transport itself, but the design goal is to > be generic enough to support userspace driver...

...{ /* ... */ module_put(THIS_MODULE); } static long vfio_vhost_mdev_unlocked_ioctl(void *device_data, unsigned int cmd, unsigned long arg) { struct mdev_device *mdev = device_data; struct mdev_parent *parent = mdev->parent; /* * Use vhost ioctls. * * We will have a different parent_ops design. * And potentially, we can share the same parent_ops * with virtio_mdev. */ switch (cmd) { case VHOST_GET_FEATURES: parent->ops->get_features(mdev, ...); break; /* ... */ } return 0; } static ssize_t vfio_vhost_mdev_read(void *device_data, char __user *buf, siz...

...{ /* ... */ module_put(THIS_MODULE); } static long vfio_vhost_mdev_unlocked_ioctl(void *device_data, unsigned int cmd, unsigned long arg) { struct mdev_device *mdev = device_data; struct mdev_parent *parent = mdev->parent; /* * Use vhost ioctls. * * We will have a different parent_ops design. * And potentially, we can share the same parent_ops * with virtio_mdev. */ switch (cmd) { case VHOST_GET_FEATURES: parent->ops->get_features(mdev, ...); break; /* ... */ } return 0; } static ssize_t vfio_vhost_mdev_read(void *device_data, char __user *buf, siz...

...*device_data, > > unsigned int cmd, unsigned long arg) > > { > > struct mdev_device *mdev = device_data; > > struct mdev_parent *parent = mdev->parent; > > > > /* > > * Use vhost ioctls. > > * > > * We will have a different parent_ops design. > > * And potentially, we can share the same parent_ops > > * with virtio_mdev. > > */ > > switch (cmd) { > > case VHOST_GET_FEATURES: > > parent->ops->get_features(mdev, ...); > > break; > > /* ... */ > > } > >...

...*device_data, > > unsigned int cmd, unsigned long arg) > > { > > struct mdev_device *mdev = device_data; > > struct mdev_parent *parent = mdev->parent; > > > > /* > > * Use vhost ioctls. > > * > > * We will have a different parent_ops design. > > * And potentially, we can share the same parent_ops > > * with virtio_mdev. > > */ > > switch (cmd) { > > case VHOST_GET_FEATURES: > > parent->ops->get_features(mdev, ...); > > break; > > /* ... */ > > } > >...

...will register the device with >> mdev based config ops. This means, unlike the exist hardware >> transport, this is a software transport between mdev driver and mdev >> device. The transport was implemented through: >> >> - configuration access was implemented through parent_ops->read()/write() >> - vq/config callback was implemented through parent_ops->ioctl() >> >> This transport is derived from virtio MMIO protocol and was wrote for >> kernel driver. But for the transport itself, but the design goal is to >> be generic enough to suppo...

For about 2 weeks now I been looking in forms and googleing on how to play this game on ubuntu but when I found some one with same problem, I have its been unsolved or a dead end. winehq says its playable on my os and with wine and I played this game for years on this labtop so I doubt it's because I don't meet the req. When I lunch the game terminal under wine I get this error. wine

...; > VFIO device fd. > > > Yes, but any benefit from doing this? > > It does seem a bit more modular, but it's certainly not a big deal. > > Ok, if we go this way, it could be as simple as provide some callback to > vhost, then vhost can just forward the ioctl through parent_ops. > > > > > > > > 2) For method 2, is there any easy way for user/admin to distinguish e.g > > > > > ordinary vfio-mdev for vhost from ordinary vfio-mdev? > > > > I think device-api could be a choice. > > > Ok. > > > > > &...

...; > VFIO device fd. > > > Yes, but any benefit from doing this? > > It does seem a bit more modular, but it's certainly not a big deal. > > Ok, if we go this way, it could be as simple as provide some callback to > vhost, then vhost can just forward the ioctl through parent_ops. > > > > > > > > 2) For method 2, is there any easy way for user/admin to distinguish e.g > > > > > ordinary vfio-mdev for vhost from ordinary vfio-mdev? > > > > I think device-api could be a choice. > > > Ok. > > > > > &...

...tatic long vfio_vhost_mdev_unlocked_ioctl(void *device_data, > unsigned int cmd, unsigned long arg) > { > struct mdev_device *mdev = device_data; > struct mdev_parent *parent = mdev->parent; > > /* > * Use vhost ioctls. > * > * We will have a different parent_ops design. > * And potentially, we can share the same parent_ops > * with virtio_mdev. > */ > switch (cmd) { > case VHOST_GET_FEATURES: > parent->ops->get_features(mdev, ...); > break; > /* ... */ > } > > return 0; > } > > static ssize_t v...

...when a new virtio-mdev device is probed, it will register the device with mdev based config ops. This means, unlike the exist hardware transport, this is a software transport between mdev driver and mdev device. The transport was implemented through: - configuration access was implemented through parent_ops->read()/write() - vq/config callback was implemented through parent_ops->ioctl() This transport is derived from virtio MMIO protocol and was wrote for kernel driver. But for the transport itself, but the design goal is to be generic enough to support userspace driver (this part will be added...

...gt; > > Yes, but any benefit from doing this? > > > > It does seem a bit more modular, but it's certainly not a big deal. > > > Ok, if we go this way, it could be as simple as provide some callback to > > > vhost, then vhost can just forward the ioctl through parent_ops. > > > > > > > > > > 2) For method 2, is there any easy way for user/admin to distinguish e.g > > > > > > > ordinary vfio-mdev for vhost from ordinary vfio-mdev? > > > > > > I think device-api could be a choice. > > > &g...

...sport command 2) dirty pages tracking, could be simply done by introducing new transport command 3) set/get device internal state, this requires more thought, of course we can introduce device specific transport command, but it would be better to have a unified API - Current mdev_parent_ops assumes all pointers are userspace pointer, this block the kernel driver, this series just abuse those as kernel pointer and this could be addressed by inventing new parent_ops. - For quick POC, mdev transport was just derived from virtio-MMIO, I'm pretty sure it has lots of space to be o...

...g vhost ioctls on >>> VFIO device fd. >> Yes, but any benefit from doing this? > It does seem a bit more modular, but it's certainly not a big deal. Ok, if we go this way, it could be as simple as provide some callback to vhost, then vhost can just forward the ioctl through parent_ops. > >>>> 2) For method 2, is there any easy way for user/admin to distinguish e.g >>>> ordinary vfio-mdev for vhost from ordinary vfio-mdev? >>> I think device-api could be a choice. >> Ok. >> >> >>>> I saw you introduce >>&gt...

...evice is probed, it will register the device with > mdev based config ops. This means, unlike the exist hardware > transport, this is a software transport between mdev driver and mdev > device. The transport was implemented through: > > - configuration access was implemented through parent_ops->read()/write() > - vq/config callback was implemented through parent_ops->ioctl() > > This transport is derived from virtio MMIO protocol and was wrote for > kernel driver. But for the transport itself, but the design goal is to > be generic enough to support userspace driver...

...evice is probed, it will register the device with > mdev based config ops. This means, unlike the exist hardware > transport, this is a software transport between mdev driver and mdev > device. The transport was implemented through: > > - configuration access was implemented through parent_ops->read()/write() > - vq/config callback was implemented through parent_ops->ioctl() > > This transport is derived from virtio MMIO protocol and was wrote for > kernel driver. But for the transport itself, but the design goal is to > be generic enough to support userspace driver...

...VFIO device fd. >>>> Yes, but any benefit from doing this? >>> It does seem a bit more modular, but it's certainly not a big deal. >> Ok, if we go this way, it could be as simple as provide some callback to >> vhost, then vhost can just forward the ioctl through parent_ops. >> >>>>>> 2) For method 2, is there any easy way for user/admin to distinguish e.g >>>>>> ordinary vfio-mdev for vhost from ordinary vfio-mdev? >>>>> I think device-api could be a choice. >>>> Ok. >>>> >>>&gt...

...om] > Sent: Tuesday, September 17, 2019 6:17 PM > > On 2019/9/17 ??4:09, Tian, Kevin wrote: > >> From: Jason Wang > >> Sent: Thursday, September 12, 2019 5:40 PM > >> > >> Currently, except for the crate and remove. The rest fields of > >> mdev_parent_ops is just designed for vfio-mdev driver and may not > help > >> for kernel mdev driver. So follow the device id support by previous > >> patch, this patch introduces device specific ops which points to > >> device specific ops (e.g vfio ops). This allows the future drive...

...t; Jason Wang <jasowang at redhat.com> wrote: > > > >> @@ -167,9 +176,10 @@ register itself with the mdev core driver:: > > > >> extern int mdev_register_device(struct device *dev, > > > >> const struct mdev_parent_ops > > > >> *ops); > > > >> > > > >> -It is also required to specify the class_id through:: > > > >> +It is also required to specify the class_id and device specific ops > > through:: > > > >> > > > >>...