From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcmGX-0007Qt-AC for qemu-devel@nongnu.org; Fri, 01 Jul 2011 18:32:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcmGV-0005TT-9n for qemu-devel@nongnu.org; Fri, 01 Jul 2011 18:32:49 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:43112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcmGV-0005TD-4x for qemu-devel@nongnu.org; Fri, 01 Jul 2011 18:32:47 -0400 Received: by gxk26 with SMTP id 26so1748509gxk.4 for ; Fri, 01 Jul 2011 15:32:46 -0700 (PDT) Message-ID: <4E0E4B0B.2080407@codemonkey.ws> Date: Fri, 01 Jul 2011 17:32:43 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <9F6FE96B71CF29479FF1CDC8046E1503165EEB@039-SN1MPN1-003.039d.mgd.msft.net> <1309481894.14501.230.camel@pasglop> <4E0DB945.4070203@codemonkey.ws> <20110701114301.08d0154b@schlenkerla.am.freescale.net> In-Reply-To: <20110701114301.08d0154b@schlenkerla.am.freescale.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] device assignment for embedded Power List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: Wood Scott-B07421 , "joerg.roedel@amd.com" , "qemu-devel@nongnu.org" , Alexander Graf , "blauwirbel@gmail.com" , Yoder Stuart-B08248 , "alex.williamson@redhat.com" , "paul@codesourcery.com" , "dwg@au1.ibm.com" , "armbru@redhat.com" On 07/01/2011 11:43 AM, Scott Wood wrote: > On Fri, 1 Jul 2011 07:10:45 -0500 > Anthony Liguori wrote: > >> I agree in principle but I think it should be done in a slightly >> different way. >> >> I think we ought to support composing a device by passthrough. For >> instance, something like: >> >> [physical-device "mydev"] >> region[0].file = "/dev/mem" >> region[0].guest_address = "0x42232000" >> region[0].file_offset = "0x23423400" >> region[0].size = "4096" >> irq[0].guest_irq = "10" >> irq[0].host_irq = "10" >> >> This should be independent of anything to do with device tree. This >> would be useful for x86 too to assign platform devices (like the HPET). > > That's fine, as long as there's something layered on top of it for the case > where we do want to reference something in the device tree. > > However, we'll need to address the question of what it means to say "irq 10" It depends on what the bus is. If you're going to declare "system bus" which is sort of what we call ISA for the PC, then it can map trivially to the interrupt controller's inputs. > -- outside of PC-land there often isn't a global IRQ numberspace that isn't > a fiction created by some software layer. PC's don't have a global IRQ number space FWIW. When we say: -device isa-serial,irq=4 This really means, "ISA irq 4", which is mapped to the PIIX3 and then routed through GSI, then the APIC architecture to correspond to some interrupt for some physical CPU. > Addressing this is one of the > device tree's strengths. Not really. There's nothing magical about the device tree. It's just a guest visible description of the platform hardware that isn't probe-able in some bus framework. ACPI does exactly the same thing. I'll concede that the device tree is far nicer than ACPI but again, it's not magical :-) Regards, Anthony Liguori > -Scott > >