1\section{Design Options} 2 3In order to be able to register as a \acs{pci} device driver, some sort of 4management process for receiving the interrupts is necessary. A management 5process is also useful for device detection and initialization, providing the 6system with an overall view of what devices are available. 7 8Consumers of \ac{ahci}-related interrupts must register with the management 9process so that interrupts may be forwarded. To provide clients with access to 10different \ac{sata} devices, it makes sense to grant access to invidual 11\ac{hba} ports, and similarly to forward all interrupts for a port to any 12clients registered to that port. 13 14However, in choosing the method of accessing the ports, a trade-off must be 15made between security and performance. For example, by setting a suitable 16address, another domain's memory can be written to disk, and then read back, 17violating domain separation. To stop this from occuring, a central location 18must check that all \acp{prd} reference memory which the client may access. 19 20In such a design, all port memory access, including issuing of commands, would 21happen via Flounder messages to the central daemon. The central daemon would 22have to ensure that the client does not modify the command list or command 23tables after they are checked, so the all these areas would have to be copied 24into a memory area not accessible to the client. 25 26To achieve optimal performance at the cost of security, each client must be 27given full access to the port memory. Because this is usually within the same 28page as the \ac{hba} memory, clients are able to access not just their own 29port's registers, but all other ports' and the \ac{hba}'s registers as well. 30Also, as described above, the client can access all memory with suitable 31\acs{dma} commands. 32 33\section{General Architecture} 34 35\begin{figure}[ht] 36\centering 37\includegraphics[width=.9\textwidth]{architecture.pdf} 38\captionof{figure}{Barrelfish AHCI subsystem architecture} 39\label{fig:architecture} 40\end{figure} 41 42As shown in in \autoref{fig:architecture}, our message passing to disk has two 43main parts: a management part and a communication part. The management part, 44\emph{ahcid}, provides a system-wide authority over an \ac{ahci} controller. 45The communication part, consisting of libahci (a low-level abstraction for 46using an \ac{ahci} port) and the \ac{ata} message specification and translation 47layer using Flounder, is used by all user-level code that wants to access a 48disk to send and receive messages from a disk. 49 50\section{ahcid} 51 52ahcid exists as a central point of authority over an \ac{ahci} \ac{hba}. It is 53responsible for \ac{hba} initialization, Interrupt handling and access 54mediation. 55 56\subsection{Operation} 57 58ahcid ensures only one user can access an \ac{ahci} port at a time. Users can 59open a port by sending an \acs{idc} message to ahcid. If no other user 60currently owns the port, ahcid will provide a memory capability to the port's 61memory registers. The user is then able to use the port exclusively. 62Interrupts generated by the port are handled by ahcid and dispatched to the 63associated user via an \acs{idc} message. ahcid registers itself as PCI device 64driver for certain \ac{ahci} chipsets. 65 66\section{libahci} 67 68libahci tries to hide the necessary bit-twiddling and \acs{dma} buffer 69management for sending and receiving messages to a disk. Its interface 70resembles a Flounder-generated interface and makes use of Barrelfish's 71waitsets. 72 73\section{Flounder Backend} 74 75This lab project also contains a Flounder backend and Flounder modifications in 76order to be able to specify \ac{ata} commands as message definitions. The 77resulting interface can be used similarly to performing \acs{idc}. 78 79\section{Implemented ATA Commands} 80 81For our purposes (designing a messaging interface to disks) it was sufficient 82to implement commands for reading and writing blocks to and from disks using 83\acs{dma} (\ac{ata} commands {\tt READ DMA}, {\tt WRITE DMA}), inspecting the 84disk ({\tt IDENTIFY}) and flushing the cache ({\tt FLUSH CACHE}). Due to the 85Flounder layer in our system (specifically the \acs{ahci} backend) adding new 86\ac{ata} commands is quite easy: just add the command you want in the \ac{ata} 87interface specification. 88