From owner-svn-src-all@FreeBSD.ORG Thu Oct 15 18:32:09 2009 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 83AF9106566C; Thu, 15 Oct 2009 18:32:06 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: John Baldwin Date: Thu, 15 Oct 2009 14:31:50 -0400 User-Agent: KMail/1.6.2 References: <200910141738.43910.jhb@freebsd.org> <20091015.085910.-520412456.imp@bsdimp.com> <200910151118.50619.jhb@freebsd.org> In-Reply-To: <200910151118.50619.jhb@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200910151431.53236.jkim@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, xcllnt@mac.com, "M. Warner Losh" , src-committers@FreeBSD.org Subject: Re: svn commit: r197969 - head/sys/conf X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 18:32:09 -0000 On Thursday 15 October 2009 11:18 am, John Baldwin wrote: > On Thursday 15 October 2009 10:59:10 am M. Warner Losh wrote: > > In message: <200910150833.54252.jhb@freebsd.org> > > > > John Baldwin writes: > > : On Wednesday 14 October 2009 6:11:15 pm M. Warner Losh wrote: > > : > In message: <200910141738.43910.jhb@freebsd.org> > > : > > > : > John Baldwin writes: > > : > : On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar wrote: > > : > : > On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: > > : > : > > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote: > > : > : > >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: > > : > : > >>> I can't be more clear than this. You keep ignoring > > : > : > >>> me, and it > > is > > > : > : > >>> very > > : > : > >>> frustrating. > > : > : > >> > > : > : > >> I'm not ignoring you. I'm still talking. You simply > > : > : > >> haven't > > convinced > > > : > : > >> me. While it's possible (likely?) that I don't > > : > : > >> understand the > > issues, > > > : > : > >> all you've achieved so far is that I'm more convinced > > : > : > >> that > > limiting > > > : > : > >> orm(4) to i386 and amd64 is the right thing, because > > : > : > >> the > > alternative > > > : > : > >> is not at all appealing. > > : > : > >> > > : > : > >>> The problem is that the > > : > : > >>> powerpc and itanium isa modules allow memory ranges > > : > : > >>> that > > shouldn't > > > : > : > >>> be > > : > : > >>> allowed. That's the platform specific code that > > : > : > >>> needs to be > > fixed. > > > : > : > >> isa_set_resource() is MI code and it happily adds > > : > : > >> whatever > > resources > > > : > : > >> a driver wants. The only chance MD code has is to fail > > : > : > >> the allocation, > > : > : > >> but since the whole ISA code bypasses the newbus > > : > : > >> hierarchy, > > there's > > > : > : > >> no way we know in the isa MD code what is valid and > > : > : > >> what isn't > > unless > > > : > : > >> we add kluges to platform code. > > : > : > >> > > : > : > >> If you want to fix it for real, does that mean fix it > > : > : > >> for real or does that mean add kluges to platform > > : > : > >> code? > > : > : > >> > > : > : > >> Shouldn't we have ISA bridges obtain the set of valid > > : > : > >> resources from their parent in the newbus hierarchy? > > : > : > > > > : > : > > Hmm, can we even know that? PCI-ISA bridges in x86 at > > : > : > > least don't have any > > : > : > > I/O limit registers like PCI-PCI bridges, instead they > > : > : > > are subtractively > > : > : > > decoded, i.e. they "eat" any memory request that no one > > : > : > > else > > claims. > > > : > : > The key here being requests that reach the PCI-ISA > > : > : > bridge. It's > > entirely > > > : > : > platform specific which I/O memory addresses generated by > > : > : > the CPU > > gets > > > : > : > decoded and forwarded in such a way that it's visible to > > : > : > the PCI-ISA bridge. This is what needs to be obtained > > : > : > from the parent in the > > newbus > > > : > : > hierarchy. Rather than hardcoding [0xC0000 .. 0x100000> > > : > : > as the ISA option > > : > : > ROM memory range, it should be something like > > [isa_mem_base+0xC0000 .. > > > : > : > isa_mem_base + 0x100000> or even [isa_rom_base .. > > : > : > isa_rom_base + 0x40000>. > > : > : > > : > : That might certainly be a reasonable IVAR for isab(4) to > > : > : provide to > > isa(4): a > > > : > : ROM base. However, orm(4) should be enabled for all ISA > > : > : bridges > > assuming > > > : > : that is fixed. OTOH, the way many bus drivers I've seen > > : > : handle this > > so far > > > : > : is to change the base address of SYS_RES_MEMORY objects as > > : > : they pass > > through > > > : > : the relevant bridge so that the actual memory address is > > : > : properly > > adjusted > > > : > : when it gets to the equivalent of the nexus. This is how > > : > : many of the Foo->PCI bridges in arm that I've looked at > > : > : work, and I think this is > > more > > > : > : inline with Warner's original patch which is to allow the > > : > : various platform-specific ISA bridge drivers reject memory > > : > : ranges they do not > > decode > > > : > : and provide any needed adjustments to ranges they do decode > > : > : to > > transform them > > > : > : into suitable resources for their parent. Then orm(4) > > : > : would just see > > it's > > > : > : attempts to do bus_alloc_resource() fail and end up DTRT. > > : > : Given that, > > I do > > > : > : think this logic belongs in the ISA bridge drivers rather > > : > : than in > > individual > > > : > : ISA drivers. We don't make ISA peripheral drivers add > > an 'isa_mem_base' or > > > : > : equivalent to their I/O resources, and in terms of I/O > > : > : resources, > > orm(4) is > > > : > : just a special blackhole device (much like the ACPI or > > : > : PnPBIOS system resource devices, or the ram0 or apic0 > > : > : devices on x86). > > : > > > : > This is exactly what I've been trying to say: the memory > > : > addresses that orm is using are ISA BUS addresses. These > > : > just happen to map 1:1 on x86, but will map to something else > > : > on other platforms. But our kernel API is that the driver > > : > requests the bus address, and that any necessary translation > > : > happen in the bus_space layer. > > : > > > : > I disagree that it belongs entirely in the isa bridge > > : > drivers. They may communicate information to the bus_space > > : > implementation, but it is bus_space that ultimately does this > > : > translation. > > : > > : I think it actually depends on the platform as to where it > > : belongs. If > > you > > > : have some Foo->ISA bridge that uses a window on the Foo bus to > > : map ISA > > space, > > > : then I think it makes sense to handle that in the Foo->ISA > > : bridge, > > especially > > > : if it is a relocatable window. If the ISA bus is instead > > : assigned a fixed range in the system address space then that > > : probably belongs in the > > bus_space > > > : support. > > > > I'd think it would be the opposite. bus_space needs to know how > > to map the request, since it is the last one involved. If this > > is mappable or movable, then it needs to know that too. > > It depends I think. If the Foo bus just maps a Foo memory resource > and then sub-allocates that to satisfy ISA ranges then from > bus_space's perspective it is just working with Foo resources. It > would never know about ISA nor would it need to know. > > > However, adjusting the resources that you give to a child on the > > way through the bridge is just assisting bus_space doing the > > right thing if the bus_space on that architecture just implements > > one or two global spaces. > > I think we are mostly agreeing actually. My main statement is that > how ISA memory resources are actually mapped, etc. is > platform-dependent but that different platforms may implement that > support using different means. This is actually very interesting discussion for me because one of my pet projects is extending x86bios to support non-PC architectures. If anyone is interested, the current source tarball is here: http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 Especially, please see the code around #ifdef X86BIOS_COMPAT_ARCH. Basically, mapping I/O ports and orm(4) is missing. We don't have to implement I/O ports but orm(4) vs. bus_space(9) is critical to make it a reality. Please consider it as a real practical example for orm, not just a blackhole driver. :-) Jung-uk Kim