search for: queue_us

...return virtio_queue_get_avail_addr(vdev, vdev->queue_sel) & low; case offsetof(struct virtio_pci_common_cfg, queue_avail) + 4: + assert(size == 4); return virtio_queue_get_avail_addr(vdev, vdev->queue_sel) >> 32; case offsetof(struct virtio_pci_common_cfg, queue_used): + assert(size == 4); return virtio_queue_get_used_addr(vdev, vdev->queue_sel) & low; case offsetof(struct virtio_pci_common_cfg, queue_used) + 4: + assert(size == 4); return virtio_queue_get_used_addr(vdev, vdev->queue_sel) >> 32; defaul...

..._cfg, queue_avail): + return virtio_queue_get_avail_addr(vdev, vdev->queue_sel) & low; + case offsetof(struct virtio_pci_common_cfg, queue_avail) + 4: + return virtio_queue_get_avail_addr(vdev, vdev->queue_sel) >> 32; + case offsetof(struct virtio_pci_common_cfg, queue_used): + return virtio_queue_get_used_addr(vdev, vdev->queue_sel) & low; + case offsetof(struct virtio_pci_common_cfg, queue_used) + 4: + return virtio_queue_get_used_addr(vdev, vdev->queue_sel) >> 32; + default: + return 0; + } +} + +static void virtio_pc...

..._cfg, queue_avail): + return virtio_queue_get_avail_addr(vdev, vdev->queue_sel) & low; + case offsetof(struct virtio_pci_common_cfg, queue_avail) + 4: + return virtio_queue_get_avail_addr(vdev, vdev->queue_sel) >> 32; + case offsetof(struct virtio_pci_common_cfg, queue_used): + return virtio_queue_get_used_addr(vdev, vdev->queue_sel) & low; + case offsetof(struct virtio_pci_common_cfg, queue_used) + 4: + return virtio_queue_get_used_addr(vdev, vdev->queue_sel) >> 32; + default: + return 0; + } +} + +static void virtio_pc...

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,

...> + return virtio_queue_get_avail_addr(vdev, vdev->queue_sel) & low; > + case offsetof(struct virtio_pci_common_cfg, queue_avail) + 4: > + return virtio_queue_get_avail_addr(vdev, vdev->queue_sel) >> 32; > + case offsetof(struct virtio_pci_common_cfg, queue_used): > + return virtio_queue_get_used_addr(vdev, vdev->queue_sel) & low; > + case offsetof(struct virtio_pci_common_cfg, queue_used) + 4: > + return virtio_queue_get_used_addr(vdev, vdev->queue_sel) >> 32; > + default: > + return 0; > +...

On Wed, May 29, 2013 at 10:47:52AM +0930, Rusty Russell wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > > 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

...on and configuration, the Physical Guest Addresses in the queue configuration fields are to be considered as offsets in octets from the start of the corresponding Window. For example for PCI, in the virtio_pci_common_cfg structure these fields are affected: le64 queue_desc; le64 queue_avail; le64 queue_used; For MMIO instead these MMIO Device layout fields are affected: QueueDescLow, QueueDescHigh QueueAvailLow, QueueAvailHigh QueueUsedLow, QueueUsedHigh For PCI a new virtio_pci_cap of cfg type VIRTIO_PCI_CAP_WINDOW_CFG is defined. It contains the following fields: struct virtio_pci_window_cap...

- queue size can actually be 0 which is not a power of 2 - fix capability format. PCI spec says: The layout of the information is vendor specific, except that the byte immediately following the ?Next? pointer in the capability structure is defined to be a length field. This length field provides the number of bytes in the capability structure (including the ID and Next pointer bytes).

On 09.09.2015 08:40, Zhang, Yang Z wrote: > Claudio Fontana wrote on 2015-09-07: >> Coming late to the party, >> >> On 31.08.2015 16:11, Michael S. Tsirkin wrote: >>> Hello! >>> During the KVM forum, we discussed supporting virtio on top >>> of ivshmem. I have considered it, and came up with an alternative >>> that has several advantages

On 09.09.2015 08:40, Zhang, Yang Z wrote: > Claudio Fontana wrote on 2015-09-07: >> Coming late to the party, >> >> On 31.08.2015 16:11, Michael S. Tsirkin wrote: >>> Hello! >>> During the KVM forum, we discussed supporting virtio on top >>> of ivshmem. I have considered it, and came up with an alternative >>> that has several advantages

I've renewed this again, with some comments from HPA. I've tried to keep the new patches separate, so you can see the changes since we last discussed this (and so it's easy to back it out if we decide it's insane). I haven't even looked at the QEMU side so this is completely untested. Comments gratefully received! Rusty. Michael S Tsirkin (1): pci: add pci_iomap_range

I've renewed this again, with some comments from HPA. I've tried to keep the new patches separate, so you can see the changes since we last discussed this (and so it's easy to back it out if we decide it's insane). I haven't even looked at the QEMU side so this is completely untested. Comments gratefully received! Rusty. Michael S Tsirkin (1): pci: add pci_iomap_range