Re: [Xen-devel] xen_create_contiguous_region - Regarding

[Jambunathan K <jambunathan@xxxxxxxxxx>]

Keir

>>> Given that our driver supports 35-bit mask, the fact that
>>> xen_create_contiguous_region constrains "machine contiguous" allocations
>>> to less than dma_bits seems very limiting.
>>>
>>> What would be the recommended way to get machine contiguous pages within
>>>  say (1<<35)?
>> 
>> The address width is a parameter to xen_create_contiguous_region().
>> 

Let me explain what I meant.

xen_create_contiguous_region (as in Xen-3.0.4) can be instructed to make
2 kinds of allocations - from either MEMZONE_DOM or MEMZONE_DMADOM. Two
zones are delineated by max_dma_mfn as dictated by dma_size.

A "MEMF_dma" request to __alloc_domheap_pages is assured to be satisfied
from the MEMZONE_DMADOM.

The role of address_bits apparently stops at discreetly choosing between
one of the above 2 zones.

I am of the understanding that xen_create_contiguous_region() *cannot*
assure allocations say within (1<<35) (and desirably from outside of
MEMZONE_DMADOM)


In memory_exchange,

    if ( (exch.out.address_bits != 0) &&
         (exch.out.address_bits <
          (get_order_from_pages(max_page) + PAGE_SHIFT)) )
    {
        if ( exch.out.address_bits < dma_bitsize )
        {
            rc = -ENOMEM;
            goto fail_early;
        }
        memflags = MEMF_dma;
    }


the above code snippet requires that address_bits be atleast dma_bitsize
in which case it flags the alloc request as from MEMZONE_DMADOM. This
seems a bit counter intuitive to me. Is not address_bits a mandated
"spec" on the output extent.

In essence I have the following requests wrt xen_create_contiguous_region():

1) Export it.
2) Have it honor address_bits spec.

I can try my hand at submitting a patch if I have an in principle nod.

Thanks,
Jambunathan K.





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel