From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZ2BQ-0001F2-St for qemu-devel@nongnu.org; Fri, 09 Dec 2011 10:16:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RZ2BM-0001JO-NE for qemu-devel@nongnu.org; Fri, 09 Dec 2011 10:16:20 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:65080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZ2BM-0001Iw-Ir for qemu-devel@nongnu.org; Fri, 09 Dec 2011 10:16:16 -0500 From: Paul Brook Date: Fri, 9 Dec 2011 15:16:06 +0000 References: <1321282528-19070-1-git-send-email-peter.maydell@linaro.org> <4EC41574.5080606@codemonkey.ws> In-Reply-To: <4EC41574.5080606@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112091516.07644.paul@codesourcery.com> Subject: Re: [Qemu-devel] [RFC 0/4] virtio-mmio transport List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Peter Maydell , Pawel Moll , Paolo Bonzini [Replying to various bits of this thread all at once] > * you have to specify which kind of virtio device you want in the > board model. In particular this means that for virtio-blk the user > has to say "-drive if=none,file=whatever.img,id=myimg > -global virtio-blk-mmio.drive=myimg" or the virtio-blk layer will > refuse to start, which is not at all userfriendly This is pretty lame. I see two or three bugs here: 1) We're greating virtio devices unconditionally. Much better would be to have devices be allocated as necessary. e.g. unless the user explicitly requests otherwise, put the first device at a particular address, and subsequent devices at sequential addresses. The guest OS can then easily probe them to see which are present. I guess a null virtio device might make sense to avoid accessing undefined memory regions. For the vexpress board the logic tile site (0xc0000000) seems like a sensible location. Your current choice of an area reserved by the southbridge seems somewhat questionable. 2) virtio-blk fails if no drive is connected. I guess you could call this a feature, which means you must fix (1). If not then I think it's reasonable for hardcoded board devices should also use hardcoded drive IDs. i.e. we act as if the user specified "-global virtio-blk-mmio.drive=virtio" or similar 3) "qemu -drive if=virtio" assmes you want PCI virtio. Either we consider this an obsolete legacy option and document it as such, or fix it as part of (1). In the latter case it's probably going to do the wrong thing on boards that have both virtio-mmio and PCI (there are at least two correct answers). >[...] > Correct. Syborg virtio was something Paul Brook did bit is not an > "official" virtio transport as far as Linux or the spec is concerned. > > I'm not sure what guest software uses the syborg virtio transport. It is/was a virtual reference platform for SymbianOS. However since then the Symbian Foundation got shot in the back of the head and the rest of Nokia jumped ship to Windows, so I'd be surprised if anyone really cares about it. Paul