Page-1

# Enable virtualization Virtualization uses software to create an abstraction layer over computer hardware. The abstraction layer divides the hardware elements of a single computer, such as processor, memory, and storage into different virtual entities, called as virtual machines (VMs). Each VM runs its own OS and behaves like an independent computer, though it’s running on the same underlying computer hardware. **Figure: Virtualization** Note Virtualization is supported on the custom BSP variant only. ## Qualcomm virtualization solution Qualcomm uses Gunyah, a type-1 hypervisor designed for strong security, high performance, OS independence, and higher CPU privilege level. Gunyah does not depend on any lower-privileged OS kernel or code for its core functionality to offer increased security. Gunyah is designed for isolated virtual machine use cases, and for launching isolated virtual machines from a relatively less trusted host virtual machine. The following figure shows the Qualcomm virtualization solution architecture: **Figure: Qualcomm virtualization solution architecture** Gunyah provides the following features: > > > Table: Features of Gunyah > > > | Features | Description | > | --- | --- | > | Threads and scheduling | Scheduler schedules virtual CPUs (VCPUs) on physical CPUs and allows time-sharing of the CPUs. | > | Memory management | Gunyah tracks memory ownership and memory usage under its control. Gunyah provides low-level dynamic memory management APIs on top of which the higher-level donation, lending, and sharing are built. | > | Interrupt virtualization | Gunyah manages interrupts that are routed directly to the assigned VM. | > | Inter-VM communication | Message queues and doorbells provide mechanisms for communication between the VMs. | > | Device virtualization | Para-virtualization of devices is supported using inter-VM communication and virtio primitives. The hardware virtualization and emulation support low-level architecture features and devices, such as CPU timers and interrupt controllers. | > | Resource manager | Gunyah supports a root VM that initially owns all the VM memory and input/output resources. The Gunyah resource manager is the default-bundled root VM and provides high-level services including dynamic VM management, secure memory donation, lending, and sharing. | The Gunyah hypervisor support is added to the [crosvm](https://chromium.googlesource.com/chromiumos/platform/crosvm) virtual memory monitor (VMM). The crosvm interacts with the Gunyah VM manager in the kernel through the `/dev/gunyah` interface and creates a VM. The following figure shows the blocks in the Qualcomm virtualization solution: **Figure: Qualcomm virtualization solution** For more information about type 1 hypervisor, see [gunyah-hypervisor](https://github.com/quic/gunyah-hypervisor). ### Guest VM build support To compile the guest VM kernel and initrd images, use the following procedure: During the guest VM kernel compilation, both the guest kernel and the minimal `rootfs` are built. `qcom_vm_defconfig` serves as the base configuration for compiling the guest kernel. The `qcom_vm_debug.config` builds the debug variant of the guest VM. `crosvm` serves as the VMM and interacts with the Gunyah VM manager in the kernel through the `/dev/gunyah` interface to create VMs. #### Build a guest VM For more information about `crosvm` support, see [Create a secondary virtual machine](https://docs.qualcomm.com/bundle/publicresource/topics/80-70030-27/create_secondary_virtual_machine.html). After the build process completes, certain images are generated. These images get stored in the `/build-qcom-wayland/tmp-glibc/deploy/images//qcom-console-image` directory. To compile the guest VM, run the following command: export SHELL=/bin/bash && MACHINE=SOC DISTRO=qcom-wayland source setup-environment bitbake qcom-console-image Copy to clipboard #### Guest VM initrd image - The `initramfs-ostree-image-.cpio.gz` file is created for the guest VM. This image contains an initrd image, used during the boot process. - The `initramfs-ostree-image-.cpio.gz` file is generated in the `build-qcom-wayland\tmp-qcom-guestvm-glibc\deploy\images\` directory. - On the booted device, the image is stored in the `/var/gunyah/initrd.img` file within the system rootfs. #### Guest VM kernel image - `svm-initramfs-qcom-image-.cpio.gz` image is generated for the secondary virtual machine (SVM), which is the guest kernel image. - The SVM kernel image is generated in the `build-qcom-wayland/tmp-glibc/deploy/images//linux-svm-kernel-qcom` directory. - On the booted device, the image is in a `/var/gunyah/Image` file within the system rootfs. Both the `initrd.img` and the SVM kernel images are packed in the `system.img` file. The final `system.img` file is found in the same directory as the other images `/build-qcom-wayland/tmp-glibc/deploy/images//qcom-console-image`. ### Launch guest virtual machine Use the `crosvm` VMM and the Gunyah hypervisor to launch the guest virtual machines. To launch the VM, run the following command: # /usr/bin/crosvm --log-level=debug --no-syslog run --disable-sandbox --hypervisor \ gunyah --protected-vm-without-firmware \ --serial=type=stdout,hardware=virtio-console,console,stdin,num=1 \ --serial=type=stdout,hardware=serial,earlycon,num=1 \ --initrd /var/gunyah/initrd.img --no-balloon --no-rng \ --params "rw root=/dev/ram earlyprintk=serial panic=0" \ /var/gunyah/Image Copy to clipboard The following are the supported parameters for the `crosvm` command to launch guest VMs: Table: Supported parameters | Parameters | Description | | --- | --- | | /usr/bin/crosvm
Copy to clipboard | Shows the path of the `crosvm` binary | | --log-level=debug
Copy to clipboard | Sets the logging level to debug while running `crosvm` | | --no-syslog
Copy to clipboard | Disables syslog | | --disable-sandbox
Copy to clipboard | Disables sandboxing | | --hypervisor gunyah
Copy to clipboard | Specifies the hypervisor to be used (in this case, `gunyah`) | | --protected-vm-without-firmware
Copy to clipboard | Indicates that the VM is protected and does not require firmware | | --serial=...
Copy to clipboard | Configures serial devices for input/output | | --initrd /var/gunyah/initrd.img
Copy to clipboard | Specifies the initial RAM disk (initrd) image | | --no-balloon
Copy to clipboard | Disables memory ballooning | | --no-rng
Copy to clipboard | Disables the entropy source used to seed the guest OS entropy pool | | --params "..."
Copy to clipboard | Specifies the kernel command-line options | | /var/gunyah/Image
Copy to clipboard | Specifies the path to the kernel image | #### View VM and boot logs The following sample output shows the VM logs: bash-5.1# cat /proc/cpuinfo processor : 0 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 crc32 atomics cpuid asimdrdm dcpop asimddp CPU implementer : 0x00 CPU architecture: 8 CPU variant : 0x0 CPU part : 0x048 CPU revision : 0 bash-5.1# cat /proc/meminfo MemTotal: 161656 kB MemFree: 124940 kB MemAvailable: 124032 kB Buffers: 0 kB Cached: 19816 kB SwapCached: 0 kB Active: 12 kB Copy to clipboard The following code snippet shows the boot logs: [2022-04-28T17:43:03.290477745+00:00 DEBUG crosvm::crosvm::sys::linux] creating hypervisor: Gunyah { device: None } [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0480] [ 0.000000] Linux version 6.6.0 (oe-user@oe-host) (aarch64-qcom-linux-gcc (GCC) 11.4.0, GNU ld (GNU Binutils) 2.38.20220708) #1 SMP PREEMPT Wed Feb 7 04:56:59 UTC 2024 [ 0.000000] KASLR enabled [ 0.000000] random: crng init done [ 0.000000] Machine model: linux,dummy-virt [ 0.000000] earlycon: uart8250 at MMIO 0x00000000000003f8 (options '') [ 0.000000] printk: bootconsole [uart8250] enabled [ 0.000000] efi: UEFI not found. [ 0.000000] software IO TLB: Reserved memory: created restricted DMA pool at 0x0000000090000000, size 64 MiB [ 0.000000] OF: reserved mem: initialized node restricted_dma_reserved@90000000, compatible id restricted-dma-pool [ 0.000000] OF: reserved mem: 0x0000000090000000..0x0000000093ffffff (65536 KiB) map non-reusable restricted_dma_reserved@90000000 [ 0.000000] NUMA: No NUMA configuration found [ 0.000000] NUMA: Faking a node at [mem 0x0000000080000000-0x0000000093ffffff] [ 0.000000] NUMA: NODE_DATA [mem 0x8ff509c0-0x8ff52fff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000080000000-0x0000000093ffffff] [ 0.000000] DMA32 empty [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000080000000-0x0000000093ffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x0000000093ffffff] [ 0.000000] On node 0, zone DMA: 16384 pages in unavailable ranges [ 0.000000] cma: Reserved 32 MiB at 0x000000008d600000 on node -1 [ 0.000000] psci: probing for conduit method from DT. [ 0.000000] psci: PSCIv1.1 detected in firmware. [ 0.000000] psci: Using standard PSCI v0.2 function IDs [ 0.000000] psci: MIGRATE_INFO_TYPE not supported. [ 0.000000] psci: SMC Calling Convention v1.3 [ 0.000000] percpu: Embedded 31 pages/cpu s86568 r8192 d32216 u126976 [ 0.000000] Detected PIPT I-cache on CPU0 [ 0.000000] CPU features: detected: GIC system register CPU interface [ 0.000000] CPU features: detected: Spectre-v4 [ 0.000000] CPU features: kernel page table isolation forced ON by KASLR [ 0.000000] CPU features: detected: Kernel page table isolation (KPTI) [ 0.000000] alternatives: applying boot alternatives [ 0.000000] Kernel command line: panic=-1 console=hvc0 earlycon=uart8250,mmio,0x3f8 rw root=/dev/ram earlyprintk=serial panic=0 [ 0.000000] Unknown kernel command line parameters "earlyprintk=serial", will be passed to user space. [ 0.000000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes, linear) [ 0.000000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes, linear) [ 0.000000] Fallback order for Node 0: 0 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 80640 [ 0.000000] Policy zone: DMA [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] software IO TLB: area num 1. [ 0.000000] software IO TLB: mapped [mem 0x0000000089600000-0x000000008d600000] (64MB) [ 0.000000] Memory: 116344K/327680K available (14528K kernel code, 3938K rwdata, 7112K rodata, 6080K init, 571K bss, 178568K reserved, 32768K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] trace event string verifier disabled [ 0.000000] rcu: Preemptible hierarchical RCU implementation. [ 0.000000] rcu: RCU event tracing is enabled. [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1. [ 0.000000] Trampoline variant of Tasks RCU enabled. [ 0.000000] Tracing variant of Tasks RCU enabled. [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 [ 0.000000] GICv3: 988 SPIs implemented [ 0.000000] GICv3: 0 Extended SPIs implemented [ 0.000000] Root IRQ handler: gic_handle_irq [ 0.000000] GICv3: GICv3 features: 16 PPIs [ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x000000003ffd0000 [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. [ 0.000000] arch_timer: cp15 timer(s) running at 19.20MHz (virt). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns [ 0.000000] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns [ 0.002616] arm-pv: using stolen time PV [ 0.003945] Console: colour dummy device 80x25 [ 0.005300] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800) [ 0.008475] pid_max: default: 32768 minimum: 301 [ 0.009923] LSM: initializing lsm=capability,selinux,integrity [ 0.011702] SELinux: Initializing. [ 0.012884] Mount-cache hash table entries: 1024 (order: 1, 8192 bytes, linear) [ 0.015180] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes, linear) [ 0.017809] cacheinfo: Unable to detect cache hierarchy for CPU 0 [ 0.019820] RCU Tasks: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. [ 0.022107] RCU Tasks Trace: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. [ 0.024472] rcu: Hierarchical SRCU implementation. [ 0.025891] rcu: Max phase no-delay instances is 1000. [ 0.027767] EFI services will not be available. [ 0.029190] smp: Bringing up secondary CPUs ... [ 0.030713] smp: Brought up 1 node, 1 CPU [ 0.032002] SMP: Total of 1 processors activated. [ 0.033471] CPU features: detected: 32-bit EL0 Support [ 0.035048] CPU features: detected: Data cache clean to the PoU not required for I/D coherence [ 0.037742] CPU features: detected: Common not Private translations [ 0.039678] CPU features: detected: CRC32 instructions [ 0.041275] CPU features: detected: LSE atomic instructions [ 0.043105] CPU features: detected: Privileged Access Never [ 0.044891] CPU: All CPU(s) started at EL1 [ 0.046161] alternatives: applying system-wide alternatives [ 0.050071] devtmpfs: initialized [ 0.051500] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.054767] futex hash table entries: 256 (order: 2, 16384 bytes, linear) [ 0.057122] pinctrl core: initialized pinctrl subsystem [ 0.058872] DMI not present or invalid. [ 0.060334] NET: Registered PF_NETLINK/PF_ROUTE protocol family [ 0.062534] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations [ 0.064964] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations [ 0.067353] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations [ 0.069943] audit: initializing netlink subsys (disabled) [ 0.071632] audit: type=2000 audit(0.056:1): state=initialized audit_enabled=0 res=1 [ 0.074141] thermal_sys: Registered thermal governor 'step_wise' [ 0.074143] thermal_sys: Registered thermal governor 'power_allocator' [ 0.076118] cpuidle: using governor menu [ 0.079536] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. [ 0.081693] ASID allocator initialised with 32768 entries [ 0.083662] Serial: AMBA PL011 UART driver [ 0.085582] Modules: 2G module region forced by RANDOMIZE_MODULE_REGION_FULL [ 0.087812] Modules: 0 pages in range for non-PLT usage [ 0.087813] Modules: 516176 pages in range for PLT usage [ 0.091914] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages [ 0.099837] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page [ 0.101815] HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages [ 0.107895] HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page [ 0.109875] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages [ 0.116064] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page [ 0.118084] HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages [ 0.124190] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page [ 0.128423] ACPI: Interpreter disabled. [ 0.132206] iommu: Default domain type: Translated [ 0.133734] iommu: DMA domain TLB invalidation policy: strict mode [ 0.135749] SCSI subsystem initialized [ 0.140957] usbcore: registered new interface driver usbfs [ 0.142744] usbcore: registered new interface driver hub [ 0.144353] usbcore: registered new device driver usb [ 0.149976] pps_core: LinuxPPS API ver. 1 registered [ 0.151488] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti [ 0.162194] PTP clock support registered [ 0.163436] EDAC MC: Ver: 3.0.0 [ 0.164532] scmi_core: SCMI protocol bus registered [ 0.166176] FPGA manager framework [ 0.171350] Advanced Linux Sound Architecture Driver Initialized. [ 0.173213] vgaarb: loaded [ 0.174176] clocksource: Switched to clocksource arch_sys_counter [ 0.235827] VFS: Disk quotas dquot_6.6.0 [ 0.237108] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 0.239428] pnp: PnP ACPI: disabled [ 0.241483] NET: Registered PF_INET protocol family [ 0.243293] IP idents hash table entries: 8192 (order: 4, 65536 bytes, linear) [ 0.245817] tcp_listen_portaddr_hash hash table entries: 256 (order: 0, 4096 bytes, linear) [ 0.248604] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) [ 0.251034] TCP established hash table entries: 4096 (order: 3, 32768 bytes, linear) [ 0.253323] TCP bind hash table entries: 4096 (order: 5, 131072 bytes, linear) [ 0.255664] TCP: Hash tables configured (established 4096 bind 4096) [ 0.257584] UDP hash table entries: 256 (order: 1, 8192 bytes, linear) [ 0.259650] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear) [ 0.261768] NET: Registered PF_UNIX/PF_LOCAL protocol family [ 0.263829] RPC: Registered named UNIX socket transport module. [ 0.265673] RPC: Registered udp transport module. [ 0.267186] RPC: Registered tcp transport module. [ 0.268641] RPC: Registered tcp-with-tls transport module. [ 0.270380] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.272421] PCI: CLS 0 bytes, default 64 [ 0.273680] Unpacking initramfs... [ 0.278241] kvm [1]: HYP mode not available [ 0.279783] Initialise system trusted keyrings [ 0.286209] workingset: timestamp_bits=42 max_order=16 bucket_order=0 [ 0.288474] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.294313] NFS: Registering the id_resolver key type [ 0.295881] Key type id_resolver registered [ 0.297197] Key type id_legacy registered [ 0.302225] nfs4filelayout_init: NFSv4 File Layout Driver Registering... [ 0.304407] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering... [ 0.310289] 9p: Installing v9fs 9p2000 file system support [ 0.320607] NET: Registered PF_ALG protocol family [ 0.322022] Key type asymmetric registered [ 0.330205] Asymmetric key parser 'x509' registered [ 0.331833] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245) [ 0.334140] io scheduler mq-deadline registered [ 0.342201] io scheduler kyber registered [ 0.343459] io scheduler bfq registered [ 0.353648] pci-host-generic 10000.pci: assigned reserved memory node restricted_dma_reserved@90000000 [ 0.362220] pci-host-generic 10000.pci: host bridge /pci ranges: [ 0.364055] pci-host-generic 10000.pci: MEM 0x0002000000..0x0003ffffff -> 0x0002000000 [ 0.370193] pci-host-generic 10000.pci: MEM 0x0094800000..0xffffffffff -> 0x0094800000 [ 0.372927] pci-host-generic 10000.pci: Memory resource size exceeds max for 32 bits [ 0.382221] PCI: OF: PROBE_ONLY enabled [ 0.383535] pci-host-generic 10000.pci: ECAM at [mem 0x00010000-0x0100ffff] for [bus 00] [ 0.386134] pci-host-generic 10000.pci: PCI host bridge to bus 0000:00 [ 0.394279] pci_bus 0000:00: root bus resource [bus 00] [ 0.395912] pci_bus 0000:00: root bus resource [mem 0x02000000-0x03ffffff] [ 0.397972] pci_bus 0000:00: root bus resource [mem 0x94800000-0xffffffffff] [ 0.406329] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000 [ 0.409065] pci 0000:00:01.0: [1af4:1043] type 00 class 0x00ff00 [ 0.419597] pci 0000:00:01.0: reg 0x10: [mem 0x02000000-0x02007fff] [ 0.425686] Freeing initrd memory: 6464K [ 0.428105] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold [ 0.430575] pci 0000:00:02.0: [1b36:0011] type 00 class 0xffff00 [ 0.432661] pci 0000:00:02.0: reg 0x10: [mem 0x02008000-0x0200800f] [ 0.436076] pci 0000:00:00.0: Limiting direct PCI/PCI transfers [ 0.438471] virtio-pci 0000:00:01.0: assigned reserved memory node restricted_dma_reserved@90000000 [ 0.443123] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 0.445534] 2e8.U6_16550A: ttyS0 at MMIO 0x2e8 (irq = 14, base_baud = 115200) is a 16550A [ 0.448422] 2f8.U6_16550A: ttyS1 at MMIO 0x2f8 (irq = 14, base_baud = 115200) is a 16550A [ 0.451159] 3e8.U6_16550A: ttyS2 at MMIO 0x3e8 (irq = 15, base_baud = 115200) is a 16550A [ 0.453983] 3f8.U6_16550A: ttyS3 at MMIO 0x3f8 (irq = 15, base_baud = 115200) is a 16550A [ 0.456935] msm_serial: driver initialized [ 0.460508] printk: console [hvc0] enabled [ 0.461772] printk: bootconsole [uart8250] disabled [ 0.475305] loop: module loaded [ 0.475957] megasas: 07.725.01.00-rc1 [ 0.476374] tun: Universal TUN/TAP device driver, 1.6 [ 0.477187] VFIO - User Level meta-driver version: 0.3 [ 0.477691] usbcore: registered new interface driver usb-storage [ 0.478075] i2c_dev: i2c /dev entries driver [ 0.478575] sdhci: Secure Digital Host Controller Interface driver [ 0.479311] sdhci: Copyright(c) Pierre Ossman [ 0.479612] sdhci-pltfm: SDHCI platform and OF driver helper [ 0.479932] ledtrig-cpu: registered to indicate activity on CPUs [ 0.480343] SMCCC: SOC_ID: ARCH_SOC_ID not implemented, skipping .... [ 0.480864] usbcore: registered new interface driver usbhid [ 0.481329] usbhid: USB HID core driver [ 0.482042] NET: Registered PF_PACKET protocol family [ 0.482342] 9pnet: Installing 9P2000 support [ 0.482635] Key type dns_resolver registered [ 0.484383] registered taskstats version 1 [ 0.484775] Loading compiled-in X.509 certificates [ 0.486896] page_owner is disabled [ 0.487629] Key type .fscrypt registered [ 0.487943] Key type fscrypt-provisioning registered [ 0.488391] clk: Disabling unused clocks [ 0.488759] ALSA device list: [ 0.489050] No soundcards found. [ 0.490311] Freeing unused kernel memory: 6080K [ 0.498264] Run /init as init process Starting version 250.5+ bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell bash-5.1# Copy to clipboard #### Launch a VM with two CPUs and default RAM To launch a guest VM with two CPUs, use the `--cpus num-cores=2` parameter: #/usr/bin/crosvm --log-level=debug --no-syslog run --disable-sandbox --hypervisor \ gunyah --protected-vm-without-firmware \ --cpus num-cores=2 \ --serial=type=stdout,hardware=virtio-console,console,stdin,num=1 \ --serial=type=stdout,hardware=serial,earlycon,num=1 \ --initrd /var/gunyah/initrd.img --no-balloon --no-rng \ --params "rw root=/dev/ram earlyprintk=serial panic=0" \ /var/gunyah/Image Copy to clipboard The following code snippet shows the VM logs: bash-5.1# cat /proc/cpuinfo processor : 0 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 crc32 atomics cpuid asimdrdm dcpop asimddp CPU implementer : 0x00 CPU architecture: 8 CPU variant : 0x0 CPU part : 0x048 CPU revision : 0 processor : 1 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 crc32 atomics cpuid asimdrdm dcpop asimddp CPU implementer : 0x00 CPU architecture: 8 CPU variant : 0x0 CPU part : 0x048 CPU revision : 0 bash-5.1# cat /proc/meminfo MemTotal: 161656 kB MemFree: 124940 kB MemAvailable: 124032 kB Buffers: 0 kB Cached: 19816 kB SwapCached: 0 kB Active: 12 kB Copy to clipboard #### Launch a VM with two CPUs and 512 MB RAM To launch a guest VM with two CPUs and 512 MB RAM, use the `--cpus num-cores=2 `` and ``--mem size=512` parameters. #/usr/bin/crosvm --log-level=debug --no-syslog run --disable-sandbox --hypervisor \ gunyah --protected-vm-without-firmware \ --cpus num-cores=2 --mem size=512 \ --serial=type=stdout,hardware=virtio-console,console,stdin,num=1 \ --serial=type=stdout,hardware=serial,earlycon,num=1 \ --initrd /var/gunyah/initrd.img --no-balloon --no-rng \ --params "rw root=/dev/ram earlyprintk=serial panic=0" \ /var/gunyah/Image Copy to clipboard The following code snippet shows the VM logs: bash-5.1# cat /proc/cpuinfo processor : 0 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 crc32 atomics cpuid asimdrdm dcpop asimddp CPU implementer : 0x00 CPU architecture: 8 CPU variant : 0x0 CPU part : 0x048 CPU revision : 0 processor : 1 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 crc32 atomics cpuid asimdrdm dcpop asimddp CPU implementer : 0x00 CPU architecture: 8 CPU variant : 0x0 CPU part : 0x048 CPU revision : 0 bash-5.1# cat /proc/meminfo MemTotal: 418304 kB MemFree: 378356 kB MemAvailable: 376048 kB Buffers: 0 kB Cached: 20308 kB SwapCached: 0 kB Active: 0 kB Copy to clipboard #### Launch a VM with block device To launch the VM, run the following command: #/usr/bin/crosvm --log-level=debug --no-syslog run --disable-sandbox --hypervisor \ gunyah --protected-vm-without-firmware \ --block disk.img \ --cpus num-cores=2 --mem size=256 \ --serial=type=stdout,hardware=virtio-console,console,stdin,num=1 \ --serial=type=stdout,hardware=serial,earlycon,num=1 \ --initrd /var/gunyah/initrd.img --no-balloon --no-rng \ --params "rw root=/dev/ram earlyprintk=serial panic=0" \ /var/gunyah/Image Copy to clipboard - Use the `--block` flag to specify the block device name (in this case, disk.img). - This flag creates `/dev/vda, /dev/vdb`, and `/dev/vd*` nodes in the guest VM. bash-5.1# ls -al /dev/block/ total 0 drwxr-xr-x 2 root root 220 Jan 1 00:00 . drwxr-xr-x 9 root root 2980 Jan 1 00:00 .. lrwxrwxrwx 1 root root 6 Jan 1 00:00 254:0 -> ../vda lrwxrwxrwx 1 root root 8 Jan 1 00:00 7:0 -> ../loop0 lrwxrwxrwx 1 root root 8 Jan 1 00:00 7:1 -> ../loop1 Copy to clipboard To mount the device in the guest VM, run the following command: `mount -t ext4 /dev/vda /mount-point`. bash-5.1# mkdir /data bash-5.1# mount -t ext4 /dev/vda /data [ 112.311376] EXT4-fs (vda): mounted filesystem 4b577765-65ad-4fd8-910c-0eac437d8afb r/w with ordered data mode. Quota mode: none. Copy to clipboard ### KVM overview A kernel-based virtual machine (KVM) is an open-source virtualization module integrated into the Linux kernel. This integration allows the KVM to act as a hypervisor. KVM facilitates hardware-assisted virtualization for guest operating systems. Note KVM is supported on Dragonwing™ IQ-8275 and Dragonwing IQ-9075 SoCs only. **Figure: High-level overview of KVM/QEMU virtualization** The following are the prerequisites to enable KVM Hypervisor on Arm CPU-based systems: - The Boot loader starts the Linux kernel in the exception level 2 (EL2) - `CONFIG_KVM` is enabled in the kernel configuration To verify if KVM is available on the device, run the following command to verify the presence of `/dev/kvm`: ls -l /dev/kvm Copy to clipboard In the Qualcomm^®^ Linux^®^ default boot flow, the Linux kernel starts in EL1 while Gunyah assumes the role of the Hypervisor. For instructions on booting the Linux kernel in EL2 to enable the KVM Hypervisor, see [UEFI](https://docs.qualcomm.com/bundle/publicresource/topics/80-70030-4/boot-developer-touchpoints.html#uefi). Consider the following when enabling KVM: - Virtual host extensions (VHE) are enabled by default on all the Qualcomm Linux SoCs that support Arm (v8.1) or later instruction sets. This configuration allows the entire Linux Kernel to run at EL2 with slight modifications. The guest OS kernel and user space run at EL1 and EL0. With VHE, transitions between the guest and host incur less penalty because the guest and host kernels operate at different exception levels. - The Linux Kernel manages all accessible non-secure memory. It does not support protected use cases that require specific isolation from the Linux kernel. The Gunyah hypervisor controls the S2 page tables of the Linux Kernel in the default boot flow. - The peripheral image loading (PIL) services are only supported on Qualcomm Dragonwing™ IQ-9075 and Qualcomm Dragonwing™ IQ-9100 SoCs only. Hence, any applications that require aDSP, cDSP, and neural signal processor (NSP) do not work when KVM is enabled for other SoCs. - The power state coordination interface (PSCI) for KVM is supported on the Linux kernel. PSCI ensures that CPU hotplug and low-power modes (LPM) function correctly with KVM. Note Secure PIL is supported on Qualcomm Dragonwing™ IQ-9075 and Qualcomm Dragonwing™ IQ-9100. Flash `xbl_config_kvm.elf` instead of `xbl_config.elf`, to boot the target with KVM using advanced light-weight power measurement and automation controller accessory (ALPACA) and the product configuration assistant tool (PCAT) tool. #### Virtual machine manager Quick emulator (QEMU) is used as the virtual machine manager (VMM) for virtualization. Libvirt acts as a management layer that interacts with QEMU to start, stop, and manage virtual machines. ##### QEMU Use QEMU as a VMM with the KVM to run VMs at near-native performance. QEMU supports emulated devices, for example, virtio devices, that provide high-performance I/O operations and allows access to USB and peripheral component interconnect (PCI) devices from the VM. The QEMU process and its threads manage a single VM. Invoke QEMU directly to create the VMs. For more information, see [QEMU’s](https://qemu-project.gitlab.io/qemu/index.html). ##### Libvirt Libvirt is a suite of tools, including an API library, a daemon (libvirtd), and a command-line utility (virsh), for managing VMs. The virsh utility is useful for managing multiple VMs. For more information, see [virsh](https://www.libvirt.org/manpages/virsh.html). #### Launch guest VM To launch an ARM64-based VM, use QEMU or virsh commands that internally work with libvirt. The commands allow you to configure the VM with CPU, memory, and storage. Specify the number of virtual CPUs and the amount of memory allocated to the VM. Additionally, the VM can boot with a ramdisk (initrd) and a `.ext4` root file system. Note Verify that the guest kernel image (`Image`), root filesystem CPIO (`rootfs.cpio.gz`), and root filesystem image (`rootfs.ext4`) are present in the `/mnt/overlay/guest` directory in the host filesystem before launching the guest. These file paths and formats are examples for reference. ##### QEMU To bring up the VMs with various configurations, run the following commands: ###### Boot with ramdisk qemu-system-aarch64 \ -M virt -m 2G \ -kernel /mnt/overlay/guest/Image \ -initrd /mnt/overlay/guest/rootfs.cpio.gz \ -cpu host --enable-kvm -smp 4 -nographic Copy to clipboard ###### Boot with rootfs image qemu-system-aarch64 \ -M virt -m 2G \ -kernel /mnt/overlay/guest/Image \ -drive file=/mnt/overlay/guest/rootfs.ext4,if=virtio,format=raw \ -append "root=/dev/vda" \ -cpu host --enable-kvm -smp 4 -nographic Copy to clipboard ##### Libvirt Libvirt enables you to use QEMU and KVM to create, interact, and manage VMs. ###### VM management with virsh virsh provides a range of commands to create, control, and monitor VMs. The following are the virsh commands used for VM management: # Define a new VM domain called initrd_simple virsh define /mnt/overlay/libvirt_initrd_simple.xml Copy to clipboard # List all domains and check the state of initrd_simple, it is not started yet virsh list --all Copy to clipboard # start the initrd_simple VM virsh start initrd_simple Copy to clipboard # connect to console virsh console initrd_simple Copy to clipboard # Disconnect from console by pressing (Ctrl + ]) key combination Copy to clipboard # shutdown the VM Copy to clipboard virsh shutdown initrd_simple Copy to clipboard # Undefine the VM if there is no intention to restart/resue it virsh undefine initrd_simple Copy to clipboard ###### Boot with ramdisk Copy the following XML content to `/mnt/overlay/guest/libvirt_initrd_simple.xml` on the host: simple_initrd 2097152 4 /machine hvm /mnt/overlay/guest/Image /mnt/overlay/guest/rootfs.cpio.gz Copy to clipboard ###### Boot with rootfs image Copy the following XML file to the host file system in the `/mnt/overlay/guest/libvirt_rootfs_simple.xml` file. Use the VM management commands with `rootfs_simple` as VM domain/name instead of `initrd_simple`. simple_rootfs 2097152 4 /machine hvm /mnt/overlay/guest/Image root=/dev/vda Copy to clipboard > > > #### Virtio framework Virtio abstracts devices in a paravirtualized hypervisor environment. It provides an I/O paravirtualization framework to interact with the paravirtualized (paravirt) devices. The virtual machine monitor (VMM) or hypervisor (HYP) emulates most of the devices exposed to virtual machines (VMs) using virtio. #### Key features The following are the key features of virtual network: - Paravirtualization and full virtualization > > > - Full virtualization: In a fully virtual environment, the guest VM does not recognize the hypervisor, it runs without modifications. However, full virtualization results in higher overhead due to the device emulation. > - Paravirtualization: In a paravirtualize environment, the VM recognizes the hypervisor and requires modifications to the OS. Paravirtualization allows efficient communication between the guest and the host. - Virtio architecture > > > > > > > > > **Figure : A high-level overview of the virtio architecture** > > - Front-end drivers: Implements in the guest OS. The front-end drivers interact with the back-end drivers > in the hypervisor > - Back-end drivers: Implements in the VMM/HYP. The back-end drivers handle the actual device emulation, > and interacts with the front-end drivers through virtual queues > - Virtual queues: Virtio uses virtual queues (virtqueues) to facilitate communication between front-end and back-end drivers. These queues are implemented as rings to manage guest-to-hypervisor transitions efficiently. - Vhost > > > Vhost is a protocol that offloads the virtio data plane implementation to another element > (user process or kernel module) to enhance performance. This offloading reduces the overhead > of context switching between the guest VM and the hypervisor. - Vhost-net: A kernel-level implementation that allows the data plane to bypass the QEMU process, to reduce latency and improves performance. For more information about v-host-net, see [Introduction to virtio-networking and vhost-net](https://www.redhat.com/en/blog/introduction-virtio-networking-and-vhost-net). - Vhost-user: A user-space implementation that handles the data plane with a separate process, to provide flexibility and better performance for workloads. For more information about v-host-user, see [Vhost-user Protocol](https://www.qemu.org/docs/master/interop/vhost-user.html). #### Benefits The following are the advantages of using virtio framework: - Standardization: Virtio provides a common interface for device emulation. It promotes code reuse and efficiency across different virtualization platforms. - Flexibility: Virtio supports block devices and network devices. #### Virtio interfaces The following are the virtio-supported interfaces: ##### 9P transport overview `virtio-9p` enables you to share files between the host and the VMs under the 9P (Plan 9 file system) protocol to enhance the performance within the virtio framework. Note Ensure that the following configurations are enabled in the host and guest kernels: Host side: CONFIG_NET_9P, CONFIG_NET_9P_VIRTIO Copy to clipboard Guest side: CONFIG_NET_9P, CONFIG_NET_9P_VIRTIO, CONFIG_9P_FS Copy to clipboard To create a `virtio-9p` shared directory, define it on the host, and configure the guest VM to mount it. See the following example: > > > root@qcs9100-ride-sx:~# ls -la /mnt/overlay/test_dir > total 12 > drwxr-xr-x. 2 root root 4096 Apr 29 21:36 . > drwxr-xr-x. 7 root root 4096 Apr 29 21:36 .. > -rw-r--r--. 1 root root 8 Apr 29 21:36 file.txt > root@qcs9100-ride-sx:~# cat /mnt/overlay/test_dir/file.txt > testing > root@qcs9100-ride-sx:~# > Copy to clipboard Create a `/mnt/overlay/test_dir` directory on the host to share it with the guest VM. Pass this information either in the libvirt XML configuration or as QEMU arguments. To configure the 9P transport, run the following command: qemu-system-aarch64 \ -M virt -m 2G \ -kernel /mnt/overlay/guest/Image \ -drive file=/mnt/overlay/guest/rootfs.ext4,if=virtio,format=raw \ -append "root=/dev/vda" \ -cpu host --enable-kvm -smp 4 -nographic \ -fsdev local,id=fsdev0,path=/mnt/overlay/test_dir,security_model=passthrough \ -device virtio-9p-pci,fsdev=fsdev0,mount_tag=hostshare Copy to clipboard To identify and mount the shared directory on the guest VM, use the `fsdev0` and `hostshare` filesystem devices. To launch the Libvirt guest VM from the libvirt interface with the following sample XML, see [Libvirt](https://docs.qualcomm.com/doc/80-70030-3/topic/virtualization.html#id7). simple_9p 2097152 4 /machine hvm /mnt/overlay/guest/Image root=/dev/vda Copy to clipboard Note Copy the XML content to `/mnt/overlay/guest/libvirt_virtio_9p.xml` file in the host. After the guest VM boots up, verify if the virtio device is probed successfully. > > > root@v8a-arm64:~# lspci > 00:00.0 Host bridge: Red Hat, Inc. QEMU PCIe Host bridge > 00:01.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.1 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.2 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 01:00.0 Unclassified device [0002]: Red Hat, Inc. Virtio 1.0 filesystem (rev 01) > 02:00.0 SCSI storage controller: Red Hat, Inc. Virtio 1.0 block device (rev 01) > root@v8a-arm64:~#root@v8a-arm64:~# cat /sys/bus/pci/devices/0000\:01\:00.0/virtio0/uevent > DRIVER=9pnet_virtio > MODALIAS=virtio:d00000009v00001AF4 > root@v8a-arm64:~# > Copy to clipboard To mount the shared directory in the guest VM, run the following command: mount -t 9p -o trans=virtio hostshare mountpoint Copy to clipboard ##### VSOCK overview VSOCK is a virtual socket interface that allows communication between VMs and the host OS. It’s used in KVM and QEMU. VSOCK is supported through a virtio interface. virtio-vsock is a vhost-based virtio device where the host kernel manages all the data transfer while the KVM hypervisor controls the information. To create a VSOCK connection in a KVM and QEMU environment, specify the context identifier (CID) and port the number. The CID is a unique identifier assigned to each VM in a VSOCK environment, which is used to route communication between the host and the VMs. The host has a CID of 2 while VMs are assigned CIDs starting from 3 and above. The following table lists the CID values: Table: CID values | CID | Description | | --- | --- | | -1 | Any address for binding | | 0 | Hypervisor | | 1 | Loopback | | 2 | Host | Note Ensure that the following configurations are enabled in the host and guest kernels. Host side: CONFIG_VSOCKETS, CONFIG_VHOST_VSOCK Guest side: CONFIG_VSOCKETS, CONFIG_VIRTIO_VSOCKETS Copy to clipboard - Enable VSOCK device: To enable the VSOCK device, specify the device in the VM configuration file (libvirt XML), or pass an argument to QEMU. qemu-system-aarch64 \ -machine virt -m 2G \ -kernel /mnt/overlay/guest/Image \ -drive file=/mnt/overlay/guest/rootfs.ext4,if=virtio,format=raw \ -append "root=/dev/vda" \ -cpu host --enable-kvm -smp 4 -nographic \ -device vhost-vsock-pci,guest-cid=73 Copy to clipboard In this command, `guest-cid=73` specifies the CID for the VM. - Launch the guest VM using the libvirt interface: To use the VSOCK device with libvirt, define the VSOCK device in the VM XML configuration file. To launch the guest VM using the libvirt interface, see [Libvirt](https://docs.qualcomm.com/doc/80-70030-3/topic/virtualization.html#id7). Copy the XML content to `/mnt/overlay/guest/libvirt_virtio_vsock.xml` on the host. After the Guest VM boots up, verify that the device is probed successfully. > > > root@v8a-arm64:~# lspci > 00:00.0 Host bridge: Red Hat, Inc. QEMU PCIe Host bridge > 00:01.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.1 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.2 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 01:00.0 SCSI storage controller: Red Hat, Inc. Virtio 1.0 block device (rev 01) > 02:00.0 Communication controller: Red Hat, Inc. Virtio 1.0 socket (rev 01) > root@v8a-arm64:~# > root@v8a-arm64:~# cat /sys/bus/pci/devices/0000\:02\:00.0/virtio1/uevent > DRIVER=vmw_vsock_virtio_transport > MODALIAS=virtio:d00000013v00001AF4 > root@v8a-arm64:~# > Copy to clipboard To verify the host-to-guest and guest-to-host interaction, use the `socat` utility. Ensure that the `socat` utility is supported on host and guest. - On the host, verify the following port: > > > socat STDIN VSOCK-LISTEN:1234 > Copy to clipboard - On the guest, connect to the host using the host CID (2): socat STDOUT VSOCK-CONNECT:2:1234 Copy to clipboard - In this setup, the guest and host show the same values. ##### Virtio block overview The virtio block is a standardized way to present block devices to the VM. Each virtio block device appears as a disk inside the guest VM. The virtio block allows the VMs to read and write operations. The following are the key features of the virtio-block device: - Simplicity: Easy to implement and use - Performance: Designed to minimize overhead and maximize throughput - Flexibility: Designed to use with various types of storage back ends Note Ensure that `CONFIG_VIRTIO_BLK` is enabled in the guest kernel. To use a virtio-block device, do the following: 1. To configure the VM for including a virtio-block device, specify the device in the VM configuration file (libvirt XML), or pass an argument to QEMU. 1. To enable the virtio-block device in the VM, use the following QEMU command: qemu-system-aarch64 \ -M virt -m 2G \ -kernel /mnt/overlay/guest/Image \ -drive file=/mnt/overlay/guest/rootfs.ext4,if=virtio,format=raw \ -append "root=/dev/vda" \ -cpu host --enable-kvm -smp 4 -nographic \ -drive file=/mnt/overlay/guest/disk.img,if=virtio,format=raw Copy to clipboard In this command, `rootfs.ext4` and `disk.img` are the disks inside the guest VM. 2. Launch the guest VM using the libvirt interface: To launch the guest VM with the following sample XML, see [Libvirt](https://docs.qualcomm.com/doc/80-70030-3/topic/virtualization.html#id7): simple_block_device 2097152 4 /machine hvm /mnt/overlay/guest/Image root=/dev/vda Copy to clipboard Note Copy the XML content to `/mnt/overlay/guest/libvirt_virtio_blk.xml` on the host. 2. The guest OS detects the virtio-block device and initializes it. In this process, the guest driver communicates with the device to set up the necessary data structures and queues. > > > root@v8a-arm64:~# dmesg | grep virtio > [ 0.225425] virtio-pci 0000:01:00.0: enabling device (0000 -> 0002) > [ 0.227073] virtio-pci 0000:02:00.0: enabling device (0000 -> 0002) > [ 0.234012] virtio_blk virtio0: 4/0/0 default/read/poll queues > [ 0.235405] virtio_blk virtio0: [vda] 2220734 512-byte logical blocks (1.14 GB/1.06 GiB) > [ 0.241213] virtio_blk virtio1: 4/0/0 default/read/poll queues > [ 0.242418] virtio_blk virtio1: [vdb] 8192000 512-byte logical blocks (4.19 GB/3.91 GiB) > root@v8a-arm64:~# > root@v8a-arm64:~# lspci > 00:00.0 Host bridge: Red Hat, Inc. QEMU PCIe Host bridge > 00:01.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.1 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.2 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 01:00.0 SCSI storage controller: Red Hat, Inc. Virtio 1.0 block device (rev 01) > 02:00.0 SCSI storage controller: Red Hat, Inc. Virtio 1.0 block device (rev 01) > root@v8a-arm64:~# > Copy to clipboard 3. After initializing, you can use the virtio-block and other block devices. The guest OS performs read and write operations on the virtio driver and passes the operations to the host for processing. 4. To manage the virtio-block device, use the standard tools and commands available in the guest OS. For example, `lsblk` and `df`. ##### Virtio-IOMMU overview Virtio-IOMMU is a paravirtualized input/output memory management unit (IOMMU) that provides direct memory access (DMA) management in the virtual environments. Virtio-IOMMU integrates with the existing software APIs, such as virtual function I/O (VFIO) and removes the need for page table emulation, making it a lightweight and high-performance solution. Virtio-IOMMU acts as a proxy for physical IOMMUs and manages the devices assigned to the guest. As virtual IOMMU, it manages, emulates, and paravirtualizes the devices. The following are the key features of Virtio-IOMMU: - Paravirtualization: Leverages existing transport mechanisms and reduces overhead. - Flexibility: Supports PCI passthrough and shares virtual memory. - Integration: Integrates with software APIs and enhances compatibility. For example, VFIO. Note Ensure that `CONFIG_VIRTIO_IOMMU` is enabled in the guest kernel. To use a Virtio-IOMMU device, do the following: 1. To configure the VM for including a Virtio-IOMMU device, specify the device in the VM configuration file (XML), or pass an argument to QEMU. > > > 1. Enable a Virtio-IOMMU device: To enable the Virtio-IOMMU device in the VM, use the following QEMU command: > > > > > > > > > > qemu-system-aarch64 \ > > -M virt -m 2G \ > > -kernel /mnt/overlay/guest/Image \ > > -drive file=/mnt/overlay/guest/rootfs.ext4,if=virtio,format=raw \ > > -append "root=/dev/vda" \ > > -cpu host --enable-kvm -smp 4 -nographic \ > > -device virtio-iommu-pci > > Copy to clipboard > > > 2. Launch guest VM using the libvirt interface: To launch the guest VM with the following sample XML, see [Libvirt](https://docs.qualcomm.com/doc/80-70030-3/topic/virtualization.html#id7). > > > > > > > > > > > > simple_iommu > > 2097152 > > 4 > > > > /machine > > > > > > hvm > > /mnt/overlay/guest/Image > > root=/dev/vda > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Copy to clipboard > > > > Note > > > Copy the XML content to `/mnt/overlay/guest/libvirt_virtio_iommu.xml` on the host. 2. The guest OS detects the Virtio-IOMMU device and initializes it. In this process, the guest driver communicates with the device to set up the necessary data structures and mappings. > > > root@v8a-arm64:~# dmesg | grep virtio > [ 0.184166] virtio-pci 0000:00:03.0: enabling device (0000 -> 0002) > [ 0.189122] virtio_iommu virtio0: input address: 64 bits > [ 0.189516] virtio_iommu virtio0: page mask: 0xfffffffffffff000 > [ 0.220135] virtio-pci 0000:01:00.0: Adding to iommu group 0 > [ 0.220676] virtio-pci 0000:01:00.0: enabling device (0000 -> 0002) > [ 0.223065] virtio_blk virtio1: 4/0/0 default/read/poll queues > [ 0.224713] virtio_blk virtio1: [vda] 2220734 512-byte logical blocks (1.14 GB/1.06 GiB) > root@v8a-arm64:~# > Copy to clipboard > > > The DMESG logs show that the virtio-block device is attached to the IOMMU domain, > which is a part of the IOMMU group `0`. 3. After initializing, the Virtio-IOMMU device manages DMA operations for attached devices. The guest OS performs mapping and unmapping operations with the virtio driver and passes the operations to the host for processing. > > > The following example shows Virtio-IOMMU device operations: > > > root@v8a-arm64:~# cat /sys/kernel/iommu_groups/0/devices/0000\:01\:00.0/virtio1/uevent > DRIVER=virtio_blk > MODALIAS=virtio:d00000002v00001AF4 > root@v8a-arm64:~# > Copy to clipboard ##### Virtio-net overview The virtio-net device is a virtual network device that provides an interface for network operations in virtualized environments. It offers high performance and low overhead. The following are the key features of the virtio-net device: - Efficiency: Minimizes overhead and maximizes throughput. - Simplicity: Easy to implement and use. - Flexibility: Supports various network configurations and back ends. Note Ensure that `CONFIG_VIRTIO_NET` is enabled in the guest kernel. To use a virtio-net device, do the following: 1. To configure the VM for including a virtio-net device, specify the device in the VM configuration file (libvirt XML), or pass an argument to QEMU. > > > 1. To enable the virtio-net device in the VM, use the following QEMU command: > > > > > > > > > > qemu-system-aarch64 \ > > -M virt -m 2G \ > > -kernel /mnt/overlay/guest/Image \ > > -drive file=/mnt/overlay/guest/rootfs.ext4,if=virtio,format=raw \ > > -append "root=/dev/vda" \ > > -cpu host --enable-kvm -smp 4 -nographic \ > > -netdev tap,id=net0,ifname=tap0,script=no,downscript=no \ > > -device virtio-net-pci,netdev=net0 > > Copy to clipboard > > > > > > Note > > > > > > This command creates a Tap interface on the host. To create the Tap interface manually, > > run the following command: > > > > > > ip tuntap add dev tap0 mode tap > > Copy to clipboard > > > 2. To launch the guest VM with the following sample XML, see [Libvirt](https://docs.qualcomm.com/doc/80-70030-3/topic/virtualization.html#id7). > > > > > > > > > > > > simple_net > > 2097152 > > 4 > > > > /machine > > > > > > hvm > > /mnt/overlay/guest/Image > > root=/dev/vda > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Copy to clipboard > > > > > > To create a tap interface for direct communication between the host VM and the guest VM, copy the XML content to `/mnt/overlay/guest/libvirt_virtio_net.xml` on the host. 2. The guest operating system detects the virtio-net device and initializes it. In this process, the guest driver communicates with the device to set up the necessary data structures and queues. > > > root@v8a-arm64:~# dmesg | grep virtio > [ 0.394365] virtio-pci 0000:01:00.0: enabling device (0000 -> 0002) > [ 0.396364] virtio-pci 0000:02:00.0: enabling device (0000 -> 0002) > [ 0.404496] virtio_blk virtio1: 4/0/0 default/read/poll queues > [ 0.406048] virtio_blk virtio1: [vda] 2220734 512-byte logical blocks (1.14 GB/1.06 GiB) > [ 0.980919] virtio_net virtio0 enp1s0: renamed from eth0 > root@v8a-arm64:~# lspci > 00:00.0 Host bridge: Red Hat, Inc. QEMU PCIe Host bridge > 00:01.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.1 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.2 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 01:00.0 Ethernet controller: Red Hat, Inc. Virtio 1.0 network device (rev 01) > 02:00.0 SCSI storage controller: Red Hat, Inc. Virtio 1.0 block device (rev 01) > root@v8a-arm64:~# > Copy to clipboard 3. Operate: After you initialize and configure the virtio-net device, use it as other network interface. The guest OS performs standard network operations with the virtio driver and passes the operations to the host for processing. To use the Tap interface, run the following network configurations on the host VM and the guest VM: - Host configuration: root@qcs9100-ride-sx:~# ip addr add 192.168.100.1/24 dev tap0 root@qcs9100-ride-sx:~# ip link set dev tap0 up Copy to clipboard - Guest configuration: root@v8a-arm64:~# ip addr add 192.168.100.2/24 dev enp1s0 root@v8a-arm64:~# ip link set dev enp1s0 up Copy to clipboard To run the network traffic on this interface, use the following example: > > > root@v8a-arm64:~# ping 192.168.100.1 > PING 192.168.100.1 (192.168.100.1): 56 data bytes > 64 bytes from 192.168.100.1: seq=0 ttl=64 time=0.364 ms > 64 bytes from 192.168.100.1: seq=1 ttl=64 time=0.156 ms > Copy to clipboard ##### Virtio-serial and virtio-console overview The virtio-serial device provides an interface for serial communication between the host VM and the guest VM in virtual environments. The following are the key features of the virtio-serial device: - Multiple ports: Supports multiple serial ports, allows various communication channels. - Efficiency: Minimizes overhead and maximizes throughput. - Flexibility: Supports different types of data exchange. For example, console access and file transfer. Note Ensure that `CONFIG_VIRTIO_CONSOLE` is enabled in the guest kernel. To use a virtio-serial device, do the following: 1. To configure the VM for including a virtio-serial device, specify the device in the VM configuration file (libvirt XML), or pass an argument to QEMU. 1. To enable the virtio-net device in the VM, use the following QEMU command: > > > qemu-system-aarch64 \ > -M virt -m 2G \ > -kernel /mnt/overlay/guest/Image \ > -drive file=/mnt/overlay/guest/rootfs.ext4,if=virtio,format=raw \ > -append "root=/dev/vda" \ > -cpu host --enable-kvm -smp 4 -nographic \ > -device virtio-serial-pci,id=virtio-serial0 \ > -chardev pty,id=charconsole0 \ > -device virtconsole,chardev=charconsole0,id=console0 \ > -chardev socket,path=/tmp/qemu.sock,server=on,wait=off,id=charchannel0 \ > -device virtserialport,chardev=charchannel0,name=org.qemu.guest_agent.0 > Copy to clipboard 2. To launch the guest VM with the following sample XML, see [Libvirt](https://docs.qualcomm.com/doc/80-70030-3/topic/virtualization.html#id7). simple_serial 2097152 4 /machine hvm /mnt/overlay/guest/Image root=/dev/vda

