1In the course of this lab project we successfully implemented an \ac{ahci} 2driver and supporting code for data storage and retrieval. 3 4\section{Flounder Modifications} 5 6The extensions added to flounder provide a very simple and extensible way to 7interface with disks. The overhead incurred is acceptable in the trade-off for 8simplicity and modularity. The seperation of interface definition for \ac{ata} 9from implementation of command dispatching to the device allows simple addition 10of further \ac{ata} transports, such as additional \acs{pata}/\acs{sata} 11controllers. 12 13\section{Security} 14 15The \acs{ahci} driver demonstrates the trade-off when dealing with \acs{dma}. 16If a domain is allowed full control over the configuration of \acs{dma} 17aspects, it can obtain full read/write access to physical memory. To mitigate 18this problem, the management service would have to check and validate any 19memory regions supplied before allowing a command to execute. If only trusted 20domains are allowed to bind to the \acs{ahci} driver, these checks are not 21neccessary. This is a valid assumption, as filesystems and blockdevice-like 22services are the only ones that should be allowed raw access to disks. 23 24\section{Performance} 25 26Performance is in the same order of magnitude as seen on Linux for large 27blocksizes and random access. There is some bottleneck during read operations 28that could relate either to interrupt dispatching or memcopy performance. To 29achieve high throughput on sequential workloads with small blocksizes, a 30prefetcher of some sort is necessary. A possible solution would be to have a 31cache that stores pages or larger chunks of data. A read operation would then 32have to read multiples of the cached size if the data is not present in the 33cache. If data is cached, the request can be completed much faster without 34needing to consult the disk. 35