Peter Maydell
2013-Jun-21 15:23 UTC
what should a virtio-mmio transport without a backend look like?
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. >>> (The idea is that QEMU might just always instantiate say 8 >>> mmio transports, and then whether they actually have a >>> blk/net/whatever backend depends on user options).> Might it be reasonably easy to just not enumerate unused transports > in the device tree or kernel parameters?At least for QEMU, the backend that plugs into the transport isn't created until after the machine model has created transports and put together the device tree blob. So we don't really have the information about what devices are going to appear at the point we're doing this. thanks -- PMM
Christopher Covington
2013-Jun-21 16:02 UTC
what should a virtio-mmio transport without a backend look like?
Hi Peter, On 06/21/2013 11:23 AM, Peter Maydell wrote:> 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. >>>> (The idea is that QEMU might just always instantiate say 8 >>>> mmio transports, and then whether they actually have a >>>> blk/net/whatever backend depends on user options). > >> Might it be reasonably easy to just not enumerate unused transports >> in the device tree or kernel parameters? > > At least for QEMU, the backend that plugs into the transport > isn't created until after the machine model has created > transports and put together the device tree blob. So we don't > really have the information about what devices are going to > appear at the point we're doing this.Would using CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES enumeration instead of device tree be any easier? How does the back end know which devices to create? Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation.
Peter Maydell
2013-Jun-21 16:41 UTC
what should a virtio-mmio transport without a backend look like?
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 odd kernel command line arguments in order to make things work.) (Having talked with Grant Likely I now have a reasonable plan for manipulating the dtb to add virtio nodes, so I'm happy that that's the right way to go.) 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 :-)> How does the back end know which devices to create?Anything specified via -device on the QEMU command line is created after the board model has initialized. When a virtio-blk-backend (or whatever) is created it's automatically plugged into the first available matching bus (in the same way that if you create a PCI card via -device it plugs into the first available PCI slot). -- PMM
Maybe Matching Threads
- what should a virtio-mmio transport without a backend look like?
- what should a virtio-mmio transport without a backend look like?
- what should a virtio-mmio transport without a backend look like?
- what should a virtio-mmio transport without a backend look like?
- what should a virtio-mmio transport without a backend look like?