swi_vm() and busdma_swi()?

Pratyush Kshirsagar pratyush.kshirsagar at gmail.com
Tue Nov 30 21:56:16 PST 2010

Sepherosa Ziehau <sepherosa <at> gmail.com> writes:

> On Wed, Dec 1, 2010 at 12:19 PM, Venkatesh Srinivas
> <me <at> endeavour.zapto.org> wrote:
> > On Tue, Nov 30, 2010 at 9:42 PM, Sepherosa Ziehau <sepherosa <at> gmail.com>
> >> On Wed, Dec 1, 2010 at 6:38 AM, Venkatesh Srinivas
> >> <me <at> endeavour.zapto.org> wrote:
> >>> Hi,
> >>>
> >>> In the per-mach busdma code, busdma_swi() walks a callback list under
> >>
> >> busdma_swi() should be deprecated and removed, however, before that
> >> you will have to fix some old drivers bus_dmamap_load()'s callback
> >> logic first (all of these old drivers should be marked as non-mpsafe).
> >>
> >> Best Regards,
> >> sephe
> >
> > Does this mean those drivers already don't function on amd64?
> If the system is short of bounce pages and the buffer to be loaded
> needs to be bounced (i.e. needs to be copied to the address that is
> accessible to device.  This usually happens on the system w/ more than
> 4Gbytes memory, since most old devices can't access physical addresses
> above 4Gbytes), then those drivers will not work under these
> situation.
> Best Regards,
> sephe

With respect to what spehe wrote, I want to clarify my doubts. 
I am working on writing the virtio drivers/ porting from NetBSD to DFBSD. 
So, does the above 4Gbytes constraint hold for this drivers also, I think they
should but how come this happen for bounce pages. 
And are this bounce pages placed in the memory hole configured for systems with
memory more than the accessible range of devices.

>>>An arbitrary area of virtual memory may be loaded into a map. Each page of
this memory will be checked for conformance to the map requirement. If it
conforms then it is left at its original location. If it is not then a fresh
con-formant “bounce page” is allocated and used as intermediate storage. <<<<

- Pratysuh.

More information about the Kernel mailing list