From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwHoe-0005Jj-VZ for qemu-devel@nongnu.org; Mon, 08 Jul 2013 16:13:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UwHod-0001Cw-Sx for qemu-devel@nongnu.org; Mon, 08 Jul 2013 16:13:44 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:56269) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwHod-0001Cr-N1 for qemu-devel@nongnu.org; Mon, 08 Jul 2013 16:13:43 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 8 Jul 2013 14:13:03 -0600 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 4C1D81FF001C for ; Mon, 8 Jul 2013 14:07:41 -0600 (MDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r68K97Mj58130494 for ; Mon, 8 Jul 2013 16:09:10 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r68K91WW017125 for ; Mon, 8 Jul 2013 16:09:01 -0400 From: Anthony Liguori In-Reply-To: References: <1372338255-3934-1-git-send-email-peter.maydell@linaro.org> <39E5AB85-E7DD-4B9F-9F6F-F80CA6FCAC11@suse.de> <83A07262-ED9A-4E5A-BC11-5B357F5B4996@suse.de> Date: Mon, 08 Jul 2013 15:08:56 -0500 Message-ID: <87li5gbyqv.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 0/8] Add virtio-mmio and use it in vexpress List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Alexander Graf Cc: KONRAD Frederic , David Gibson , kvmarm@lists.cs.columbia.edu, qemu-devel@nongnu.org, patches@linaro.org Peter Maydell writes: > On 8 July 2013 14:45, Alexander Graf wrote: >> On 08.07.2013, at 15:23, Peter Maydell wrote: >>> Now I'm completely confused. Why would assigned devices >>> have anything to do with this? Can you explain in more >>> detail, because I don't really see what you're suggesting? >> >> The only missing link we have to create any device using -device >> on the command line is the IRQ line enumeration. If we can allocate >> IRQ lines automatically, we can put any command line given -device >> onto our main system bus that is non-pci, non-isa. > > If the user is expected to be able to get the MMIO address > right (which they'd have to specify on the command line > somehow too) why not require them to specify the IRQ number > while they're doing it? I'm a bit suspicious of anything > that requires the user to specify to that level of detail > though, since it requires a lot of inside knowledge about the > board. > > This is the whole reason for having the separate transport: > the board gets to take care of the board specific detail of > how to wire up the transport, and the user just asks to > create the backends that plug automatically into it. > The virtio command line options are complicated and confusing > enough as it is. > >> So if we want to ever support VFIO for platform devices, >> the user will want to pass -device vfio-ahci,foo=bar on >> the command line to assign an AHCI device. > > This appears to be seriously short on actually specifying > enough information to wire a device up. > >> The only infrastructure blocker we have for that today >> is the IRQ allocation. > > DMA lines? Specifying the right location in the address space? > >> Maybe we could even try to be as smart as putting the MMIO >> regions into guest address space intelligently automatically. > > This sounds likely to cause problems with migration unless > we can guarantee that we always pick the same place. I think we're trying to fit a square peg into a round hole. virtio-mmio is a virtio transport where each device has a dedicated set of system resources. Alex, it sounds like you want virtio-mmio-bus which would be a single set of system resources that implemented a virtio bus on top of it. Regards, Anthony Liguori > > -- PMM