search for: virtio_mdev_writel

...loff_t off) +{ + struct mdev_parent *parent = mdev->parent; + ssize_t len; + u32 val; + + if (unlikely(!parent->ops->read)) + return 0xFFFFFFFF; + + len = parent->ops->read(mdev, (char *)&val, 4, &off); + if (len != 4) + return 0xFFFFFFFF; + + return val; +} + +static void virtio_mdev_writel(struct mdev_device *mdev, + loff_t off, u32 val) +{ + struct mdev_parent *parent = mdev->parent; + + if (unlikely(!parent->ops->write)) + return; + + parent->ops->write(mdev, (char *)&val, 4, &off); + + return; +} + +static void virtio_mdev_get(struct virtio_device...

...gt; + struct vfio_device *vfio_device; > + struct mdev_device *mdev; > +}; > + > +/* > + * XXX > + * We assume virtio_mdev.ko exposes below symbols for now, as we > + * don't have a proper way to access parent ops directly yet. > + * > + * virtio_mdev_readl() > + * virtio_mdev_writel() > + */ > +extern u32 virtio_mdev_readl(struct mdev_device *mdev, loff_t off); > +extern void virtio_mdev_writel(struct mdev_device *mdev, loff_t off, u32 val); Need to consider a better approach, I feel we should do it through some kind of mdev driver instead of talk to mdev device di...

...u64 acked_features; + struct vfio_group *vfio_group; + struct vfio_device *vfio_device; + struct mdev_device *mdev; +}; + +/* + * XXX + * We assume virtio_mdev.ko exposes below symbols for now, as we + * don't have a proper way to access parent ops directly yet. + * + * virtio_mdev_readl() + * virtio_mdev_writel() + */ +extern u32 virtio_mdev_readl(struct mdev_device *mdev, loff_t off); +extern void virtio_mdev_writel(struct mdev_device *mdev, loff_t off, u32 val); + +static u8 mdev_get_status(struct mdev_device *mdev) +{ + return virtio_mdev_readl(mdev, VIRTIO_MDEV_STATUS); +} + +static void mdev_set_stat...

...ssize_t len; > + u32 val; > + > + if (unlikely(!parent->ops->read)) > + return 0xFFFFFFFF; > + > + len = parent->ops->read(mdev, (char *)&val, 4, &off); > + if (len != 4) > + return 0xFFFFFFFF; > + > + return val; > +} > + > +static void virtio_mdev_writel(struct mdev_device *mdev, > + loff_t off, u32 val) > +{ > + struct mdev_parent *parent = mdev->parent; > + > + if (unlikely(!parent->ops->write)) > + return; > + > + parent->ops->write(mdev, (char *)&val, 4, &off); > + > + return; >...

...ssize_t len; > + u32 val; > + > + if (unlikely(!parent->ops->read)) > + return 0xFFFFFFFF; > + > + len = parent->ops->read(mdev, (char *)&val, 4, &off); > + if (len != 4) > + return 0xFFFFFFFF; > + > + return val; > +} > + > +static void virtio_mdev_writel(struct mdev_device *mdev, > + loff_t off, u32 val) > +{ > + struct mdev_parent *parent = mdev->parent; > + > + if (unlikely(!parent->ops->write)) > + return; > + > + parent->ops->write(mdev, (char *)&val, 4, &off); > + > + return; >...

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

Hi all: 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