similar to: [RFC] virtio-mmio: Update the device to OASIS spec version

This patch add a support for second version of the virtio-mmio device, which follows OASIS "Virtual I/O Device (VIRTIO) Version 1.0" specification. Main changes: 1. The control register symbolic names use the new device/driver nomenclature rather than the old guest/host one. 2. The driver detect the device version (version 1 is the pre-OASIS spec, version 2 is compatible with

This patch add a support for second version of the virtio-mmio device, which follows OASIS "Virtual I/O Device (VIRTIO) Version 1.0" specification. Main changes: 1. The control register symbolic names use the new device/driver nomenclature rather than the old guest/host one. 2. The driver detect the device version (version 1 is the pre-OASIS spec, version 2 is compatible with

This patch add a support for second version of the virtio-mmio device, which follows OASIS "Virtual I/O Device (VIRTIO) Version 1.0" specification. Main changes: 1. The control register symbolic names use the new device/driver nomenclature rather than the old guest/host one. 2. The driver detect the device version (version 1 is the pre-OASIS spec, version 2 is compatible with

This patch add a support for second version of the virtio-mmio device, which follows OASIS "Virtual I/O Device (VIRTIO) Version 1.0" specification. Main changes: 1. The control register symbolic names use the new device/driver nomenclature rather than the old guest/host one. 2. The driver detect the device version (version 1 is the pre-OASIS spec, version 2 is compatible with

On Tue, Jan 20, 2015 at 06:12:11PM +0000, Pawel Moll wrote: > This patch add a support for second version of the virtio-mmio device, > which follows OASIS "Virtual I/O Device (VIRTIO) Version 1.0" > specification. > > Main changes: > > 1. The control register symbolic names use the new device/driver > nomenclature rather than the old guest/host one. >

On Tue, Jan 20, 2015 at 06:12:11PM +0000, Pawel Moll wrote: > This patch add a support for second version of the virtio-mmio device, > which follows OASIS "Virtual I/O Device (VIRTIO) Version 1.0" > specification. > > Main changes: > > 1. The control register symbolic names use the new device/driver > nomenclature rather than the old guest/host one. >

On Fri, Dec 19, 2014 at 06:38:04PM +0000, Pawel Moll wrote: > This patch add a support for second version of the virtio-mmio device, > which follows OASIS "Virtual I/O Device (VIRTIO) Version 1.0" > specification. > > Main changes: > > 1. The control register symbolic names use the new device/driver > nomenclature rather than the old guest/host one. >

On Fri, Dec 19, 2014 at 06:38:04PM +0000, Pawel Moll wrote: > This patch add a support for second version of the virtio-mmio device, > which follows OASIS "Virtual I/O Device (VIRTIO) Version 1.0" > specification. > > Main changes: > > 1. The control register symbolic names use the new device/driver > nomenclature rather than the old guest/host one. >

On Thu, 2015-01-15 at 16:51 +0000, Michael S. Tsirkin wrote: > > + uint64_t addr = virt_to_phys(info->queue); > > Kernel normally uses u64 for this type. Sure, well spotted. > > + > > + writel(addr & 0xffffffff, > > + vm_dev->base + VIRTIO_MMIO_QUEUE_DESC_LOW); > > + writel((addr

On Thu, 2015-01-15 at 16:51 +0000, Michael S. Tsirkin wrote: > > + uint64_t addr = virt_to_phys(info->queue); > > Kernel normally uses u64 for this type. Sure, well spotted. > > + > > + writel(addr & 0xffffffff, > > + vm_dev->base + VIRTIO_MMIO_QUEUE_DESC_LOW); > > + writel((addr

Hi, On 01/20/2015 01:12 PM, Pawel Moll wrote: > @@ -356,13 +346,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned index, > info->num /= 2; > } > > - /* Activate the queue */ > - writel(info->num, vm_dev->base + VIRTIO_MMIO_QUEUE_NUM); > - writel(VIRTIO_MMIO_VRING_ALIGN, > - vm_dev->base + VIRTIO_MMIO_QUEUE_ALIGN); > -

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?

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/standard-headers/linux/virtio_mmio.h | 141 +++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 include/standard-headers/linux/virtio_mmio.h diff --git a/include/standard-headers/linux/virtio_mmio.h b/include/standard-headers/linux/virtio_mmio.h new file mode 100644 index 0000000..c4b0968 ---

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/standard-headers/linux/virtio_mmio.h | 141 +++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 include/standard-headers/linux/virtio_mmio.h diff --git a/include/standard-headers/linux/virtio_mmio.h b/include/standard-headers/linux/virtio_mmio.h new file mode 100644 index 0000000..c4b0968 ---

Going over the virtio mmio code, I noticed that it doesn't correctly return device config values in LE format when using virtio 1.0. Borrow code from virtio_pci_modern to do this correctly. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Note: untested: QEMU doesn't support virtio 1.0 for virtio-mmio. Pawel, could you please confirm this patch makes sense?

Going over the virtio mmio code, I noticed that it doesn't correctly return device config values in LE format when using virtio 1.0. Borrow code from virtio_pci_modern to do this correctly. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Note: untested: QEMU doesn't support virtio 1.0 for virtio-mmio. Pawel, could you please confirm this patch makes sense?

On Thu, Jan 15, 2015 at 05:32:38PM +0000, Pawel Moll wrote: > On Thu, 2015-01-15 at 16:51 +0000, Michael S. Tsirkin wrote: > > > + uint64_t addr = virt_to_phys(info->queue); > > > > Kernel normally uses u64 for this type. > > Sure, well spotted. > > > > + > > > + writel(addr & 0xffffffff, > > > +

On Thu, Jan 15, 2015 at 05:32:38PM +0000, Pawel Moll wrote: > On Thu, 2015-01-15 at 16:51 +0000, Michael S. Tsirkin wrote: > > > + uint64_t addr = virt_to_phys(info->queue); > > > > Kernel normally uses u64 for this type. > > Sure, well spotted. > > > > + > > > + writel(addr & 0xffffffff, > > > +

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