IRC channel logs

***Server sets mode: +nt

<damo22>vm_allocate_contiguous gives you a block of contiguous RAM for a DMA buffer, but it doesnt help if you need a particular physical offset

<damo22>is that something i need to solve?

<damo22>ah yes

<damo22>hey youpi why not put the ds_vm_allocate_contiguous an RPC on the "mem" device

<damo22>why does it need to be on the master device port

<damo22>then all the ds_* RPCs will take a device_t

<youpi>well, to me vm_allocate_contiguous, as it is, really is like vm_allocate

<youpi>so I don't see why putting it along devices

<youpi>as it is now it's just memory allocation, with a constraint on the physical addresses of the memory to be allocated

<damo22>ok, so it should be a mach RPC?

<youpi>putting it into the device land would make things less clear, with some memroy allocation in some parf of the kernel, and others in other parts

<youpi>on the host port, yes

<damo22>ok

<youpi>just like it is already in the userland driver branch

<damo22>no worries

<damo22>why does it need the "task"

<damo22>target_task, that means anyone can call it and attach memory to any task?

<damo22>since it is a kernel call, somehow it should always be mach_task_self() from the process that calls it?

<damo22>how can i pass in mach_task_self() without adding it as a parameter explicitly

<youpi>task for knowing in which task the allocation should be exposed

<youpi>the host ports is used to check that not everybody can call it

<youpi>(i.e. you could allocate into another process, that's needed for fork etc.)

<damo22>ok

<damo22>youpi: i am reading the vm code, it looks like the virtual memory is split into 3 regions, DMA, DIRECTMAP and HIGHMEM. these are all virtual address spaces, there is no room for MMIO regions that must map to a physical address

<damo22>ie, you cant very easily request physical addresses in particular, there is a way to request within the three VM regions, but that still does not guarantee any physical address

<damo22>it almost needs another region called MMIO that is reserved by the bios

<damo22>and then you ask for VM_PAGE_SEL_MMIO

<damo22>and subtract MMIO_BASE from the requested ofset

<junlingm>damo22: vm_allocate_contiguous seems to return a paddr?

<junlingm>oh, sorry I misunderstood your statement. You mean it does not give a region starting at a specific physical address?

<damo22>i think vm_allocate_contiguous is useless, in the case where you want DMA, you usually already know the physical address of the buffer because its hardcoded in PCI

<damo22>all you need is a pointer to it that you can actually access from userspace

<damo22>it should be an RPC called vm_map_physical

<damo22>and all it does is takes a physical address and size, finds the nearest page, maps it into the page table and returns an offset from the start of the page

<damo22>the problem is, you could misuse it to peek at any address

<damo22>in fact, we dont need it, we have mem device and vm_map

<damo22>just call device_open("mem") and device_map(...) and then vm_map

<damo22>just like we did in libpciaccess

<youpi>damo22: you're confused :)

<youpi>there are several things

<youpi>for mmio, yes, mapping the mem device is what we can do, and already do in libpciaccess

<youpi>but there are also OS-provided DMA buffers

<youpi>which are in real memory

<youpi>which need to be physically contiguous because PCI devices don't access the page table

<youpi>that's what vm_allocate_contiguous provides

<youpi>*physically* contiguous memory

<youpi>vm_allocate only provides *virtually* contiguous memory

<youpi>now, the DMA/DIRECTDMA/HIGHMEM are for *physical* addresses

<youpi>they really are meant to decide where physically the pages get allocated

<youpi>which is important because devices have differing memory access capabilitiies

<damo22>do we need to provide a way to allocate physically contiguous memory for userspace?

<youpi>so drivers call vm_allocate_contiguous, and get both the virtual adress (for accessing the data from the CPU) and the physical adresse (which they give to the device, for it to access the data directly in memory)

<youpi>yes

<youpi>because devices can only access memory that way

<damo22>ok

<youpi>physically

<youpi>and physically contiguous

<youpi>you give a base physical address and the size

<youpi>some devices can take an iovec, but that's not always available

<youpi>and the driver need to know the physical address, to pass it to the device

<youpi>vm_allocate() doesn't provide that

<damo22>but i read the code for vm_allocate_contiguous, it calls vm_page_grab_contig

<damo22>that does not allow you to specify anything related to the physical address being allocate

<damo22>d