On Thu, Nov 5, 2015 at 10:46 AM, Barret Rhoden <[email protected]> wrote:
> > Maybe the structure of the event queue could be made simpler? > > From the user POV, I guess this is already abstracted by APIs, right? > > For an application, there is an API to extract a message from the > mailbox, and in general the address space issues don't affect them > much. > > From the kernel's perspective, one idea I had was to use uva2kva to > translate user pointers to kernel pointers. That basically is a page > table walk in software. The danger is that the user's address space > changes after we've walked the page tables. The solution there is to > use some form of deferred-destruction when it comes to munmap (the > main concern is that the page isn't *reused* after being munmapped > while the kernel thinks its still the user's memory). As usual, I have > some notes on that too, which we can pull out if the switch_tos pop up > as a pain point for an application's performance. > Here is what I was thinking. There is an VM area of N pages, at KMSG within kernel only area, and at UMSG at user VM space. The user VM space [UMSG, UMSG+N] is out of mmap() reach. Userspace has an API we give them to create a mailbox, which turns into a syscall. The syscall would get the necessary pages, find a free spot X in [KMSG, KMSG+N], map them there, as well as at UMSG + (X - KMSG). To deliver an event to user mailbox pointer P, the kernel will use (P - UMSG + KMSG). No need to swap CR3. The mailbox destruction would undo the mapping, and the struct proc will have to track the mappings as well, so that a process destruction can undo them as well. -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
