\begin{itemize}
\item Remove obselete page flipping mode (\brev{289583})
\item Implement multiqueue (\brev{294442})
+ \item Throughput from guest to host: 1 queue 5.8 Gb/s, 4 queues 11.2 Gb/s
\end{itemize}
\end{itemize}
\end{frame}
\item purge unused page flipping mode to simplify code
\item low hanging fruit, multiqueue, turns out not so low-hanging
\item rewrite large part of netfront.c
- \end{itemize}
-}
-
-\begin{frame}
- \frametitle{xen-net related improvements}
- \begin{itemize}
- \item graph for netfront throughput
- \end{itemize}
-\end{frame}
-\note{
- \begin{itemize}
\item doesn't scale linearly yet, likely to be bottleneck in Xen
\item room to optimise single stream throughput
\item tests run with WITNESS enabled
\end{itemize}
}
-\section{Xen}
+
+\section{News from Xen}
+
+\subsection{xen_up}
\begin{frame}
\frametitle{The full virtualization spectrum}
\begin{frame}
\frametitle{xSplice - hypervisor hot-patching}
\begin{itemize}
- \item ABC
+ \item Rationale:
+ \begin{itemize}
+ \item Rebooting hypervisor to fix security bugs are not desirable
+ \item A large number of security bugs require very simple patch to fix
+ \end{itemize}
+ \item Phase one goal is to handling patching functions, patching structure is yet to come
+ \item User space tooling is not tied to particular operating system
\end{itemize}
\end{frame}
\note{
\begin{itemize}
+ \item cause disruption for users
+ \item for very large installation base, rebooting within the time frame that required by Xen project security process is not always feasible
+ \item some organisations developed their own hot-patching. this risks fragmenting the community
+ \item members of Xen project realised this and started to push for upstream effort for hypervisor hot-patching
+
\end{itemize}
}