Re: uvm objects with physical address constraints

[Matt Thomas <matt%3am-software.com@localhost>]

On May 20, 2014, at 1:40 PM, Taylor R Campbell <riastradh%NetBSD.org@localhost> 
wrote:

> DRM/GEM uses uvm_aobj for long-term pageable graphics buffers, but
> when these buffers are assigned physical pages whose addresses can be
> programmed into the GPU's page tables, only certain physical pages are
> allowed -- specifically, Intel GPUs can handle only 32-bit, 36-bit, or
> 40-bit physical addresses, depending on the model.  Normally we use
> bus_dmamem_alloc and bus_dmatag_subregion to impose these constraints,
> but bus_dmamem memory is not pageable.
> 
> When I wrote the code to hook GEM objects up to uvm_aobj last summer I
> kinda quietly hoped this wouldn't be a problem, but it turns out this
> is a problem in practice.
> 
> The attached patch
> 
> (a) implements a uvm page allocation strategy UVM_PGA_STRAT_LIMITED
> which lets the caller specify low and high addresses, for which
> uvm_pagealloc defers to uvm_pglistalloc;

Wrong approach.  These should be on dedicated vm freelists instead.
Look at how mips64 has first512m, first4g, etc.  You could have 
first4g, first64g, first1t.  Then you can use UVM_PGA_STRAT_ONLY.

> (b) rearranges locking in uvm_pglistalloc a little so this works;

Dont need this.

> (c) adds a uao_limit_paddr(uao, low, high) to let a uao client specify
> bounds on the allowed physical addresses; and

Choose a freelist.

> (d) uses uao_limit_paddr in i915drmkms.
> 
> It doesn't change page allocation in any other case: uao still uses
> the normal page allocation strategy if you don't call uao_limit_paddr,
> and other calls to uvm_pagealloc are not affected.
> 
> Comments?  Objections?  Lewd Spenserian sonnets?

see above.