similar to: [Qemu-devel] [RFC 0/4] virtio-mmio transport

Hi Rusty, Peter (on Cc) got the qemu implementation up and running (thanks!) and provided some useful feedback regarding the spec. To make the long story short, this is what came out of the discussion (feel free to correct me at any point, Peter ;-): diff --git a/virtio-spec.lyx b/virtio-spec.lyx index 6426f8f..79a6498 100644 --- a/virtio-spec.lyx +++ b/virtio-spec.lyx @@ -6681,7 +6681,9 @@ s on

Hi Rusty, Peter (on Cc) got the qemu implementation up and running (thanks!) and provided some useful feedback regarding the spec. To make the long story short, this is what came out of the discussion (feel free to correct me at any point, Peter ;-): diff --git a/virtio-spec.lyx b/virtio-spec.lyx index 6426f8f..79a6498 100644 --- a/virtio-spec.lyx +++ b/virtio-spec.lyx @@ -6681,7 +6681,9 @@ s on

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. >

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 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. >

My apologies, I used Anthony's previous (now obsolete) email. Updated it now & keeping full context below. Sorry. On 10/22/13 19:49, Laszlo Ersek wrote: > Hi, > > "Appendix X: virtio-mmio" in the virtio spec says > > ? 0x040 | RW | QueuePFN > [...] When the Guest stops using the queue it must write zero > (0x0) to this register. >

Hi, "Appendix X: virtio-mmio" in the virtio spec says ? 0x040 | RW | QueuePFN [...] When the Guest stops using the queue it must write zero (0x0) to this register. [...] and Virtqueue Configuration [...] 2. Check if the queue is not already in use: read QueuePFN register, returned value should be zero (0x0). [...] I think this in itself is

Hi, "Appendix X: virtio-mmio" in the virtio spec says ? 0x040 | RW | QueuePFN [...] When the Guest stops using the queue it must write zero (0x0) to this register. [...] and Virtqueue Configuration [...] 2. Check if the queue is not already in use: read QueuePFN register, returned value should be zero (0x0). [...] I think this in itself is

On Fri, 2013-06-21 at 17:41 +0100, Peter Maydell wrote: > On 21 June 2013 17:02, Christopher Covington <cov at codeaurora.org> wrote: > > Would using CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES enumeration > > instead of device tree be any easier? > > My general view is that the kernel command line is > the user's to manipulate, and that QEMU shouldn't > touch it

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?

On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote: > I'm (finally) trying to add virtio-mmio support properly to > QEMU now Fred has put all the refactoring foundations in place. > > 1. One question I've run into is: what should a virtio-mmio transport > with no backend look like to the guest OS? The spec as written > seems to assume that there's always some

On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote: > I'm (finally) trying to add virtio-mmio support properly to > QEMU now Fred has put all the refactoring foundations in place. > > 1. One question I've run into is: what should a virtio-mmio transport > with no backend look like to the guest OS? The spec as written > seems to assume that there's always some