\begin{frame}
\frametitle{Why splitting PV and HVM code?}
\begin{itemize}
- \item Users can pick and choose the guest types
+ \item Users can pick and choose the guest interfaces
\begin{itemize}
\item Smaller binary, smaller attack surface
\item Reclaim precious address space if PV is disabled, to let Xen support $>$16TB host memory more easily
\item Identify all the components that need refactoring
\begin{itemize}
\item Dom0 builder
+ \item Domain handling code
\item Trap handling code
\item Memory management code
\item Guest memory accessor
\begin{itemize}
\item Abstract out a set of guest interfaces
\item Adjust internal interfaces between components if necessary
- \item Fix x86 common code, make PV and HVM configurable
+ \item Fix x86 common code
+ \item Make PV and HVM configurable
\end{itemize}
\end{itemize}
\end{frame}
\frametitle{Why PV ABI in PVH container?}
\begin{itemize}
\item Continue to support PV in a more secure manner
- \item Have more than 128G worth of 32bit PV guests
+ \item Have more than 128GB worth of 32bit PV guests
\end{itemize}
\end{frame}
\begin{itemize}
\item Build the PV shim -- essentially a stripped-down Xen hypervisor
\begin{itemize}
- \item Go through all PV hypercall handlers, classify them into different groups to be dealt with accordingly
+ \item Go through all PV hypercall handlers, categorize them into the aforementeioned groups
\item Further refactor PV guest supporting code: provide the "real PV" handlers and "PV shim" handlers while sharing as much code as possible
\item Change the build system to pull in the right objects
\end{itemize}
\item Doing coarse-grained refactoring:
\begin{itemize}
\item Dom0 builder (done)
+ \item Domain handling code (done)
\item Trap handling code (done)
\item Memory management code (doing)
\item Guest memory accessor