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