From c98a9dd886384ad3a693592033fc20ebbd4d7737 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sol=C3=A8ne=20Rapenne?= Date: Thu, 11 Dec 2025 00:09:14 +0100 Subject: [PATCH] fix a typo --- user/advanced-topics/standalones-and-hvms.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/advanced-topics/standalones-and-hvms.rst b/user/advanced-topics/standalones-and-hvms.rst index 45854900..76490a6f 100644 --- a/user/advanced-topics/standalones-and-hvms.rst +++ b/user/advanced-topics/standalones-and-hvms.rst @@ -32,7 +32,7 @@ PVH has less attack surface than PV, as it relies on Second Level Address Transl PVH also has less attack surface than HVM, as it does not require QEMU to provide device emulation services. While QEMU is confined in a stubdomain, and again in a seccomp based sandbox, the stubdomain has significant attack surface against the hypervisor. Not only does it have the full attack surface of a PV domain, it also has access to additional hypercalls that allow it to control the guest it is providing emulation services for. XSA-109 was a vulnerability in one of these hypercalls. -PVH has better performance than HVM, as the stubdomain iin HVM consumes resources (both memory and a small amount of CPU). There is little difference in the I/O path at runtime, as both PVH and HVM guests usually use paravirtualized I/O protocols. +PVH has better performance than HVM, as the stubdomain in HVM consumes resources (both memory and a small amount of CPU). There is little difference in the I/O path at runtime, as both PVH and HVM guests usually use paravirtualized I/O protocols. Surprisingly, PVH often has better performance than PV. This is because PVH does not require hypercalls for page table updates, which are expensive. SLAT does raise the cost of TLB misses, but this is somewhat mitigated by a second-level TLB in recent hardware.