Date: Wed, 18 Aug 1999 12:28:44 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Peter Wemm <peter@netplex.com.au> Cc: Doug Rabson <dfr@nlsystems.com>, alpha@FreeBSD.ORG Subject: Re: rman_get_virtual() on alpha Message-ID: <14266.56422.223568.791717@grasshopper.cs.duke.edu> In-Reply-To: <19990818160949.97E171C1F@overcee.netplex.com.au> References: <Pine.BSF.4.10.9908181659030.72739-100000@salmon.nlsystems.com> <19990818160949.97E171C1F@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm writes:
> 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)
Err, you meant SYS_RES_BWX rather than SYS_RES_DENSE. Everything we
support has dense memory.
> 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.
There's no management required. The virtual addresses get mapped via
the alpha's K0SEG. Eg:
vm_offset_t
pci_cvt_to_bwx(vm_offset_t sparse)
{
if(chipset.cvt_to_bwx)
return ALPHA_PHYS_TO_K0SEG(chipset.cvt_to_bwx(sparse));
else
return NULL;
}
> 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.
This sounds good to me -- I'd like to eliminate driver ifdefs as well.
Would we assume that the 'any' arg to BUS_MAP_MEMORY would translate
to dense space on the alpha?
I suppose for porting a generic driver, BWX space doesn't really even
make much sense. Unless a driver has asm's to exploit it (or exports
it via mmap to a user program which does), or unless the kernel is
compiled with -mcpi=ev56, no bwx instructions are going to be used on
it.
Drew
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?14266.56422.223568.791717>