updates

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/cca-device-attach/2-virtio.md

@@ -8,18 +8,18 @@ layout: learningpathall
 
 ## Overview
 
-This section introduces VirtIO in the context of CCA Realms, and explains how it enables secure data exchange between a Realm and the untrusted external world.
+In this section, you will learn how VirtIO works in the context of Arm CCA Realms and how it enables efficient data exchange between a Realm and the untrusted external world.
 
-A Realm must eventually use physical devices to interact with the external world. The easiest way to achieve this is by using VirtIO, which provides a fast, high-level emulation layer. This is considered the first level of device attach, where access is mediated by the hypervisor using paravirtualized interfaces.
+A Realm must eventually use physical devices to interact with the external world. The simplest way to do this is by using VirtIO, which provides a fast, paravirtualized interface. This is considered the first level of device attach, where access is mediated by the hypervisor using paravirtualized drivers.
 
-More advanced device attach features can be enabled by hardware security features like PCIe-TDISP (**T**EE **D**evice **I**nterface **S**ecurity **P**rotocol) and PCIe-IDE (**I**ntegrity
-and **D**ata **E**ncryption), where the host OS assigns a physical device to a Realm. The Realm can then make security measurements on the physical device and include those in its attestation base.
+More advanced device attach features can be enabled by hardware security features such as PCIe-TDISP (TEE Device Interface Security Protocol) and PCIe-IDE (Integrity
+and Data Encryption). In those cases, the host OS assigns a physical device to a Realm, and the Realm can then measure the device and include those measurements in its attestation base.
 
-### What is VirtIO?
+## What is VirtIO?
 
-VirtIO provides an efficient, paravirtualized I/O interface between Realms and host devices. It is an abstraction layer for virtual devices in virtualized environments. VirtIO is a standardized, efficient interface for virtual devices in virtualized environments. It lets guest operating systems use paravirtualized drivers to communicate with host-provided devices, avoiding the overhead of fully emulating physical hardware.
+VirtIO is a standardized, paravirtualized interface for virtual devices in virtualized environments. It allows guest operating systems to use optimized drivers to communicate with host-provided devices, avoiding the overhead of fully emulating physical hardware.
 
-Paravirtualized means that the guest OS is aware it’s running in a virtualized environment and can use optimized drivers (VirtIO) to communicate with virtual hardware. Emulating physical hardware devices (like NICs or disks) for VMs is slow and inefficient. VirtIO allows VMs to bypass full device emulation and use streamlined drivers.
+Paravirtualized means that the guest OS is aware it’s running in a virtualized environment. It allows guest operating systems to use optimized drivers to communicate with host-provided virtual hardware. Emulating physical hardware devices (like NICs or disks) for VMs is slow and inefficient. VirtIO allows VMs to bypass full device emulation and use streamlined drivers.
 
 VirtIO is most commonly used with KVM/QEMU virtualization. Example drivers include:
 
@@ -30,23 +30,21 @@ VirtIO is most commonly used with KVM/QEMU virtualization. Example drivers inclu
 - `virtio-rng`: random number source
 - `virtio-console`: simple console interface
 
-### How does VirtIO work in VMs?
+## How does VirtIO work in VMs?
 
-Here is an overview of how VirtIO works in virtual machines:
-
-1. The host hypervisor (for example, QEMU/KVM) exposes VirtIO backend devices
-2. The guest OS loads VirtIO frontend drivers such as `virtio_net`or `virtio_blk` that communicate using the VirtIO protocol
-3. I/O uses shared memory `virtqueues`, which avoids full device emulation
-4. Devices are exposed over the PCI or MMIO bus to the guest
+1. The host hypervisor (for example, QEMU/KVM) exposes VirtIO backend devices.
+2. The guest OS loads VirtIO frontend drivers such as `virtio_net`or `virtio_blk` that communicate using the VirtIO protocol.
+3. I/O uses shared memory `virtqueues`, which avoids full device emulation.
+4. Devices are exposed over the PCI or MMIO bus to the guest.
 
 For example, instead of emulating an Intel e1000 NIC, the host exposes a `virtio-net` interface. The guest OS uses the `virtio-net` driver to exchange packets through shared buffers.
 
-### Key takeaways
+## Key takeaways
 
-- VirtIO provides fast I/O through paravirtualization, not hardware emulation
-- Shared queues reduce overhead and context switching
-- It is the simplest and most common first step for device attach in Realms
+- VirtIO provides fast I/O through paravirtualization, not hardware emulation.
+- Shared queues reduce overhead and context switching.
+- It is the simplest and most common first step for device attach in Realms.
 
 ## Next steps
 
-Learn how bounce buffers make this safe for Realms in [Bounce buffers](./bounce-buffers.md)
+In the next section, you'll learn how bounce buffers make VirtIO safe for Realms. 

content/learning-paths/servers-and-cloud-computing/cca-device-attach/3.bounce_buffers.md

@@ -12,9 +12,9 @@ Bounce buffers are temporary memory areas used when a device cannot perform DMA
 
 Common reasons for this include:
 
-1. The original buffer is not physically contiguous
-2. The buffer resides in memory not accessible by the device
-3. The buffer does not meet the device alignment or boundary constraints 
+- The original buffer is not physically contiguous
+- The buffer resides in memory not accessible by the device
+- The buffer does not meet the device alignment or boundary constraints 
 
 ## Why use bounce buffers?
 
@@ -64,13 +64,9 @@ This pattern preserves confidentiality and integrity of Realm data because:
 
 A bounce buffer preserves the confidentiality of other Realm data because only the explicitly shared region is exposed. However, the transferred data is outside Realm protection once it leaves. Use protocol-level encryption such as TLS for network traffic to keep that data confidential in transit.
 
-## Seeing a Realm's bounce buffers at work
-
 ## Next steps
 
-Let's put this to work and check for ourselves that bounce buffers are used. The steps in this section will build on the Key Broker demo that was used in the [CCA
-Essentials learning path](/learning-paths/servers-and-cloud-computing/cca-essentials/example/),
-demonstrating an end-to-end attestation.
+In the next section, you'll test this by tracing SWIOTLB activity in [Exercise: observe bounce buffers in a Realm](./lab-observe-bounce-buffers.md). 
+
 
-Prove it by tracing SWIOTLB activity in [Exercise: observe bounce buffers in a Realm](./lab-observe-bounce-buffers.md)