search for: queue_en

...rtio/virtio_pci_modern.c +++ b/drivers/virtio/virtio_pci_modern.c @@ -294,7 +294,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device *vp_dev, /* Check if queue is either not available or already active. */ num = ioread16(&cfg->queue_size); - if (!num || ioread8(&cfg->queue_enable)) + if (!num || ioread16(&cfg->queue_enable)) return ERR_PTR(-ENOENT); if (num & (num - 1)) { @@ -394,7 +394,7 @@ static int vp_modern_find_vqs(struct virtio_device *vdev, unsigned nvqs, */ list_for_each_entry(vq, &vdev->vqs, list) { iowrite16(vq->index, &amp...

...rtio/virtio_pci_modern.c +++ b/drivers/virtio/virtio_pci_modern.c @@ -294,7 +294,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device *vp_dev, /* Check if queue is either not available or already active. */ num = ioread16(&cfg->queue_size); - if (!num || ioread8(&cfg->queue_enable)) + if (!num || ioread16(&cfg->queue_enable)) return ERR_PTR(-ENOENT); if (num & (num - 1)) { @@ -394,7 +394,7 @@ static int vp_modern_find_vqs(struct virtio_device *vdev, unsigned nvqs, */ list_for_each_entry(vq, &vdev->vqs, list) { iowrite16(vq->index, &amp...

...amp;cfg->queue_avail_hi); - vp_iowrite64_twopart(hw->vring[i].used, &cfg->queue_used_lo, - &cfg->queue_used_hi); - vp_iowrite16(hw->vring[i].size, &cfg->queue_size); - ifcvf_set_vq_state(hw, i, hw->vring[i].last_avail_idx); - vp_iowrite16(1, &cfg->queue_enable); - } +int ifcvf_set_vq_address(struct ifcvf_hw *hw, u16 qid, u64 desc_area, + u64 driver_area, u64 device_area) +{ + struct virtio_pci_common_cfg __iomem *cfg = hw->common_cfg; + + vp_iowrite16(qid, &cfg->queue_select); + vp_iowrite64_twopart(desc_area, &cfg->queue_desc_lo,...

...amp;cfg->queue_avail_hi); - vp_iowrite64_twopart(hw->vring[i].used, &cfg->queue_used_lo, - &cfg->queue_used_hi); - vp_iowrite16(hw->vring[i].size, &cfg->queue_size); - ifcvf_set_vq_state(hw, i, hw->vring[i].last_avail_idx); - vp_iowrite16(1, &cfg->queue_enable); - } +int ifcvf_set_vq_address(struct ifcvf_hw *hw, u16 qid, u64 desc_area, + u64 driver_area, u64 device_area) +{ + struct virtio_pci_common_cfg __iomem *cfg = hw->common_cfg; + + vp_iowrite16(qid, &cfg->queue_select); + vp_iowrite64_twopart(desc_area, &cfg->queue_desc_lo,...

...; Thanks, > >> > Rusty. > >> > >> I think PCI can optionally support atomic 64 bit accesses, but not all > >> architectures can generate them. > > > > Ping. Going to change this in the layout struct? > > Not sure what you mean.... We use a queue_enable field, so it doesn't > matter if the accesses aren't atomic for that. > > Cheers, > Rusty. I mean the struct should have separate _lo and _hi fields. Otherwise I have to do: + case offsetof(struct virtio_pci_common_cfg, queue_desc): + assert(size == 4); + retu...

...size); return virtio_queue_get_num(vdev, vdev->queue_sel); case offsetof(struct virtio_pci_common_cfg, queue_msix_vector): + assert(size == sizeof cfg.queue_msix_vector); return virtio_queue_vector(vdev, vdev->queue_sel); case offsetof(struct virtio_pci_common_cfg, queue_enable): + assert(size == sizeof cfg.queue_enable); /* TODO */ return 0; case offsetof(struct virtio_pci_common_cfg, queue_notify_off): + assert(size == sizeof cfg.queue_notify_off); return vdev->queue_sel; case offsetof(struct virtio_pci_common_cfg, queu...

The spec is very clear on this: 4.1.3.1 Driver Requirements: PCI Device Layout The driver MUST access each field using the ?natural? access method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses for 16-bit fields and 8-bit accesses for 8-bit fields. Add type-safe wrappers to prevent access with incorrect width. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

The spec is very clear on this: 4.1.3.1 Driver Requirements: PCI Device Layout The driver MUST access each field using the ?natural? access method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses for 16-bit fields and 8-bit accesses for 8-bit fields. Add type-safe wrappers to prevent access with incorrect width. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

Formerly, ifcvf driver has implemented a lazy-initialization mechanism for the virtqueues and other config space contents, it would store all configurations that passed down from the userspace, then load them to the device config space upon DRIVER_OK. This can not serve live migration, so this series implement an immediate initialization mechanism, which means rather than the former store-load

Formerly, ifcvf driver has implemented a lazy-initialization mechanism for the virtqueues and other config space contents, it would store all configurations that passed down from the userspace, then load them to the device config space upon DRIVER_OK. This can not serve live migration, so this series implement an immediate initialization mechanism, which means rather than the former store-load

Anthony Liguori <aliguori at us.ibm.com> writes: > "Michael S. Tsirkin" <mst at redhat.com> writes: >> + case offsetof(struct virtio_pci_common_cfg, device_feature_select): >> + return proxy->device_feature_select; > > Oh dear no... Please use defines like the rest of QEMU. It is pretty ugly. Yet the structure definitions are descriptive,

Anthony Liguori <aliguori at us.ibm.com> writes: > "Michael S. Tsirkin" <mst at redhat.com> writes: >> + case offsetof(struct virtio_pci_common_cfg, device_feature_select): >> + return proxy->device_feature_select; > > Oh dear no... Please use defines like the rest of QEMU. It is pretty ugly. Yet the structure definitions are descriptive,

...n Wang wrote: > +static void vp_vdpa_set_vq_ready(struct vdpa_device *vdpa, > + u16 qid, bool ready) > +{ > + struct vp_vdpa *vp_vdpa = vdpa_to_vp(vdpa); > + > + vp_iowrite16(qid, &vp_vdpa->common->queue_select); > + vp_iowrite16(ready, &vp_vdpa->common->queue_enable); > +} > + Looks like this needs to check and just skip the write if ready == 0, right? Of course vdpa core then insists on calling vp_vdpa_get_vq_ready which will warn. Maybe just drop the check from core, move it to drivers which need it? ... > +static const struct pci_device_id...

...n Wang wrote: > +static void vp_vdpa_set_vq_ready(struct vdpa_device *vdpa, > + u16 qid, bool ready) > +{ > + struct vp_vdpa *vp_vdpa = vdpa_to_vp(vdpa); > + > + vp_iowrite16(qid, &vp_vdpa->common->queue_select); > + vp_iowrite16(ready, &vp_vdpa->common->queue_enable); > +} > + Looks like this needs to check and just skip the write if ready == 0, right? Of course vdpa core then insists on calling vp_vdpa_get_vq_ready which will warn. Maybe just drop the check from core, move it to drivers which need it? ... > +static const struct pci_device_id...

...with the new layout code in Rusty's new layout branch. At the moment all fields are in the same memory BAR (bar 2). This will be used to test performance and compare memory, io and hypercall latency. Compiles but does not work yet. Migration isn't handled yet. It's not clear what do queue_enable/queue_disable fields do, not yet implemented. Gateway for config access with config cycles not yet implemented. Sending out for early review/flames. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- hw/virtio/virtio-pci.c | 393 +++++++++++++++++++++++++++++++++++++++++++--...

...with the new layout code in Rusty's new layout branch. At the moment all fields are in the same memory BAR (bar 2). This will be used to test performance and compare memory, io and hypercall latency. Compiles but does not work yet. Migration isn't handled yet. It's not clear what do queue_enable/queue_disable fields do, not yet implemented. Gateway for config access with config cycles not yet implemented. Sending out for early review/flames. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- hw/virtio/virtio-pci.c | 393 +++++++++++++++++++++++++++++++++++++++++++--...

On Mon, Dec 12, 2011 at 01:49:13PM +0200, Michael S. Tsirkin wrote: > On Mon, Dec 12, 2011 at 09:15:03AM +1030, Rusty Russell wrote: > > On Sun, 11 Dec 2011 11:42:56 +0200, "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Thu, Dec 08, 2011 at 09:09:33PM +1030, Rusty Russell wrote: > > > > +/* There is no iowrite64. We use two 32-bit ops. */

...used to easily determine which fields are to be initialized, and the queue window id registers that are used to reach the data structures. This feature under OPTION 2 adds the requirement to enable all virtqueues before the DRIVER_OK (which is already done in practice, as usual by writing 1 to the queue_enable field). Driver attempts to read back from the queue_enable field for a queue which has not been also enabled by the remote peer will have the device return 0 (disabled) until the remote peer has also initialized its own share of the data structures for the same virtqueue as it appears in the re...

...ew layout branch. > > At the moment all fields are in the same memory BAR (bar 2). > This will be used to test performance and compare > memory, io and hypercall latency. > > Compiles but does not work yet. > Migration isn't handled yet. > > It's not clear what do queue_enable/queue_disable > fields do, not yet implemented. > > Gateway for config access with config cycles > not yet implemented. > > Sending out for early review/flames. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > hw/virtio/virtio-pci.c | 39...

...SI_QUEUE_OFF, &cfg->queue_msix_vector); > + if (ioread16(&cfg->queue_msix_vector) == > + VIRTIO_MSI_NO_VECTOR) { > + IFC_ERR(ifcvf->dev, > + "No msix vector for queue %u.\n", i); > + return -1; > + } > + > + iowrite16(1, &cfg->queue_enable); This queue_enable should be done through set_vq_ready() from virtio core. > + } > + > + return 0; > +} > + > +static void ifcvf_hw_disable(struct ifcvf_hw *hw) > +{ > + struct virtio_pci_common_cfg *cfg; > + u32 i; > + > + cfg = hw->common_cfg; > + iow...