From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZ2pX-00076E-BR for qemu-devel@nongnu.org; Fri, 09 Dec 2011 10:57:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RZ2pW-0008RW-37 for qemu-devel@nongnu.org; Fri, 09 Dec 2011 10:57:47 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:42022) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZ2pW-0008RO-0t for qemu-devel@nongnu.org; Fri, 09 Dec 2011 10:57:46 -0500 Received: by qcsd15 with SMTP id d15so2698897qcs.4 for ; Fri, 09 Dec 2011 07:57:45 -0800 (PST) Message-ID: <4EE22FF4.5050903@codemonkey.ws> Date: Fri, 09 Dec 2011 09:57:40 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1321282528-19070-1-git-send-email-peter.maydell@linaro.org> <4EC41574.5080606@codemonkey.ws> <201112091516.07644.paul@codesourcery.com> In-Reply-To: <201112091516.07644.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/4] virtio-mmio transport List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Peter Maydell , qemu-devel@nongnu.org, Pawel Moll , Paolo Bonzini On 12/09/2011 09:16 AM, Paul Brook wrote: > [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. Can we remove syborg virtio then? Regards, Anthony Liguori > > Paul >