search for: error_kmalloc

...int num; int err; @@ -372,13 +346,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned index, goto error_available; } - /* Allocate and fill out our active queue description */ - info = kmalloc(sizeof(*info), GFP_KERNEL); - if (!info) { - err = -ENOMEM; - goto error_kmalloc; - } - num = readl(vm_dev->base + VIRTIO_MMIO_QUEUE_NUM_MAX); if (num == 0) { err = -ENOENT; @@ -420,13 +387,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned index, writel(1, vm_dev->base + VIRTIO_MMIO_QUEUE_READY); } - vq->priv = info; - info-&g...

...int num; int err; @@ -372,13 +346,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned index, goto error_available; } - /* Allocate and fill out our active queue description */ - info = kmalloc(sizeof(*info), GFP_KERNEL); - if (!info) { - err = -ENOMEM; - goto error_kmalloc; - } - num = readl(vm_dev->base + VIRTIO_MMIO_QUEUE_NUM_MAX); if (num == 0) { err = -ENOENT; @@ -420,13 +387,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned index, writel(1, vm_dev->base + VIRTIO_MMIO_QUEUE_READY); } - vq->priv = info; - info-&g...

...ter. > Just do > if (ops->get_vq_ready(mdev, index)) > return -ENOENT; Ok, will fix. > >> + /* Allocate and fill out our active queue description */ >> + info = kmalloc(sizeof(*info), GFP_KERNEL); >> + if (!info) { >> + err = -ENOMEM; >> + goto error_kmalloc; >> + } >> + > Similar to above one. Ok. > >> + num = ops->get_queue_max(mdev); >> + if (num == 0) { >> + err = -ENOENT; >> + goto error_new_virtqueue; >> + } >> + >> + /* Create the vring */ >> + align = ops->get_vq_alig...

...shouldn't already be set up. */ + if (virtio_mdev_readl(vm_dev->mdev, VIRTIO_MDEV_QUEUE_READY)) { + err = -ENOENT; + goto error_available; + } + + /* Allocate and fill out our active queue description */ + info = kmalloc(sizeof(*info), GFP_KERNEL); + if (!info) { + err = -ENOMEM; + goto error_kmalloc; + } + + num = virtio_mdev_readl(vm_dev->mdev, VIRTIO_MDEV_QUEUE_NUM_MAX); + if (num == 0) { + err = -ENOENT; + goto error_new_virtqueue; + } + + /* Create the vring */ + align = virtio_mdev_readl(vm_dev->mdev, VIRTIO_MDEV_QUEUE_ALIGN); + vq = vring_create_virtqueue(index, num, align, vdev,...

On Mon, 2011-10-24 at 03:33 +0100, Rusty Russell wrote: > No, that's it I think. Please send a diff for the documentation, since > I'm updating the LyX master and I've already applied your previous > version. Here it goes (below). Also do you think you would be able to merge the driver (corresponding v4 patch follows) in the 3.2 merge window that seems to have just opened?

On Mon, 2011-10-24 at 03:33 +0100, Rusty Russell wrote: > No, that's it I think. Please send a diff for the documentation, since > I'm updating the LyX master and I've already applied your previous > version. Here it goes (below). Also do you think you would be able to merge the driver (corresponding v4 patch follows) in the 3.2 merge window that seems to have just opened?

...rtio_mdev_readl(vm_dev->mdev, VIRTIO_MDEV_QUEUE_READY)) { > + err = -ENOENT; > + goto error_available; > + } > + > + /* Allocate and fill out our active queue description */ > + info = kmalloc(sizeof(*info), GFP_KERNEL); > + if (!info) { > + err = -ENOMEM; > + goto error_kmalloc; > + } > + > + num = virtio_mdev_readl(vm_dev->mdev, VIRTIO_MDEV_QUEUE_NUM_MAX); > + if (num == 0) { > + err = -ENOENT; > + goto error_new_virtqueue; > + } > + > + /* Create the vring */ > + align = virtio_mdev_readl(vm_dev->mdev, VIRTIO_MDEV_QUEUE_ALIGN); >...

...rtio_mdev_readl(vm_dev->mdev, VIRTIO_MDEV_QUEUE_READY)) { > + err = -ENOENT; > + goto error_available; > + } > + > + /* Allocate and fill out our active queue description */ > + info = kmalloc(sizeof(*info), GFP_KERNEL); > + if (!info) { > + err = -ENOMEM; > + goto error_kmalloc; > + } > + > + num = virtio_mdev_readl(vm_dev->mdev, VIRTIO_MDEV_QUEUE_NUM_MAX); > + if (num == 0) { > + err = -ENOENT; > + goto error_new_virtqueue; > + } > + > + /* Create the vring */ > + align = virtio_mdev_readl(vm_dev->mdev, VIRTIO_MDEV_QUEUE_ALIGN); >...

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

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. This appears to work on native and Xen x86_64 using both modern and legacy virtio-pci. It also appears to work on arm and arm64. It definitely won't work as-is on s390x, and

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. This appears to work on native and Xen x86_64 using both modern and legacy virtio-pci. It also appears to work on arm and arm64. It definitely won't work as-is on s390x, and

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too

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

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

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too

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