search for: nr_sent

...>detach); + break; + case VIRTIO_IOMMU_T_MAP: + size = sizeof(r->map); + break; + case VIRTIO_IOMMU_T_UNMAP: + size = sizeof(r->unmap); + break; + default: + return -EINVAL; + } + + *top = size - *bottom; + return 0; +} + +static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent, + struct list_head *sent) +{ + + unsigned int len; + int nr_received = 0; + struct viommu_request *req, *pending; + + pending = list_first_entry_or_null(sent, struct viommu_request, list); + if (WARN_ON(!pending)) + return 0; + + while ((req = virtqueue_get_buf(viommu->vq, &len))...

...>detach); + break; + case VIRTIO_IOMMU_T_MAP: + size = sizeof(r->map); + break; + case VIRTIO_IOMMU_T_UNMAP: + size = sizeof(r->unmap); + break; + default: + return -EINVAL; + } + + *top = size - *bottom; + return 0; +} + +static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent, + struct list_head *sent) +{ + + unsigned int len; + int nr_received = 0; + struct viommu_request *req, *pending; + + pending = list_first_entry_or_null(sent, struct viommu_request, list); + if (WARN_ON(!pending)) + return 0; + + while ((req = virtqueue_get_buf(viommu->vq, &len))...

...f(r->map); > + break; > + case VIRTIO_IOMMU_T_UNMAP: > + size = sizeof(r->unmap); > + break; > + default: > + return -EINVAL; > + } > + > + *top = size - *bottom; > + return 0; > +} > + > +static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent, > + struct list_head *sent) > +{ > + > + unsigned int len; > + int nr_received = 0; > + struct viommu_request *req, *pending; > + > + pending = list_first_entry_or_null(sent, struct viommu_request, list); > + if (WARN_ON(!pending)) > + return 0; > + >...

...>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 real our ktime is. Are we + * using a RTC? Are we aware of steal time? I don't know m...

...f(r->map); > + break; > + case VIRTIO_IOMMU_T_UNMAP: > + size = sizeof(r->unmap); > + break; > + default: > + return -EINVAL; > + } > + > + *top = size - *bottom; > + return 0; > +} > + > +static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent, > + struct list_head *sent) > +{ > + > + unsigned int len; > + int nr_received = 0; > + struct viommu_request *req, *pending; > + > + pending = list_first_entry_or_null(sent, struct viommu_request, list); > + if (WARN_ON(!pending)) > + return 0; > + >...

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

...ng_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 real our ktime is. Are we > + * using a RTC? A...

...ng_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 real our ktime is. Are we > + * using a RTC? A...

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

On 19/02/18 12:23, Tomasz Nowicki wrote: [...] >> +static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent, >> + struct list_head *sent) >> +{ >> + >> + unsigned int len; >> + int nr_received = 0; >> + struct viommu_request *req, *pending; >> + >> + pending = list_first_entry_or_null(sent, struct viommu_request, list); >> + if (WARN_ON(!pend...

...FAULT_RESV_MASK 0xffffff00 + +struct viommu_event { + union { + u32 head; + struct virtio_iommu_fault fault; + }; +}; + #define to_viommu_domain(domain) \ container_of(domain, struct viommu_domain, domain) @@ -161,12 +177,13 @@ static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent, unsigned int len; int nr_received = 0; struct viommu_request *req, *pending; + struct virtqueue *vq = viommu->vqs[VIOMMU_REQUEST_VQ]; pending = list_first_entry_or_null(sent, struct viommu_request, list); if (WARN_ON(!pending)) return 0; - while ((req = virtqueue_get_buf(viommu...

...fffff00 + +struct viommu_event { + union { + u32 head; + struct virtio_iommu_fault fault; + }; +}; + #define to_viommu_domain(domain) container_of(domain, struct viommu_domain, domain) /* Virtio transport */ @@ -160,12 +175,13 @@ static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent, unsigned int len; int nr_received = 0; struct viommu_request *req, *pending; + struct virtqueue *vq = viommu->vqs[VIOMMU_REQUEST_VQ]; pending = list_first_entry_or_null(sent, struct viommu_request, list); if (WARN_ON(!pending)) return 0; - while ((req = virtqueue_get_buf(viommu...

...t; + u32 head; > + struct virtio_iommu_fault fault; > + }; > +}; > + > #define to_viommu_domain(domain) container_of(domain, struct viommu_domain, domain) > > /* Virtio transport */ > @@ -160,12 +175,13 @@ static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent, > unsigned int len; > int nr_received = 0; > struct viommu_request *req, *pending; > + struct virtqueue *vq = viommu->vqs[VIOMMU_REQUEST_VQ]; > > pending = list_first_entry_or_null(sent, struct viommu_request, list); > if (WARN_ON(!pending)) > return 0; &g...

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