Copy to clipboard Note Copy the XML content to `/mnt/overlay/guest/virtio_serial.xml` on the host. 2. The guest operating system detects the virtio-serial device and initializes it. In this process, the guest driver communicates with the device to set up the necessary data structures and ports. > > > root@v8a-arm64:~# lspci > 00:00.0 Host bridge: Red Hat, Inc. QEMU PCIe Host bridge > 00:01.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.1 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.2 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 01:00.0 Communication controller: Red Hat, Inc. Virtio 1.0 console (rev 01) > 02:00.0 SCSI storage controller: Red Hat, Inc. Virtio 1.0 block device (rev 01) > root@v8a-arm64:~# > root@v8a-arm64:~# cat /sys/bus/virtio/devices/virtio0/uevent > DRIVER=virtio_console > MODALIAS=virtio:d00000003v00001AF4 > root@v8a-arm64:~# > Copy to clipboard 3. After initialization, you can use the virtio-serial device as a serial device. The guest OS performs read and write operations with the virtio driver and passes the operations to the host for processing. 4. To manage the virtio-serial device, do the following: - Monitor the performance - Verify the device status - Perform maintenance tasks - Use the standard tools and commands available in the guest OS ###### Memory balloon device support The traditional virtio memory balloon device manages the guest memory. It allows the host system to reclaim memory from VMs. The memory balloon instructs VMs to return a portion of their memory to the host. This process involves inflating the memory balloon inside the Guest VM, which reduces the memory available for other tasks within the VM. The Guest OS decides which memory pages to give back to the host, indicating which pages it does not need or access. The host then un-maps these pages from the guest VM and marks them as unavailable for the guest VM and allows the host system to use them. If the guest VM requires more memory later, the host deflates the balloon to return the pages. This feature allows each guest VM to continue running while its available memory is managed. Use the following for the virtio-balloon device to relocate physical memory between a guest VM and the host: 1. Balloon inflation: The guest driver allocates memory and informs the host. The host then reuses the inflated memory for other VMs. 2. Balloon deflation: After informing the host, the guest driver frees the previously allocated memory and enables the guest VM to use the deflated memory. `Target balloon size` controls the balloon inflation or deflation through a request to change the guest VM memory size. The resize request is sent through QEMU monitor mode or through virsh commands. The following are the key features of the virtio-balloon device: - Memory management: Adjusts memory allocation in real time based on the requirements. - Efficiency: Reclaims unused memory from idle VMs and redistributes it to the active ones. - Flexibility: Enables various virtualization setups to optimize resource usage. Note Ensure that `CONFIG_VIRTIO_BALLOON` is enabled in the guest kernel. To use a virtio-balloon device, do the following: 1. Configure the VM for including a virtio-balloon device, specify the device in the VM configuration file (libvirt XML), or pass an argument to QEMU. 1. To enable the virtio-balloon device in the VM, use the following QEMU command: qemu-system-aarch64 \ -M virt -m 2G \ -kernel /mnt/overlay/guest/Image \ -drive file=/mnt/overlay/guest/rootfs.ext4,if=virtio,format=raw \ -append "root=/dev/vda" \ -cpu host --enable-kvm -smp 4 -nographic \ -device virtio-balloon-pci,id=balloon0 Copy to clipboard 2. To launch the guest VM with the following sample XML, see [Libvirt](https://docs.qualcomm.com/doc/80-70030-3/topic/virtualization.html#id7): simple_balloon 2097152 4 /machine hvm /mnt/overlay/guest/Image root=/dev/vda Copy to clipboard Note Copy the XML content to `/mnt/overlay/guest/libvirt_virtio_balloon.xml` file on the host. 2. The guest OS detects the virtio-balloon device and initializes it. In this process, the guest driver communicates with the device to set up the necessary data structures and memory management mechanisms. > > > root@v8a-arm64:~# lspci > 00:00.0 Host bridge: Red Hat, Inc. QEMU PCIe Host bridge > 00:01.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.1 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 00:01.2 PCI bridge: Red Hat, Inc. QEMU PCIe Root port > 01:00.0 SCSI storage controller: Red Hat, Inc. Virtio 1.0 block device (rev 01) > 02:00.0 Unclassified device [00ff]: Red Hat, Inc. Virtio 1.0 memory balloon (rev 01) > root@v8a-arm64:~# > Copy to clipboard 3. After initializing, the virtio-balloon device adjusts the memory allocated to the VM. The guest OS performs memory inflation and deflation operations, which are handled by the virtio driver, and passes it to the host for processing. To adjust the guest memory, run the following virsh commands on the host: - To verify the guest VM initial memory (2 GB), run the following command: > > > root@v8a-arm64:~# cat /proc/meminfo | grep Mem > MemTotal: 1966180 kB > MemFree: 1807432 kB > MemAvailable: 1817552 kB > root@v8a-arm64:~# > Copy to clipboard - To inflate the balloon and reduce the guest VM memory to 512 MB, run the following command: root@qcs9100-ride-sx:~# virsh setmem simple_balloon 512M --live Copy to clipboard - To verify the guest VM memory after inflation, run the following command: root@v8a-arm64:~# cat /proc/meminfo | grep Mem MemTotal: 393316 kB MemFree: 235708 kB MemAvailable: 245836 kB root@v8a-arm64:~# Copy to clipboard - To deflate the balloon (Guest VM memory back to 2 GB): root@qcs9100-ride-sx:~# virsh setmem simple_balloon 2G --live Copy to clipboard - To verify the guest VM memory after deflation: root@v8a-arm64:~# cat /proc/meminfo | grep Mem MemTotal: 1966180 kB MemFree: 1811844 kB MemAvailable: 1821988 kB root@v8a-arm64:~# Copy to clipboard ###### Access host devices You can use the enumerated devices on the host system from the guest. The device assignment interface to the guest varies based on the device type. Some devices act as a back end for a device emulated by QEMU, for example, UART. Configure universal asynchronous receiver transmitter (UART) as a character device (chardev) back end on the host. For more information about QEMU chardev, see [Character device options](https://www.qemu.org/docs/master/system/invocation.html#hxtool-6). PCI and USB devices work on the kernel VFIO framework. - PCI passthrough allows a guest VM to directly access a physical PCI device on the host. The VFIO framework in the Linux kernel is used for the device assignment. For more information about the VFIO, see [VFIO - Virtual Function I/O](https://docs.kernel.org/driver-api/vfio.html). - A USB device operates in Passthrough mode, allowing the guest VM to use USB peripherals connected to the host. QEMU emulates the USB controller and works with libusb on the host to present USB peripherals to the guest. For more information, see [USB emulation](https://qemu-project.gitlab.io/qemu/system/devices/usb.html). **USB passthrough overview** Identify the USB device that is enumerated on the host computer to assign it to the guest. To see all the USB devices that are enumerated on the host, use the `lusb` command. Find the device by its `vendor id` and `product id`. In the following example, `vendor id` is 0x0781 and `product id` is 0x5567 for the USB memory stick. sh-5.1# lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 0781:5567 SanDisk Corp. Cruzer Blade Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Copy to clipboard Note Copy the following XML file on the host file system in `/mnt/overlay/guest/libvirt_usb.xml` file and modify the XML file per `vendor id` and `product id`. Launch a guest VM with the following sample XML and do the following: 1. After the guest VM is launched, connect to the console. 2. Verify the `lsusb` output in the guest VM. 3. Ensure that the output lists the USB device assigned to the guest. simple_usb 2097152 4 /machine hvm /mnt/overlay/guest/Image root=/dev/vda Copy to clipboard **PCI overview** Identify the PCI device that is enumerated on the host computer to assign it to the guest. To see all the PCI devices that are enumerated on the host, use the `lspci` command. Find the device by its `[domain:]bus:device.function`. For more information about `lspci` command, see [lspci(8)—Linux manual page](https://man7.org/linux/man-pages/man8/lspci.8.html). The following example shows supported values for domain, bus, device, and function for `Ethernet controller: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz` device: - Domain is 0001 - Bus is 01 - Device is 00 - Function is 0 for sh-5.1# lspci 0000:00:00.0 PCI bridge: Qualcomm Device 0115 0000:01:00.0 Network controller: Qualcomm QCNFA765 Wireless Network Adapter (rev 01) 0001:00:00.0 PCI bridge: Qualcomm Device 0115 0001:01:00.0 Ethernet controller: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Copy to clipboard Note Copy the XML content to `/mnt/overlay/guest/libvirt_pci.xml` file and change the `hostdev` section in the XML file according to your device requirements. To launch the guest VM, see [Libvirt](https://docs.qualcomm.com/doc/80-70030-3/topic/virtualization.html#id7). After you launch the guest VM, connect it to the console and verify the `lspci` output in the guest. Ensure that the output lists the PCI device assigned to the guest. Note The output shows different slots based on the guest PCI topology selected by QEMU and Libvirt. When `managed` is marked as *yes* in `hostdev` in the following XML, the PCI device gets detached from the host before it passes on to the guest, and re-attached to the host after the guest exits. For more information, see [USB / PCI / SCSI devices](https://libvirt.org/formatdomain.html#usb-pci-scsi-devices). simple_pci 2097152 4 /machine hvm /mnt/overlay/guest/Image root=/dev/vda

