Wiele tematów, które moglibyśmy omówić, zostało pominiętych w tym rozdziale, więc zanim zakończymy, przyjrzyjmy się kilku pomysłom, które możesz spróbować wdrożyć samodzielnie. Wdrożyliśmy dwa bardzo proste rozmycia, ale zbudowane przez nas ramy pozwalają nam zrobić o wiele więcej. Skorzystaj z listy powodów wyjścia maszyny wirtualnej na początku tego rozdziału jako inspiracji do napisania własnych rozmyć, zwracając szczególną uwagę na powody wyjścia 48 i 49, które są używane, między innymi, do emulacji pamięci mapowanej na wejście/wyjście (MMIO). Port szeregowy świetnie nadaje się do testowania i nauki, ponieważ jest szeroko dostępny i łatwy w obsłudze, ale jest zbyt wolny do rozmycia. Możesz się zastanawiać, dlaczego jest wolny, skoro jest zwirtualizowany i nie ma ograniczeń fizycznych? Powodem jest to, że dla każdego bajtu danych, które przesyłamy, powodujemy jedno wyjście maszyny wirtualnej i musimy czekać na przełączenie kontekstu z hiperwizora do procesu roboczego trybu użytkownika. Aby uzyskać przyzwoite prędkości rozmycia, należy je zastąpić urządzeniem parawirtualizowanym, które wykonuje transfer danych przez bufor pierścieniowy pamięci współdzielonej. Niestandardowy bootloader może zastąpić GRUB, aby osiągnąć szybsze czasy rozruchu — lub lepiej, proces rozruchu można całkowicie pominąć, jeśli docelowy hiperwizor obsługuje bezpośredni rozruch jądra (na przykład PVH11). Istnieje wiele sposobów, w jakie jądro może być bardziej odporne; na przykład, niektóre proste środki to oznaczenie stron jądra jako tylko do odczytu i użycie niestandardowych stosów dla obsługi wyjątków (IST12). Wreszcie, w naszej obecnej implementacji, klient działa w tym samym środowisku co cel. Idealnie byłoby przekształcić klasę gościa w serwer (działający w celu) i uruchomić klienta (rozmycie) na innej maszynie. W ten sposób możemy zapobiec utracie stanu rozmycia w przypadku awarii hosta.