1%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 2\chapter{Type system}\label{chap:type_system} 3 4In this chapter, we cover the type model of capabilities and the 5supported types in Barrelfish. 6 7%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 8\section{Type Model} 9\note{We do not implement capability rights yet.} 10 11\begin{description} 12\item[Name] Each type has a unique name. 13 14\item[Origin] A capability type is either \emph{primitive}, which 15 means that capabilities of the type may be created only through a 16 special process (e.g. at boot time), or \emph{derived}, which means 17 that capabilities of the type may be created by retyping an existing 18 capability. For primitive types, we specify how the capabilities of 19 that type are created; for derived types, we specify which 20 capability types may be retyped to yield a capability of the given 21 type. 22 23\item[Retypability] Some types of capability may be \emph{retyped} to 24 create one or more new capabilities of the same or different 25 type. If this is the case, we specify for each type from what other types of 26 capability it may be retyped. 27 28\item[Mint parameters] It is possible to specify type-specific 29 parameters when \emph{minting} capabilities. We specify for each 30 type the interpretation of the type-specific parameters. When not 31 specified, they are ignored. 32 33\item[Interpretation of rights] The interpretation of the primitive 34 capability rights is type-specific. A capability type defines the 35 interpretation of these rights, usually in the specification of the 36 legal invocations. 37 38\item[Transferability to another core] Depending on its type, it may 39 or may not be possible to transfer a capability to another core. 40 41\item[Last copy deleted] The type specific operations to perform when 42 the last copy of a capability is deleted. For capability types 43 that refer to actual memory, if the last reference to a piece of 44 memory is deleted, then the memory must be garbage collected. 45 46\item[Concrete representations] Each capability type has one or more 47 representations: in the memory of each core on which it may appear, 48 and in a canonical serialised representation used for transferring 49 it in a message between cores. These are specified as 50 Hamlet\cite{dagand:fof:plos09} data types. 51 52\item[Invocations] Most capability types support one or more 53 type-specific operations through the use of the invoke system call. 54 (documented in \ref{sec:sys_invoke}). 55\end{description} 56 57%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 58\section{Types} 59 60\subsection{CNode}\label{sec:cnode} 61 62A CNode refers to an array of capabilities of some power-of-two size. 63CNodes are used to hierarchically construct the CSpace of a domain, as 64described in \ref{sec:cspace}. All capability management is 65performed through invocations on CNodes. 66 67CNodes are organized as a two-level table with distinct capability types for 68the root or L1 CNode (which can be dynamically enlarged), and L2 or leaf 69CNodes which have a fixed size of 256 capability slots. 70The two-level CNode table forms a 32-bit capability address space for each 71dispatcher. 72User space refers to entries in that address space with a 32-bit 73\emph{capability address}. 74The high 24 bits of the capability address are used as an index into the L1 75CNode. 76The L1 CNode index can be too large for a given L1 CNode that has not been 77enlarged to it's maximum size of $2^{24}$ slots. 78A user space operation referring to an L1 slot that is not allocated will fail 79with \verb|SYS_ERR_L1_CNODE_INDEX|. 80The CPU driver then uses the L1 index to perform a lookup for the L2 CNode. 81If an L2 CNode exists for the given L1 index, the low 8 bits of the supplied 82capability address are used as an index into the L2 CNode. 83The CPU driver then uses the L2 index to perform a lookup for the requested 84capability. 85 86Many CNode invocations require that the caller provide both a CSpace 87address and the number of \emph{levels} to resolve. This allows the 88invocations to refer to a L2 CNode capability that is located in a L1 slot, 89and thus would usually be recursed through by the address resolution 90algorithm. 91 92\begin{description} 93\item[Origin] Retyping from RAM type capabilities 94 95\item[Retypability] No 96 97\item[Mint parameters] No 98 99\item[Interpretation of rights] \note{Explain rights and rights mask. 100 Capability rights and rights masks are currently not implemented. 101 This means that every user domain holding a capability has full 102 rights to it.} 103 104\item[Transferability to another core] Yes. When transfered to 105 another core, capability is implicitly retyped to a Foreign CNode 106 type. 107 \note{We currently allow CNode type caps to be transferred without doing 108 the type conversion, which is extremely risky, but does not break the 109 system if the receiver only ever tries to copy capabilities out of the 110 received CNode.} 111 112\item[Last copy deleted] When the last copy is deleted, all 113 capabilities stored within it are also deleted. 114 115\item[Concrete representations] The in-memory representation is as follows: 116 117 \begin{lstlisting}[language=Mackerel] 118 datatype L1CNode "L1 CNode capability" { 119 cnode 64 "Physical base address of CNode"; 120 size 64 "Allocated size of CNode in bytes"; 121 rightsmask 8 "Capability rights mask"; 122 }; 123 \end{lstlisting} 124 125 \begin{lstlisting}[language=Mackerel] 126 datatype L2CNode "L2 CNode capability" { 127 cnode 64 "Physical base address of CNode"; 128 rightsmask 8 "Capability rights mask"; 129 }; 130 \end{lstlisting} 131 132 Note that L2 CNodes have a fixed size of 16384 bytes, which is 133 \textbf{not} stored in their in-memory representation. 134\end{description} 135 136\begin{invocation}{Mint}\label{sec:mint} 137 \arg Capability of the source cspace root CNode to invoke 138 \arg Destination cspace cap address relative to source cspace 139 \arg Destination CNode address relative to destination cspace 140 \arg Slot in destination CNode cap to place copy into 141 \arg Address of cap to copy. 142 \arg Level/depth of 'to'. 143 \arg Level/depth of 'from'. 144 \arg 1st cap-dependent parameter. 145 \arg 2nd cap-dependent parameter. 146\end{invocation} 147The Mint invocation creates a new capability in an existing CNode 148slot, given an existing capability. The new capability will be a copy 149of the existing capability, except for changes to the 150\emph{type-specific parameters}. 151 152The use of the two type-specific parameters is described along with 153the description of the relevant type. 154 155\begin{invocation}{Copy} 156 \arg Capability of the source cspace root CNode to invoke 157 \arg Capability address of destination root cnode relative to our cspace 158 \arg CNode address to place copy into relative to destination cspace. 159 \arg Slot in CNode cap to place copy into. 160 \arg Capability address of source root cnode relative to our cspace 161 \arg Address of cap to copy. 162 \arg Level/depth of 'to'. 163 \arg Level/depth of 'from'. 164\end{invocation} 165This invocation is similar to Mint, but does not change any 166type-specific data. In fact, the CPU driver currently uses the same code path 167for copy and mint, and a mint with both cap-dependent parameters set to zero 168will behave exactly like a Copy invocation. 169 170\begin{invocation}{Retype} 171 \arg Capability of the source cspace root CNode to invoke 172 \arg Source cspace cap address in our cspace. 173 \arg Address of cap to retype in source cspace. 174 \arg Offset into cap to retype 175 \arg Kernel object type to retype to. 176 \arg Size of created objects, for variable-sized types 177 \arg Number of objects to create 178 \arg Destination cspace cap address in our cspace 179 \arg Address of CNode cap in destination cspcae to place retyped caps into. 180 \arg Level/depth of CNode cap in destination cspace 181 \arg Slot in CNode cap to start placement. 182\end{invocation} 183 184This invocation creates one or more new descendant capabilities of the 185specified type in the specified slots, given a source capability and a 186destination type. 187It will fail if the source or destination are invalid, or if the capability 188already has descendants which overlap the requested region (some capability 189types, currently only the dispatcher type can be retyped even if it already 190has descendants). 191The destination slots must all occupy the same CNode. The permissible 192source/destination pairs are shown in \ref{fig:cap_types} and 193\ref{tab:retype_types}. 194The number of new capabilities created is given as an argument. 195The invocation can fail if the retype region, which is defined as a pair of 196base address and size does not fit into the source capability. 197The retype region's base address is given as an offset into the source 198capability, and it's size is given as the number of capabilities to create 199multiplied by the requested size for the new capabilities. 200 201\note{check tables and figure for validity in 2017} 202 203\ctable[ 204 caption=Permissible types for the Retype invocation, 205 label=tab:retype_types, 206]{lll}{}{ 207 \FL Source & Destination & Variable size?\ML 208 Physical address range & Physical address range & Yes\NN 209 Physical address range & RAM & Yes\NN 210 Physical address range & Device frame & Yes\NN 211 RAM & RAM & Yes\NN 212 RAM & CNode & Yes\NN 213 RAM & VNode & No\NN 214 RAM & Dispatcher & No\NN 215 RAM & Frame & Yes\NN 216 Dispatcher & IDC endpoint & No\NN 217} 218 219\begin{figure} 220 \centering 221 \includegraphics[width=.7\columnwidth]{cap_types} 222 \caption{Valid capability retyping paths}\label{fig:cap_types} 223\end{figure} 224 225\begin{invocation}{Delete} 226 \arg Capability of the CNode to invoke 227 \arg Address of cap to delete. 228 \arg Level/depth of 'cap'. 229\end{invocation} 230This invocation deletes the capability at the given address, freeing 231the associated CNode slot. 232 233\begin{invocation}{Revoke} 234 \arg Capability of the CNode to invoke 235 \arg Address of cap to delete. 236 \arg Level/depth of 'cap'. 237\end{invocation} 238This invocation revokes the capability at the given address. 239 240The capability itself is left untouched while all its descendants and 241copies are deleted. 242 243\subsection{Foreign CNode} 244\note{This has not been implemented yet} 245 246The foreign CNode capability gives a domain on a core the ability to 247specify a capability that actually resides on another core. This 248capability allows for the holder to create local copies of the 249capabilities stored in the actual CNode modulo rights as can be 250implemented. The capability tracks on which core the actual CNode 251resides. \note{Full implementation and discussion pending} 252 253\begin{description} 254\item[Origin] When a CNode capability are copied to another core. 255 256\item[Retyability] No 257 258\item[Mint parameters] None 259 260\item[Interpretation of rights] \note{Explain rights} 261 262\item[Transferability to another core] Yes 263 264\item[Last copy deleted] \note{NYI} 265 266\item[Concrete representations] The in-memory representation on x86-64 is as follows: 267 268 \begin{lstlisting}[language=Mackerel] 269 datatype fcnode_cap "Foreign CNode capability" { 270 cnode 64 "Physical base address of CNode"; 271 bits 8 "Number of bits this CNode resolves"; 272 rightsmask 8 "Capability rights mask"; 273 core_id 8 "Core id of the core the actual CNode capability 274 resides in"; 275 guard_size 8 "Number of bits in guard word"; 276 guard 32 "Bitmask already resolved when reaching this CNode"; 277 }; 278 \end{lstlisting} 279 \note{This should not be used as-is, as we have changed the CNodes 280 themselves significantly in 2016.} 281\end{description} 282 283\note{Discussion pending on invocations} 284 285\subsection{Physical address range} 286 287Most domains will generally not handle capabilities of this type. 288They are introduced because the kernel relies on the user-space 289software to decide the location of RAM. 290 291By retyping physical address range capabilities to RAM, the caller 292guarantees that the underlying region does contain RAM that can safely 293be used for storage of kernel objects. Any domain with access to 294physical address range capabilities is therefore a critical part of 295the trusted computing base. 296 297\begin{description} 298\item[Origin] Created at boot time in the bsp core based on the 299 multiboot info. 300 301\item[Mint parameters] None 302 303\item[Retyability] To Physical address range, RAM or DevFrame type. 304 305\item[Interpretation of rights] \note{Explain rights} 306 307\item[Transferability to another core] Yes 308 309\item[Last copy deleted] \note{NYI, maybe inform some special 310 dispatcher like memory server} 311 312\item[Concrete representations] The in-memory representation is as follows: 313 314 \begin{lstlisting}[language=Mackerel] 315 datatype physaddr_cap "Physical address range capability" { 316 base 64 "Physical base address of region"; 317 bytes 64 "Size of region"; 318 }; 319 \end{lstlisting} 320\end{description} 321 322\subsection{RAM} 323 324A RAM capability refers to a naturally-aligned power-of-two-sized 325region of kernel-accessible memory. 326 327\begin{description} 328\item[Origin] Retyping from physical address range capabilities. 329 330\item[Retyability] To RAM, Frame, CNode, VNode, or Dispatcher types. 331 332\item[Mint parameters] None 333 334\item[Interpretation of rights] \note{Explain rights} 335 336\item[Transferability to another core] Yes 337 338\item[Last copy deleted] \note{NYI, maybe inform some special 339 dispatcher like memory server} 340 341\item[Concrete representations] The in-memory representation is as follows: 342 343 \begin{lstlisting}[language=Mackerel] 344 datatype ram_cap "RAM capability" { 345 base 64 "Physical base address of region"; 346 bytes 64 "Size of region"; 347 }; 348 \end{lstlisting} 349\end{description} 350 351\subsection{Dispatcher} 352This capability type refers to the kernel object associated with a 353user-level dispatcher. 354 355\begin{description} 356\item[Origin] Retyping from RAM capabilities. 357 358\item[Retyability] To IDC Endpoint type 359 360\item[Mint parameters] None 361 362\item[Interpretation of rights] \note{Explain rights} 363 364\item[Transferability to another core] No 365 366\item[Last copy deleted] \note{NYI, maybe inform some special 367 dispatcher like spawn daemon} 368 369\item[Concrete representations] The in-memory representation on x86-64 370 is as follows: 371 372 \begin{lstlisting}[language=Mackerel] 373 datatype dcb_cap "Dispatcher capability" { 374 dcb 64 "Pointer to the in kernel representation of 375 the dispatcher control block"; 376 }; 377 \end{lstlisting} 378\end{description} 379 380\begin{invocation}{Setup} 381 \arg Address of dispatcher capability relative to dispatchers caller's cspace 382 \arg Address of existing dispatcher for domain ID relative to caller's cspace 383 \arg Root of CSpace for new dispatcher relative to caller's cspace 384 \arg Root of VSpace for new dispatcher relative to cspace for new dispatcher. 385 \arg Frame capability for dispatcher structure relative to cspace for new dispatcher. 386 \arg Make runnable if true 387\end{invocation} 388This invocation sets any of the above parameters on a dispatcher 389object. If any of the CSpace addresses are null, they are ignored. 390Additionally, once all of the parameters are set (either in a single 391invocation, or after multiple invocations), and if the runnable flag 392is set, the dispatcher is made runnable. \note{There are additional 393 invocations in the code that we have not discussed yet.} 394 395\subsection{IDC Endpoint} 396 397Every IDC endpoint refers both to a dispatcher and an \emph{endpoint 398 buffer} within that dispatcher. The endpoint buffer is specified as 399an offset from the start of the dispatcher frame, and is the location 400where the kernel delivers IDC messages. It is also delivered to the 401user with an LRPC message. The initial endpoint offset of an IDC 402endpoint capability when it is retyped from a dispatcher capability is 403zero; the capability cannot be used to send IDC until the the offset 404is specified changed by minting an endpoint to another endpoint. 405 406\begin{description} 407\item[Origin] Retyping Dispatcher type capabilities. 408 409\item[Mint parameters] The mint parameters can be used to change the 410 badge on the capability 411 \begin{itemize} 412 \item Parameter 1: The endpoint offset to set on the capability. 413 \item Parameter 2: The endpoint buffer size to set on the capability. 414 \end{itemize} 415 416\item[Retyability] No 417 418\item[Interpretation of rights] \note{Explain rights} 419 420\item[Transferability to another core] No 421 422\item[Last copy deleted] \note{NYI, inform some entity to initiate 423 connection teardown} 424 425\item[Concrete representations] The in-memory representation on x86-64 426 is as follows: 427 428 \begin{lstlisting}[language=Mackerel] 429 datatype idc_cap "IDC endpoint capability" { 430 listener 64 "Pointer to the in kernel representation of the 431 receiver's dispatcher control block"; 432 epoffset 64 "Offset of endpoint buffer within dispatcher 433 structure"; 434 buflen 32 "Length of endpoint buffer in words"; 435 }; 436 \end{lstlisting} 437 438\item[Invocation] Any invocation of an endpoint capability causes the 439 entire message to be delivered to the dispatcher to which the 440 endpoint refers. 441 \end{description} 442 443\subsection{VNode} 444A VNode capability refers to a hardware page table and is used to 445manage a domain's virtual address space. Frame and device frame 446capabilities can be copied or minted into them or deleted from them by 447invoking the VNode. The architecture may impose limitations on the 448capabilities that may be copied into a VNode, or may allow extra 449attributes to be set when minting. 450 451We define one VNode capability type per hardware page table type per 452architecture. 453We currently define the following VNode types: 454\begin{itemize} 455 \item \verb|VNode_x86_64_pml4| 456 \item \verb|VNode_x86_64_pdpt| 457 \item \verb|VNode_x86_64_pdir| 458 \item \verb|VNode_x86_64_ptable| 459 \item \verb|VNode_ARM_l1| 460 \item \verb|VNode_ARM_l2| 461 \item \verb|VNode_AARCH64_l0| 462 \item \verb|VNode_AARCH64_l1| 463 \item \verb|VNode_AARCH64_l2| 464 \item \verb|VNode_AARCH64_l3| 465\end{itemize} 466 467\begin{description} 468\item[Origin] Retyping from RAM type capabilities. 469 470\item[Retyability] No 471 472\item[Mint parameters] None 473 474\item[Interpretation of rights] \note{Explain rights} 475 476\item[Transferability to another core] \note{Discussion pending} 477 478\item[Last copy deleted] Delete all the mapping capabilities associated with 479 mappings contained in the VNode. 480 481\item[Concrete representations] The in-memory representation on x86-64 482 is as follows: 483 484 \begin{lstlisting}[language=Mackerel] 485 datatype vnode_cap "VNode capability" { 486 base 64 "Base address of the page table"; 487 }; 488 \end{lstlisting} 489\end{description} 490 491\begin{invocation}{Map} 492 \arg VNode entry at which to create mapping 493 \arg CSpace address of the root (L1) CNode of the capability to map 494 \arg CSpace address of the capability to map 495 \arg Level of the capability to map 496 \arg (Architecture-dependent) Flags for the mapping 497 \arg Offset in bytes into the source capability of the region to map 498 \arg Size of the region to map in VNode entries 499 \arg CSpace address of the root (L1) CNode of the capability slot in which 500 to create the mapping capability 501 \arg CSpace address of the CNode of the capability slot in which to create 502 the mapping capability 503 \arg Level of the CNode of the capability slot in which to create 504 the mapping capability 505 \arg Slot in the CNode in which to create the mapping capability 506\end{invocation} 507This invocation maps a region of memory at the given offset and of the given 508size\footnote{we give the size in VNode entries, in order to easily reuse the 509invocation when e.g. creating superpages on x86-64} into the VNode starting at 510the given entry. 511The invocation may fail if the source capability cannot be found, the 512requested mapping region is not entirely covered by the source capability, the 513source capability does not have a type which is mappable into the VNode, given 514it's type, one or more of the VNode entries covering the requested mapping are 515already occupied, or the slot of the mapping capability cannot be found or is 516occupied. 517 518\begin{invocation}{Unmap} 519 \arg CSpace address of the mapping to remove 520 \arg Level of the mapping capability 521\end{invocation} 522This invocation unmaps the region identified by mapping from the VNode, if 523said region is actually mapped in the VNode. 524 525\noarginvocation{Identify} 526This invocation returns the physical address (and size) of the VNode. 527 528\subsection{Frame} 529A frame capability refers to a page-aligned\footnote{We coloquially refer to 5304kB pages as pages} region of physical memory with a size that is a multiple 531of 4096 bytes. 532A frame capability may be mapped into a domain's virtual address space (by 533copying it to a VNode). 534When a frame capability is created (ie.~retyped from RAM), the kernel 535zero-fills the frame. 536\note{Is this a good idea? Shouldn't we be able to pre-zero frames? 537 -AB} 538 539\begin{description} 540\item[Origin] Retyping from RAM type capabilities. 541 542\item[Retyability] To Frame type 543 544\item[Mint parameters] None 545 546\item[Interpretation of rights] \note{Explain rights} 547 548\item[Transferability to another core] Yes 549 550\item[Any copy deleted] Look up any \emph{Mapping} capabilities associated 551 with this Frame and use information stored in those mappings to remove any 552 page table entries that exist for this copy of the frame capability. 553 554\item[Last copy deleted] Check whether there are any other capabilities that 555 refer to the region, or a superset of the region, referred to by this 556 capability. If not, return create a new RAM capability and return it to a 557 specially identified ``memory server'' dispatcher. 558 559\item[Concrete representations] The in-memory representation is as follows: 560 561 \begin{lstlisting}[language=Mackerel] 562 datatype frame_cap "Frame capability" { 563 base 64 "Physical base address of mappable region"; 564 bytes 64 "Size of the region"; 565 }; 566 \end{lstlisting} 567\end{description} 568 569\noarginvocation{Identify} 570This invocation returns the physical address and size (in bytes) of the frame. 571 572\subsection{Device frame} 573A device frame capability refers to a page-aligned region of physical address 574space, with a size that is a multiple of 4096, that may be mapped into a 575domain's virtual address space (by copying it to a VNode). 576Unlike frame capabilities, the kernel does not zero-fill device frame 577capabilities upon mapping. 578As the name implies, device frames are typically used for access to 579memory-mapped devices. 580 581\begin{description} 582\item[Origin] Retyping Physical address range type capabilities. 583 584\item[Retyability] To Device frame type 585 586\item[Mint parameters] None 587 588\item[Interpretation of rights] \note{Explain rights} 589 590\item[Transferability to another core] Yes 591 592\item[Any copy deleted] Look up any \emph{Mapping} capabilities associated 593 with this Frame and use information stored in those mappings to remove any 594 page table entries that exist for this copy of the frame capability. 595 596\item[Last copy deleted] Check whether there are any other capabilities that 597 refer to the region, or a superset of the region, referred to by this 598 capability. If not, return create a new RAM capability and return it to a 599 specially identified ``memory server'' dispatcher. 600 601\item[Concrete representations] The in-memory representation is as follows: 602 603 \begin{lstlisting}[language=Mackerel] 604 datatype device_cap "Device Frame capability" { 605 base 64 "Physical base address of region"; 606 bytes 64 "Size of the region"; 607 }; 608 \end{lstlisting} 609\end{description} 610 611\noarginvocation{Identify} This invocation returns the physical 612address and size (in bytes) of the frame. 613 614\subsection{Mapping} 615After an attempt to store shadow page table entries in the Frame/DevFrame 616capability copies that are mapped in a VNode, which led to a lot of 617unnecessary heavy-weight Frame capability copies in the system, we redesigned 618the shadow page table implementation to use additional capability types, one 619for each capability type that can be copied to a VNode type. 620 621We define one mapping type per mappable capability type. 622We currently define the following mapping types: 623\begin{itemize} 624 \item \verb|Frame_Mapping| 625 \item \verb|DevFrame_Mapping| 626 \item \verb|VNode_x86_64_pml4_Mapping| 627 \item \verb|VNode_x86_64_pdpt_Mapping| 628 \item \verb|VNode_x86_64_pdir_Mapping| 629 \item \verb|VNode_x86_64_ptable_Mapping| 630 \item \verb|VNode_ARM_l1_Mapping| 631 \item \verb|VNode_ARM_l2_Mapping| 632 \item \verb|VNode_AARCH64_l0_Mapping| 633 \item \verb|VNode_AARCH64_l1_Mapping| 634 \item \verb|VNode_AARCH64_l2_Mapping| 635 \item \verb|VNode_AARCH64_l3_Mapping| 636\end{itemize} 637 638\begin{description} 639\item[Origin] Created when copying a mappable capability to a VNode. 640 641\item[Retyability] None. 642 643\item[Mint parameters] None 644 645\item[Interpretation of rights] \note{Explain rights} 646 647\item[Transferability to another core] No. 648 649\item[Any copy deleted] Use information stored in capability to delete that 650 mapping that caused this capability to be created. 651 652\item[Last copy deleted] Same as for any other copy deleted. 653 654\item[Concrete representations] The in-memory representation is as follows: 655 656 \begin{lstlisting}[language=Mackerel] 657 datatype mapping "Mapping capability" { 658 cap 64 "Kernel address of capability this mapping tracks"; 659 pte 64 "Kernel address of VNode entry this mapping tracks"; 660 offset 32 "Offset into capability for the mapped region"; 661 pte_count 16 "Number of VNode entries of the mapped region"; 662 }; 663 \end{lstlisting} 664\end{description} 665 666\begin{invocation}{Modify flags of mapping} 667 \arg CSpace address of mapping capability 668 \arg Offset (in #pages) of the first page to get new set of flags from the 669 first page in the mapping identified by the mapping capability. 670 \arg Number of pages that should get new set of flags 671 \arg New set of flags 672 \arg Hint for selective TLB flushing 673\end{invocation} 674Invocation that uses mapping capability to efficiently find relevant VNode 675entries to modify a mapping's flags. 676 677\begin{invocation}{Destroy mapping} 678 \arg Cspace address of mapping capability 679\end{invocation} 680This invocation is not yet implemented. 681 682\subsection{IO} 683An IO capability gives the holder the ability to read and write to IO ports. 684IO capabilities are currently only supported on x86-64. 685 686\begin{description} 687\item[Origin] A single IO capability covering the whole IO region created at 688 boot time in the BSP core. 689 690\item[Retyability] No 691 692\item[Mint parameters] Used to specify the region of io space the capability can access. 693 \begin{itemize} 694 \item Parameter 1: Start of the region 695 \item Parameter 2: End of the region 696 \end{itemize} 697 698\item[Interpretation of rights] \note{Explain rights} 699 700\item[Transferability to another core] Yes 701 702\item[Last copy deleted] \note{NYI} 703 704\item[Concrete representations] The in-memory representation on x86-64 is as follows: 705 706 \begin{lstlisting}[language=Mackerel] 707 datatype io_cap "IO capability" { 708 start 16 "Start of the granted IO range"; 709 end 16 "End of the granted IO range"; 710 }; 711 \end{lstlisting} 712\end{description} 713 714\begin{invocation}{Outb} 715 \arg IO port number 716 \arg Output data 717\end{invocation} 718This invocation writes a byte to the the specified IO port 719 720\begin{invocation}{Outw} 721 \arg IO port number 722 \arg Output data 723\end{invocation} 724This invocation writes a two byte word to the the specified IO port 725 726\begin{invocation}{Outd} 727 \arg IO port number 728 \arg Output data 729\end{invocation} 730This invocation writes a four byte to the the specified IO port 731 732\begin{invocation}{Inb} 733 \arg IO port number 734\end{invocation} 735This invocation returns a byte read from the specified IO port. 736 737\begin{invocation}{Inw} 738 \arg IO port number 739\end{invocation} 740This invocation returns a 16-bit word read from the specified IO port. 741 742\begin{invocation}{Ind} 743 \arg IO port number 744\end{invocation} 745This invocation returns a 32-bit doubleword read from the specified IO port. 746 747\subsection{IRQ table capability} 748The IRQ table capability allows the holder to configure the user-level 749handler dispatcher that will be invoked when the kernel receives 750device interrupts. 751 752\note{Discuss new IRQSrc and IRQDest capabilities} 753 754\begin{description} 755\item[Origin] Given to the first domain spawned on a core. 756 757\item[Retyability] No 758 759\item[Mint parameters] None 760 761\item[Interpretation of rights] \note{Explain rights} 762 763\item[Transferability to another core] No 764 765\item[Last copy deleted] \note{NYI} 766 767\item[Concrete representations] This capability type has no 768 representation associated with it as it is used to simply give 769 permissions to the holders and does not refer to any kernel data 770 structure. 771 \end{description} 772 773\begin{invocation}{Set} 774 \arg IRQ number 775 \arg CSpace address of asynchronous endpoint capability 776\end{invocation} 777This invocation sets the user-level handler endpoint that will receive 778a message when the given interrupt occurs. While a handler is set, 779interrupts will be delivered as IDC messages. 780 781 782\begin{invocation}{Delete} 783 \arg IRQ number 784\end{invocation} 785This invocation clears the handler for the given IRQ. 786 787\subsection{Kernel Capability} 788This capability is used to confer authority to the user-space part of the 789Barrelfish kernel, the ``monitor''. 790Some other privileged domains also receive a copy of the kernel capability, 791but we should factor those operations out and create different capability 792types that give those dispatchers only the right to invoke the operations they 793actually need. 794One example of such a dispatcher is the dispatcher that brings up new cores. 795 796\begin{description} 797\item[Origin] Given to the first domain spawned on a core. 798 799\item[Retyability] No 800 801\item[Mint parameters] None 802 803\item[Interpretation of rights] \note{Explain rights} 804 805\item[Transferability to another core] No 806 807\item[Last copy deleted] \note{NYI} 808 809\item[Concrete representations] The in-memory representation is as follows: 810 811 \begin{lstlisting}[language=Mackerel] 812 datatype kernel_cap "Kernel capability" { 813 }; 814 \end{lstlisting} 815 816 The kernel capability does not convey any information, it is simply a 817 token of authority. 818\end{description} 819 820\begin{invocation}{Spawn core} 821 \arg Apic ID of the core to try booting 822 \arg CSpace address of the RAM capability to use to relocate the new kernel 823 \arg CSpace address of the Dispatcher capability of the first domain to run 824 \arg Number of valid bits for the root CNode to associate with the Dispatcher capability 825 \arg CSpace address of the root CNode to associate with the Dispatcher capability 826 \arg CSpace address of the VNode to associate with the Dispatcher capability 827 \arg CSpace address of the dispatcher frame to associate with the Dispatcher capability 828\end{invocation} 829The invocation requests the kernel to try booting another core. The 830kernel is to be relocated into the given memory region and to run the 831the given domain. 832 833\begin{invocation}{Get core ID} 834 \arg None 835\end{invocation} 836The invocation returns the APIC ID of the core. 837 838\begin{invocation}{Identify capability} 839 \arg CSpace address of the capability to identify 840 \arg Level of the capability to identify 841 \arg Location of buffer to hold capability representation 842\end{invocation} 843The invocation stores the kernel's in-memory representation of the 844capability into the given buffer. 845j 846\begin{invocation}{Identify another dispatcher's capability} 847 \arg CSpace address of the dispatcher's L1 cnode capability 848 \arg Level in our CSpace of the L1 cnode capability 849 \arg CSpace address relative to the dispatcher's CSpace of the capability to 850 identify 851 \arg Level in the dispatcher's CSpace of the capability to identify 852 \arg Location of buffer to hold capability representation 853\end{invocation} 854The invocation stores the kernel's in-memory representation of another 855dispatcher's capability into the given buffer. 856 857\begin{invocation}{Create capability} 858 \arg In memory representation of a capability 859 \arg CSpace address of the CNode the place the created capability in 860 \arg Level of the CNode in the CSpace 861 \arg Slot number to place the capability in 862 \arg Owning core of the new capability 863\end{invocation} 864Creates the given capability in the given slot in the given CNode with the 865given Owner. 866 867\note{TODO: KernelCmd\_Copy\_existing} 868 869\begin{invocation}{Set capability's remote relations} 870 \arg CSpace address of CSpace (L1 CNode) in which to look for capability 871 \arg Level of root capability. 872 \arg CSpace address of capability 873 \arg Level of capability 874 \arg Remote relations to set. 875 \arg Mask: bitmask to show which remote relations to set. 876\end{invocation} 877If mask is not zero, set remote relations according to the bits set in the 878expression \verb|remote_relations & mask|. 879Always returns the remote relations bitmask after potentially setting new 880remote relations. 881 882\begin{invocation}{Read capability's remote relations} 883 \arg CSpace address of capability 884 \arg Level of capability 885\end{invocation} 886Returns bitmask of currently set remote relations on capability. 887 888Further Kernel capability invocations that we will have to document: 889\begin{itemize} 890 \item \verb|KernelCmd_Get_arch_id|: Returns arch id of caller's core 891 \item \verb|KernelCmd_Nullify_cap|: Set the capability to NULL allowed it to be reused 892 \item \verb|KernelCmd_Setup_trace|: Set up trace buffer 893 \item \verb|KernelCmd_Register|: Register monitor notify endpoint 894 \item \verb|KernelCmd_Domain_Id|: Set domain ID of dispatcher 895 \item \verb|KernelCmd_Get_cap_owner|: Get capability's owning core 896 \item \verb|KernelCmd_Set_cap_owner|: Set capability's owning core 897 \item \verb|KernelCmd_Lock_cap|: Lock capability when performing distributed 898 operation. 899 \item \verb|KernelCmd_Unlock_cap|: Unlock capability when distributed 900 operation done. 901 \item \verb|KernelCmd_Delete_last|: Instruct CPU driver to perform 902 operations necessary -- as outlined in this section -- when deleting last 903 copy of a capability. 904 \item \verb|KernelCmd_Delete_foreigns|: Delete non-owned copies when 905 processing a revoke request from another core. 906 \item \verb|KernelCmd_Revoke_mark_target|: Mark a capability for revocation. 907 \item \verb|KernelCmd_Revoke_mark_relations|: Mark a capability's relations 908 for revocation. 909 \item \verb|KernelCmd_Delete_step|: Instruct the CPU driver to perform a 910 delete step in the distributed delete protocol. 911 \item \verb|KernelCmd_Clear_step|: Instruct the CPU driver to perform a 912 clear step in the distributed delete protocol. 913 \item \verb|KernelCmd_Retype|: Perform a retype for a capability with remote 914 relations. 915 \item \verb|KernelCmd_Has_descendants|: Check whether a capability has 916 descendants. 917 \item \verb|KernelCmd_Is_retypeable|: Check whether a requested retype is 918 valid. 919 \item \verb|KernelCmd_Sync_timer|: Synchronize hardware timers. 920 \item \verb|KernelCmd_IPI_Register|: Register a handler for an IPI (?). 921 \item \verb|KernelCmd_IPI_Delete|: Delete a handler for an IPI (?). 922 \item \verb|KernelCmd_GetGlobalPhys|: Get global physical address 923 corresponding to a local physical address? 924 \item \verb|KernelCmd_Add_kcb|: add extra KCB to be scheduled. 925 \item \verb|KernelCmd_Remove_kcb|: remove KCB from scheduling ring. 926 \item \verb|KernelCmd_Suspend_kcb_sched|: suspend/resume KCB scheduler. 927 \item \verb|KernelCmd_Get_platform|: Get architecture platform. 928\end{itemize} 929 930\subsection{Kernel Control Block} 931A kernel control block capability captures all the state for a single CPU 932driver. This allows us to do interesting operations such as rebooting a core 933at runtime~\cite{Coreboot:Zellweger2014}. 934A kernel control block is structured according to the \verb|struct kcb| 935defined in the CPU driver code. 936 937\begin{description} 938\item[Origin] Retyping from RAM type capabilities 939 940\item[Retypability] No 941 942\item[Mint parameters] No 943 944\item[Interpretation of rights] \note{Explain rights and rights mask. 945 Capability rights and rights masks are currently not implemented. 946 This means that every user domain holding a capability has full 947 rights to it.} 948 949\item[Transferability to another core] Yes, between cores that share memory. 950 When transferred to another core, can be scheduled on that core. 951 952\item[Last copy deleted] \note{NYI} 953 954\item[Concrete representations] The in-memory representation is as follows: 955 956 \begin{lstlisting}[language=Mackerel] 957 datatype KernelControlBlock "Represents a CPU driver's state" { 958 kcb 64 "Kernel address of the KCB represented by this capability" 959 }; 960 \end{lstlisting} 961\end{description} 962 963\note{Need to discuss invocations on KCB} 964