Date: Thu, 19 Aug 1999 00:09:49 +0800 From: Peter Wemm <peter@netplex.com.au> To: Doug Rabson <dfr@nlsystems.com> Cc: alpha@freebsd.org Subject: Re: rman_get_virtual() on alpha Message-ID: <19990818160949.97E171C1F@overcee.netplex.com.au> In-Reply-To: Your message of "Wed, 18 Aug 1999 17:00:56 %2B0100." <Pine.BSF.4.10.9908181659030.72739-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote:
> On Wed, 18 Aug 1999, Peter Wemm wrote:
>
> > Doug Rabson wrote:
> > > On Wed, 18 Aug 1999, Peter Wemm wrote:
> > >
> > > > So, what's the situation these days with rman_get_virtual()? if_fxp ex
plod
> > es
> > > > on the alpha because it allocates SYS_RES_MEMORY and wants the virtual
> > > > address of it, but the alpha still is returning physical addresses it s
eems
> > .
> > > >
> > > > It seems to me we might need some alternative to rman_get_virtual since
it
> > > > doesn't have enough context and is just a hack. Perhaps allocating mem
ory
> > > > and activating a mapping etc needs to be seperate bus methods? That wa
y we
> > > > can allocate memory, and later activate it (pmap_mapdev on x86, BWX, or
> > > > DENSE on Alpha as requested) and free it's kvm mappings?
> > >
> > > The fxp driver should probable use SYS_RES_DENSE to get the right virtual
> > > pointer. It would certainly be a lot cleaner to separate the resource
> > > allocation from the virtual mapping.
> >
> > The question is though, allocating memory resources on the alpha - does it
> > depend on the mapping type (dense vs. bwx)? Or is that decision better
> > left to mapping time? And can we fit this in with bus_space etc? (NetBSD
> > has a bus_space_map() function to map bus space into kvm, maybe we need a
> > parallel to that such that we don't have to expose DENSE/BWX etc mappings
> > to drivers). Or maybe map it in both dense and bwx space and let bus_space
> > use whichever method is convenient?
>
> There is no actual overhead for 'mapping' the resources since we just
> point at the right part of the direct physical->virtual mapped segment.
> The main issue as I see it is that the existing mechanism is ugly.
As I see it, the existing method is broken as it requires putting alpha
arch stuff into generic drivers. Also, how do we know if a given box *has*
got SYS_RES_DENSE support? (ie: bwx instructions)
Also.. SYS_RES_MEMORY corresponds to use of physical memory.. Is there a
1:1 relationship between physical memory and BWX and physical->virtual
mapping space? (ie: is there any management of that space required?) There
is on the x86 since we have to call pmap_mapdev() which allocates KVM which
is never freed under the present design.
rman_[gs]et_virtual() is (IMHO) evil for this very reason since it requires
the parent bus to pre-setup KVM space (on the x86) which may or may not be
used, and we never free it.
I think it should be:
res = BUS_ALLOC_RESOURCE( blah SYS_RES_MEMORY blah)
vaddr = BUS_MAP_MEMORY(dev, res, [alignment, any|dense|bwx|whatever, etc])
and corresponding unmap calls or something - just like with BUS_SETUP_INTR()
etc. On the alpha it'd be a NOP since the hardware does this kinda stuff
for us, but on the x86 we need it for managing kvm wirings.
I pretty much think the whole point of doing a mapping at all (in dense
mode) is so we can go direct and bypass the bus_space_* macros, with the
obvious peril of doing that of course. bus_space_* macros etc have a
specific setup in NetBSD which we don't really have a parallel of, and
probably should as this would solve this problem for working with the
bus_space style interfaces as well.
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990818160949.97E171C1F>