Date: Thu, 15 Oct 2009 11:18:49 -0400 From: John Baldwin <jhb@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, xcllnt@mac.com, src-committers@freebsd.org Subject: Re: svn commit: r197969 - head/sys/conf Message-ID: <200910151118.50619.jhb@freebsd.org> In-Reply-To: <20091015.085910.-520412456.imp@bsdimp.com> References: <200910141738.43910.jhb@freebsd.org> <200910150833.54252.jhb@freebsd.org> <20091015.085910.-520412456.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 15 October 2009 10:59:10 am M. Warner Losh wrote: > In message: <200910150833.54252.jhb@freebsd.org> > John Baldwin <jhb@freebsd.org> writes: > : On Wednesday 14 October 2009 6:11:15 pm M. Warner Losh wrote: > : > In message: <200910141738.43910.jhb@freebsd.org> > : > John Baldwin <jhb@freebsd.org> 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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910151118.50619.jhb>