[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 3.0 Status update



> However, for the long-lived control regions used by some devices (e.g.
> for descriptor rings etc) it probably makes sense to try and allocate
> them in memory they can access directly. Some of these have daft
> restrictions, such as the aacraid device only being able to use memory
> below 2GB for its control program.

> Most of these regions are bigger than a page so have to be created with
> dma_alloc_coherent, hence we have an opportunity to allocate them in a
> region they can directly access.

Yep, for the control structures it should be easy to sort as
dma_alloc_coherent() must be used for them
(Documentation/DMA-mapping.txt is pretty clear here) and so we
have a opportunity to hook in and make sure it's DMA-able
memory.

Linux device drivers can pass a address mask telling the kernel
which range the device in question can handle
(pci_set_dma_mask), it's probably a good idea to pass that down
to xen.  That should catch corner cases like the 2G limit on
some raid controller mentioned here recently without extra work
I think.

  Gerd

-- 
panic("it works"); /* avoid being flooded with debug messages */

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.