similar to: what should a virtio-mmio transport without a backend look like?

On 21 June 2013 19:45, Christopher Covington <cov at codeaurora.org> wrote: > You were proposing to use a valid/existing MagicValue/Version/VendorID with a > special DeviceID that does nothing. I'm saying why not use a valid/existing > MagicValue/Version/VendorID/DeviceID with a special parameter setting, size=0, > that does nothing? Ah, I see. Well, it sounds from your

On 21 June 2013 19:45, Christopher Covington <cov at codeaurora.org> wrote: > You were proposing to use a valid/existing MagicValue/Version/VendorID with a > special DeviceID that does nothing. I'm saying why not use a valid/existing > MagicValue/Version/VendorID/DeviceID with a special parameter setting, size=0, > that does nothing? Ah, I see. Well, it sounds from your

On 21 June 2013 19:01, Christopher Covington <cov at codeaurora.org> wrote: > Anyhow, I just did a quick experiment with 0-size block devices, and they seem > to work for me, although trying to mount the device yields the confusing > message, "mount: mounting /dev/vda on mount failed: Invalid argument". I'm confused -- what's the significance of zero size block

On 21 June 2013 19:01, Christopher Covington <cov at codeaurora.org> wrote: > Anyhow, I just did a quick experiment with 0-size block devices, and they seem > to work for me, although trying to mount the device yields the confusing > message, "mount: mounting /dev/vda on mount failed: Invalid argument". I'm confused -- what's the significance of zero size block

Hi Peter, On 06/20/2013 07:08 AM, Pawel Moll wrote: > 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

On 06/22/2013 06:51 AM, Peter Maydell wrote: > On 21 June 2013 19:45, Christopher Covington <cov at codeaurora.org> wrote: >> You were proposing to use a valid/existing MagicValue/Version/VendorID with a >> special DeviceID that does nothing. I'm saying why not use a valid/existing >> MagicValue/Version/VendorID/DeviceID with a special parameter setting, size=0,

On 06/21/2013 02:28 PM, Peter Maydell wrote: > On 21 June 2013 19:01, Christopher Covington <cov at codeaurora.org> wrote: >> Anyhow, I just did a quick experiment with 0-size block devices, and they seem >> to work for me, although trying to mount the device yields the confusing >> message, "mount: mounting /dev/vda on mount failed: Invalid argument". >

On 20 June 2013 13:58, Christopher Covington <cov at codeaurora.org> wrote: >> On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote: >>> 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 backend present. >>>

On 20 June 2013 13:58, Christopher Covington <cov at codeaurora.org> wrote: >> On Thu, 2013-06-20 at 11:29 +0100, Peter Maydell wrote: >>> 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 backend present. >>>

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 21 June 2013 17:47, Pawel Moll <pawel.moll at arm.com> wrote: > On Fri, 2013-06-21 at 17:41 +0100, Peter Maydell wrote: >> As it happens, if you use the command line to specify >> a virtio device it doesn't make the same complaint about >> bad magic number as if you specify it via dtb, but that >> should probably be fixed in the kernel :-) > > I

On 21 June 2013 17:47, Pawel Moll <pawel.moll at arm.com> wrote: > On Fri, 2013-06-21 at 17:41 +0100, Peter Maydell wrote: >> As it happens, if you use the command line to specify >> a virtio device it doesn't make the same complaint about >> bad magic number as if you specify it via dtb, but that >> should probably be fixed in the kernel :-) > > I

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 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 at all (just pass it through). (Conversely, QEMU shouldn't require the user to specify

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 at all (just pass it through). (Conversely, QEMU shouldn't require the user to specify

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 Thu, 2015-01-15 at 18:29 +0000, Michael S. Tsirkin wrote: > On Thu, Jan 15, 2015 at 06:11:17PM +0000, Pawel Moll wrote: > > On Thu, 2015-01-15 at 17:51 +0000, Michael S. Tsirkin wrote: > > > > > I think you shouldn't use VIRTIO_MMIO_VRING_ALIGN in non-legacy code: > > > > > it's a legacy thing. > > > > > > > > But I still