search for: _viommu_send_reqs_sync

...ON(!pending)) return 0; - while ((req = virtqueue_get_buf(viommu->vq, &len)) != NULL) { + while ((req = virtqueue_get_buf(vq, &len)) != NULL) { if (req != pending) { dev_warn(viommu->dev, "discarding stale request\n"); continue; @@ -201,6 +218,7 @@ static int _viommu_send_reqs_sync(struct viommu_dev *viommu, * up the CPU in case of a device bug. */ unsigned long timeout_ms = 1000; + struct virtqueue *vq = viommu->vqs[VIOMMU_REQUEST_VQ]; *nr_sent = 0; @@ -210,15 +228,14 @@ static int _viommu_send_reqs_sync(struct viommu_dev *viommu, sg[0] = &req->top...

...ON(!pending)) return 0; - while ((req = virtqueue_get_buf(viommu->vq, &len)) != NULL) { + while ((req = virtqueue_get_buf(vq, &len)) != NULL) { if (req != pending) { dev_warn(viommu->dev, "discarding stale request\n"); continue; @@ -202,6 +218,7 @@ static int _viommu_send_reqs_sync(struct viommu_dev *viommu, * dies. */ unsigned long timeout_ms = 1000; + struct virtqueue *vq = viommu->vqs[VIOMMU_REQUEST_VQ]; *nr_sent = 0; @@ -211,15 +228,14 @@ static int _viommu_send_reqs_sync(struct viommu_dev *viommu, sg[0] = &req->top; sg[1] = &req->bott...

...gt; - while ((req = virtqueue_get_buf(viommu->vq, &len)) != NULL) { > + while ((req = virtqueue_get_buf(vq, &len)) != NULL) { > if (req != pending) { > dev_warn(viommu->dev, "discarding stale request\n"); > continue; > @@ -202,6 +218,7 @@ static int _viommu_send_reqs_sync(struct viommu_dev *viommu, > * dies. > */ > unsigned long timeout_ms = 1000; > + struct virtqueue *vq = viommu->vqs[VIOMMU_REQUEST_VQ]; > > *nr_sent = 0; > > @@ -211,15 +228,14 @@ static int _viommu_send_reqs_sync(struct viommu_dev *viommu, > sg[0] = &...

...mp;pending->list, sent))) { >> + break; >> + } >> + >> + pending = list_next_entry(pending, list); > > We should remove current element from the pending list. There is no > guarantee we get response for each while loop so when we get back for > more the _viommu_send_reqs_sync() caller will pass pointer to the out of > date head next time. Right, I'll fix this Thanks, Jean

...WARN_ON(!list_is_last(&pending->list, sent)); > + break; > + } else if (WARN_ON(list_is_last(&pending->list, sent))) { > + break; > + } > + > + pending = list_next_entry(pending, list); > + } > + > + return nr_received; > +} > + > +static int _viommu_send_reqs_sync(struct viommu_dev *viommu, > + struct viommu_request *req, int nr, > + int *nr_sent) > +{ > + int i, ret; > + ktime_t timeout; > + LIST_HEAD(pending); > + int nr_received = 0; > + struct scatterlist *sg[2]; > + /* > + * The timeout is chosen arbitrarily. It&...

Implement the virtio-iommu driver following version 0.6 of the specification [1]. Previous version, RFCv2, was sent in November [2]. This version addresses Eric's comments and changes the device number. (Since last week I also tested and fixed the probe/release functions, they now use devm properly.) I did not include ACPI support because the next IORT specifications isn't ready yet (even

Implement the virtio-iommu driver following version 0.6 of the specification [1]. Previous version, RFCv2, was sent in November [2]. This version addresses Eric's comments and changes the device number. (Since last week I also tested and fixed the probe/release functions, they now use devm properly.) I did not include ACPI support because the next IORT specifications isn't ready yet (even

Implement the virtio-iommu driver following version 0.5 of the specification [1]. Previous version of this code was sent back in April [2], implementing the first public RFC. Since then there has been lots of progress and discussion on the specification side, and I think the driver is in a good shape now. The reason patches 1-3 are only RFC is that I'm waiting on feedback from the Virtio TC

Implement the virtio-iommu driver following version 0.5 of the specification [1]. Previous version of this code was sent back in April [2], implementing the first public RFC. Since then there has been lots of progress and discussion on the specification side, and I think the driver is in a good shape now. The reason patches 1-3 are only RFC is that I'm waiting on feedback from the Virtio TC

...); > + break; > + } else if (WARN_ON(list_is_last(&pending->list, sent))) { > + break; > + } > + > + pending = list_next_entry(pending, list); > + } > + > + return nr_received; > +} > + > +/* Must be called with request_lock held */ > +static int _viommu_send_reqs_sync(struct viommu_dev *viommu, > + struct viommu_request *req, int nr, > + int *nr_sent) > +{ > + int i, ret; > + ktime_t timeout; > + LIST_HEAD(pending); > + int nr_received = 0; > + struct scatterlist *sg[2]; > + /* > + * Yes, 1s timeout. As a guest, we don...

...>written = len; + + if (++nr_received == nr_sent) { + WARN_ON(!list_is_last(&pending->list, sent)); + break; + } else if (WARN_ON(list_is_last(&pending->list, sent))) { + break; + } + + pending = list_next_entry(pending, list); + } + + return nr_received; +} + +static int _viommu_send_reqs_sync(struct viommu_dev *viommu, + struct viommu_request *req, int nr, + int *nr_sent) +{ + int i, ret; + ktime_t timeout; + LIST_HEAD(pending); + int nr_received = 0; + struct scatterlist *sg[2]; + /* + * The timeout is chosen arbitrarily. It's only here to prevent locking + * up the CPU...

...nr_sent) { + WARN_ON(!list_is_last(&pending->list, sent)); + break; + } else if (WARN_ON(list_is_last(&pending->list, sent))) { + break; + } + + pending = list_next_entry(pending, list); + } + + return nr_received; +} + +/* Must be called with request_lock held */ +static int _viommu_send_reqs_sync(struct viommu_dev *viommu, + struct viommu_request *req, int nr, + int *nr_sent) +{ + int i, ret; + ktime_t timeout; + LIST_HEAD(pending); + int nr_received = 0; + struct scatterlist *sg[2]; + /* + * Yes, 1s timeout. As a guest, we don't necessarily have a precise + * notion of time...

...the caller. + */ + break; + } + + next = list_next_entry(pending, list); + list_del(&pending->list); + + if (WARN_ON(list_empty(&viommu->pending_requests))) + return 0; + + pending = next; + } + + return nr_received; +} + +/* Must be called with vq_lock held */ +static int _viommu_send_reqs_sync(struct viommu_dev *viommu, + struct viommu_request *req, int nr, + int *nr_sent) +{ + int i, ret; + ktime_t timeout; + int nr_received = 0; + struct scatterlist *sg[2]; + /* + * FIXME: as it stands, 1s timeout per request. This is a voluntary + * exaggeration because I have no idea how...

...ending, list); > + list_del(&pending->list); > + > + if (WARN_ON(list_empty(&viommu->pending_requests))) > + return 0; > + > + pending = next; > + } > + > + return nr_received; > +} > + > +/* Must be called with vq_lock held */ > +static int _viommu_send_reqs_sync(struct viommu_dev *viommu, > + struct viommu_request *req, int nr, > + int *nr_sent) > +{ > + int i, ret; > + ktime_t timeout; > + int nr_received = 0; > + struct scatterlist *sg[2]; > + /* > + * FIXME: as it stands, 1s timeout per request. This is a voluntary...

...ending, list); > + list_del(&pending->list); > + > + if (WARN_ON(list_empty(&viommu->pending_requests))) > + return 0; > + > + pending = next; > + } > + > + return nr_received; > +} > + > +/* Must be called with vq_lock held */ > +static int _viommu_send_reqs_sync(struct viommu_dev *viommu, > + struct viommu_request *req, int nr, > + int *nr_sent) > +{ > + int i, ret; > + ktime_t timeout; > + int nr_received = 0; > + struct scatterlist *sg[2]; > + /* > + * FIXME: as it stands, 1s timeout per request. This is a voluntary...

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices. In its simplest form, implemented here, the device handles map/unmap requests from the guest. Future

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices. In its simplest form, implemented here, the device handles map/unmap requests from the guest. Future