Yes, I did indeed miss the special case for frame caps. They are always unmapped when deleted (arch specific, but true for ARM and x86), not only when they are final. Sorry for the confusion ;-)
It is also correct that you can't have multiple mappings with the same cap, but you can copy a cap to the same frame before it is mapped, and you can map each of these copies separately (e.g. for setting up shared memory). So it is possible to have multiple frame caps to the same object. As Tom says, the mapping state is part of the cap, not part of the object, which is the reason for the special case.
Cheers, Gerwin
On 23 Jun 2017, at 08:53, <Thomas.Sewell@data61.csiro.aumailto:Thomas.Sewell@data61.csiro.au> <Thomas.Sewell@data61.csiro.aumailto:Thomas.Sewell@data61.csiro.au> wrote:
Hi Oak.
Yes, I think Gerwin has missed that frame caps are a bit of a special case.
Per-object finalisation actions happen when the last cap to an object is being removed. You can make as many copies of an endpoint cap as you like, and the endpoint will only be cleared when the last one is deleted. Typically the creating manager/supervisor keeps the original for itself and decides when to perform this action.
Some caps have per-cap state as well, e.g. the mapping info stored in a frame cap. As an aside, frame caps are the only caps with per-cap state that I know of, but other architectures might have more. This per-cap state is finalised with the cap. So deleting a mapped copy (or deleting all mapped copies with the Revoke operation) will remove the mapping. The kernel has to do this, in fact, because information about how to remove the mapping only exists in the mapped cap, which is the whole point of forcing you to duplicate the caps per-mapping.
Cheers, Thomas.
On 23/06/17 05:24, Norrathep Rattanavipanon wrote: Hi Gerwin,
Thank you for your response. But I'm a little bit confused here. Maybe I misunderstood something or I didnt phrase the question correctly. From my understanding (please correct me if I'm wrong), each frame cap can only be mapped once. This means, you cannot have multiple mappings created by the same frame cap.
Then what did you mean by: "the kernel will unmap the page if the cap that you are deleting is the last cap to it. If there is still a copy of the frame cap around, it will not automatically unmap." ?
Oak
On Thu, Jun 22, 2017 at 12:43 AM, <Gerwin.Klein@data61.csiro.aumailto:Gerwin.Klein@data61.csiro.au> wrote: Hi Oak,
the kernel will unmap the page if the cap that you are deleting is the last cap to it. If there is still a copy of the frame cap around, it will not automatically unmap.
This is a general principle for cap deletion: deleting the last cap to an object triggers object “finalisation”, i.e. cleanup and resetting it to an inert state so that it can later be removed from memory without impacting the rest of the system. If there are still other caps to the same object in the system, only the cap is removed.
Cheers, Gerwin
On 22.06.2017, at 13:50, Norrathep Rattanavipanon <nrattana@uci.edumailto:nrattana@uci.edu> wrote:
Hello,
I was wondering when we call seL4_cnode_delete on a (mapped) frame cap, does the kernel also handle unmapping the frame (in addition to withdrawing authority) as well? Or the user-space has to ensure that the frame is unmapped first before calling delete?
I tried my code without unmapping that frame when deleting the cap and it seems to work fine. So I guess the kernel handles that?
Oak
-- Norrathep (Oak) Rattanavipanon M.S. in Computer Science University of California - Irvine _______________________________________________ Devel mailing list Devel@sel4.systemsmailto:Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
-- Norrathep (Oak) Rattanavipanon M.S. in Computer Science University of California - Irvine
_______________________________________________ Devel mailing list Devel@sel4.systemsmailto:Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
_______________________________________________ Devel mailing list Devel@sel4.systemsmailto:Devel@sel4.systems https://sel4.systems/lists/listinfo/devel