Copy to clipboard **UART passthrough overview** Identify the `/dev/ttyX` teletype (TTY) device file corresponding to the UART to use it from the guest. Ensure that no application on the host is using this interface. Note Copy the XML content to `/mnt/overlay/guest/libvirt_uart.xml` file on the host and modify the TTY device file as per your device requirements. Launch a guest VM and connect to the console. The serial interface at `/dev/virtio-ports/hostserial` acts as a front end to the real UART on the host. Use the following XML file: simple_uart 2097152 4 /machine hvm /mnt/overlay/guest/Image root=/dev/vda

Copy to clipboard #### KVM customizations The following features allow you to modify the KVM hypervisor to meet specific requirements: #### Remote command execution To enable the QEMU guest agent in the guest OS user space, run the remote commands on the guest VMs from the host. For more information about `qemu-ga`, see [QEMU Guest Agent](https://qemu-project.gitlab.io/qemu/interop/qemu-ga.html). `qemu-agent-command` is the virsh command that includes `guest-exec` and `guest-exec-status` as the subcommands to execute and verify the status or output of the guest VMs. For more information about how to configure `qemu-ga` through virtio-serial interface, see [QEMU Guest Agent](https://wiki.libvirt.org/Qemu_guest_agent.html). For more information about how `virt-exec` wraps virsh commands and provides an interface, see [kvm-qemu/virt-exec](https://github.com/ildar-shaimordanov/my-scripts/blob/master/kvm-qemu/virt-exec). The following example shows how to run `/proc/meminfo` on the guest VM from the host computer using a `virt-exec` utility: sh-5.2# ./virt-exec testvm cat /proc/meminfo | grep -i total MemTotal: 1968056 kB SwapTotal: 0 kB VmallocTotal: 133141626880 kB CmaTotal: 32768 kB HugePages_Total: 0 Copy to clipboard ##### Watchdog configuration A QEMU-emulated I6300 ESB watchdog device is supported in the guest VM. The Linux kernel has a driver for this watchdog and exposes the standard watchdog character device. To enable the watchdog, set `CONFIG_I6300ESB_WDT` in the guest kernel configuration. A guest user space daemon must pet the watchdog. The guest Libvirt XML has an option to select `poweroff` or `reset` on watchdog timeout. For more information, see [Watchdog devices](https://libvirt.org/formatdomain.html#watchdog-devices). Add the following snippet to the guest XML to enable I6300 ESB watchdog emulation in QEMU. The default action is `reset`, which restarts the guest. Copy to clipboard ##### KVM traces To enable KVM traces, run the following command: echo 1 > /sys/kernel/tracing/events/kvm/enable Copy to clipboard The KVM guest interactions are recorded in kernel function trace (ftrace). To inspect interactions between KVM and guest VMs, read the kernel trace buffer. QEMU also supports trace events, which can be redirected to kernel ftrace. For more information about how to redirect QEMU trace back-end events to the ftrace buffer, see [Trace backends](https://qemu-project.gitlab.io/qemu/devel/tracing.html#trace-backends). This option is selected by default in the Qualcomm Linux release. To launch a guest VM with virtio traces enabled in the QEMU code, run the following command: qemu-system-aarch64 \ -M virt -m 2G \ -kernel /mnt/overlay/guest/Image \ -drive file=/mnt/overlay/guest/rootfs.ext4,if=virtio,format=raw \ -append "root=/dev/vda" \ -cpu host --enable-kvm -smp 4 -nographic \ -trace "virtio*" Copy to clipboard Last Published: Jun 25, 2026 [Previous Topic Real-time (RT) kernel overview](https://docs.qualcomm.com/bundle/publicresource/80-70030-3/topics/real_time_kernel_overview.md) [Next Topic Capture the kernel logs](https://docs.qualcomm.com/bundle/publicresource/80-70030-3/topics/capture-the-kernel-logs.md)