From nobody Thu Nov 6 19:04:18 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1488376361553804.0924904826469; Wed, 1 Mar 2017 05:52:41 -0800 (PST) Received: from localhost ([::1]:46657 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cj4gJ-00014R-QC for importer@patchew.org; Wed, 01 Mar 2017 08:52:39 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cj4fU-00010i-24 for qemu-devel@nongnu.org; Wed, 01 Mar 2017 08:51:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cj4fR-0003lb-59 for qemu-devel@nongnu.org; Wed, 01 Mar 2017 08:51:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54248) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cj4fQ-0003kE-SL for qemu-devel@nongnu.org; Wed, 01 Mar 2017 08:51:45 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8660E64A63 for ; Wed, 1 Mar 2017 13:51:44 +0000 (UTC) Received: from nilsson.home.kraxel.org (ovpn-116-35.ams2.redhat.com [10.36.116.35]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v21DpgVh027023; Wed, 1 Mar 2017 08:51:42 -0500 Received: by nilsson.home.kraxel.org (Postfix, from userid 500) id AF3E480945; Wed, 1 Mar 2017 14:51:39 +0100 (CET) From: Gerd Hoffmann To: qemu-devel@nongnu.org Date: Wed, 1 Mar 2017 14:51:37 +0100 Message-Id: <1488376297-19711-3-git-send-email-kraxel@redhat.com> In-Reply-To: <1488376297-19711-1-git-send-email-kraxel@redhat.com> References: <1488376297-19711-1-git-send-email-kraxel@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 01 Mar 2017 13:51:44 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 2/2] mach-virt: Provide sample configuration files X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrea Bolognani , Gerd Hoffmann Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Andrea Bolognani These are very much like the sample configuration files for q35, and can be used both as documentation and as a starting point for creating your own guest. Two sample configuration files are provided: * mach-virt-graphical.cfg can be used to start a fully-featured (USB, graphical console, etc.) guest that uses VirtIO devices; * mach-virt-serial.cfg is similar but has a minimal set of devices and uses the serial console. All configuration files are fully commented and neatly organized. Signed-off-by: Andrea Bolognani Reviewed-by: Andrew Jones Reviewed-by: Laszlo Ersek Message-id: 1487326479-8664-3-git-send-email-abologna@redhat.com Signed-off-by: Gerd Hoffmann --- docs/mach-virt-graphical.cfg | 281 +++++++++++++++++++++++++++++++++++++++= ++++ docs/mach-virt-serial.cfg | 243 +++++++++++++++++++++++++++++++++++++ 2 files changed, 524 insertions(+) create mode 100644 docs/mach-virt-graphical.cfg create mode 100644 docs/mach-virt-serial.cfg diff --git a/docs/mach-virt-graphical.cfg b/docs/mach-virt-graphical.cfg new file mode 100644 index 0000000..0fdf684 --- /dev/null +++ b/docs/mach-virt-graphical.cfg @@ -0,0 +1,281 @@ +# mach-virt - VirtIO guest (graphical console) +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# Usage: +# +# $ qemu-system-aarch64 \ +# -nodefaults \ +# -readconfig mach-virt-graphical.cfg \ +# -cpu host +# +# You will probably need to tweak the lines marked as +# CHANGE ME before being able to use this configuration! +# +# The guest will have a selection of VirtIO devices +# tailored towards optimal performance with modern guests, +# and will be accessed through a graphical console. +# +# --------------------------------------------------------- +# +# Using -nodefaults is required to have full control over +# the virtual hardware: when it's specified, QEMU will +# populate the board with only the builtin peripherals, +# such as the PL011 UART, plus a PCI Express Root Bus; the +# user will then have to explicitly add further devices. +# +# The PCI Express Root Bus shows up in the guest as: +# +# 00:00.0 Host bridge +# +# This configuration file adds a number of other useful +# devices, more specifically: +# +# 00:01.0 Display controller +# 00.1c.* PCI bridge (PCI Express Root Ports) +# 01:00.0 SCSI storage controller +# 02:00.0 Ethernet controller +# 03:00.0 USB controller +# +# More information about these devices is available below. + + +# Machine options +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# We use the virt machine type and enable KVM acceleration +# for better performance. +# +# Using less than 1 GiB of memory is probably not going to +# yield good performance in the guest, and might even lead +# to obscure boot issues in some cases. +# +# Unfortunately, there is no way to configure the CPU model +# in this file, so it will have to be provided on the +# command line, but we can configure the guest to use the +# same GIC version as the host. + +[machine] + type =3D "virt" + accel =3D "kvm" + gic-version =3D "host" + +[memory] + size =3D "1024" + + +# Firmware configuration +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# There are two parts to the firmware: a read-only image +# containing the executable code, which is shared between +# guests, and a read/write variable store that is owned +# by one specific guest, exclusively, and is used to +# record information such as the UEFI boot order. +# +# For any new guest, its permanent, private variable store +# should initially be copied from the template file +# provided along with the firmware binary. +# +# Depending on the OS distribution you're using on the +# host, the name of the package containing the firmware +# binary and variable store template, as well as the paths +# to the files themselves, will be different. For example: +# +# Fedora +# edk2-aarch64 (pkg) +# /usr/share/edk2/aarch64/QEMU_EFI-pflash.raw (bin) +# /usr/share/edk2/aarch64/vars-template-pflash.raw (var) +# +# RHEL +# AAVMF (pkg) +# /usr/share/AAVMF/AAVMF_CODE.fd (bin) +# /usr/share/AAVMF/AAVMF_VARS.fd (var) +# +# Debian/Ubuntu +# qemu-efi (pkg) +# /usr/share/AAVMF/AAVMF_CODE.fd (bin) +# /usr/share/AAVMF/AAVMF_VARS.fd (var) + +[drive "uefi-binary"] + file =3D "/usr/share/AAVMF/AAVMF_CODE.fd" # CHANGE ME + format =3D "raw" + if =3D "pflash" + unit =3D "0" + readonly =3D "on" + +[drive "uefi-varstore"] + file =3D "guest_VARS.fd" # CHANGE ME + format =3D "raw" + if =3D "pflash" + unit =3D "1" + + +# PCI bridge (PCI Express Root Ports) +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# We create eight PCI Express Root Ports, and we plug them +# all into separate functions of the same slot. Some of +# them will be used by devices, the rest will remain +# available for hotplug. + +[device "pcie.1"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.0" + port =3D "1" + chassis =3D "1" + multifunction =3D "on" + +[device "pcie.2"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.1" + port =3D "2" + chassis =3D "2" + +[device "pcie.3"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.2" + port =3D "3" + chassis =3D "3" + +[device "pcie.4"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.3" + port =3D "4" + chassis =3D "4" + +[device "pcie.5"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.4" + port =3D "5" + chassis =3D "5" + +[device "pcie.6"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.5" + port =3D "6" + chassis =3D "6" + +[device "pcie.7"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.6" + port =3D "7" + chassis =3D "7" + +[device "pcie.8"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.7" + port =3D "8" + chassis =3D "8" + + +# SCSI storage controller (and storage) +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# We use virtio-scsi here so that we can (hot)plug a large +# number of disks without running into issues; a SCSI disk, +# backed by a qcow2 disk image on the host's filesystem, is +# attached to it. +# +# We also create an optical disk, mostly for installation +# purposes: once the guest OS has been succesfully +# installed, the guest will no longer boot from optical +# media. If you don't want, or no longer want, to have an +# optical disk in the guest you can safely comment out +# all relevant sections below. + +[device "scsi"] + driver =3D "virtio-scsi-pci" + bus =3D "pcie.1" + addr =3D "00.0" + +[device "scsi-disk"] + driver =3D "scsi-hd" + bus =3D "scsi.0" + drive =3D "disk" + bootindex =3D "1" + +[drive "disk"] + file =3D "guest.qcow2" # CHANGE ME + format =3D "qcow2" + if =3D "none" + +[device "scsi-optical-disk"] + driver =3D "scsi-cd" + bus =3D "scsi.0" + drive =3D "optical-disk" + bootindex =3D "2" + +[drive "optical-disk"] + file =3D "install.iso" # CHANGE ME + format =3D "raw" + if =3D "none" + + +# Ethernet controller +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# We use virtio-net for improved performance over emulated +# hardware; on the host side, we take advantage of user +# networking so that the QEMU process doesn't require any +# additional privileges. + +[netdev "hostnet"] + type =3D "user" + +[device "net"] + driver =3D "virtio-net-pci" + netdev =3D "hostnet" + bus =3D "pcie.2" + addr =3D "00.0" + + +# USB controller (and input devices) +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# We add a virtualization-friendly USB 3.0 controller and +# a USB keyboard / USB tablet combo so that graphical +# guests can be controlled appropriately. + +[device "usb"] + driver =3D "nec-usb-xhci" + bus =3D "pcie.3" + addr =3D "00.0" + +[device "keyboard"] + driver =3D "usb-kbd" + bus =3D "usb.0" + +[device "tablet"] + driver =3D "usb-tablet" + bus =3D "usb.0" + + +# Display controller +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# We use virtio-gpu because the legacy VGA framebuffer is +# very troublesome on aarch64, and virtio-gpu is the only +# video device that doesn't implement it. +# +# If you're running the guest on a remote, potentially +# headless host, you will probably want to append something +# like +# +# -display vnc=3D127.0.0.1:0 +# +# to the command line in order to prevent QEMU from +# creating a graphical display window on the host and +# enable remote access instead. + +[device "video"] + driver =3D "virtio-gpu" + bus =3D "pcie.0" + addr =3D "01.0" diff --git a/docs/mach-virt-serial.cfg b/docs/mach-virt-serial.cfg new file mode 100644 index 0000000..aee9f1c --- /dev/null +++ b/docs/mach-virt-serial.cfg @@ -0,0 +1,243 @@ +# mach-virt - VirtIO guest (serial console) +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# Usage: +# +# $ qemu-system-aarch64 \ +# -nodefaults \ +# -readconfig mach-virt-serial.cfg \ +# -display none -serial mon:stdio \ +# -cpu host +# +# You will probably need to tweak the lines marked as +# CHANGE ME before being able to use this configuration! +# +# The guest will have a selection of VirtIO devices +# tailored towards optimal performance with modern guests, +# and will be accessed through the serial console. +# +# --------------------------------------------------------- +# +# Using -nodefaults is required to have full control over +# the virtual hardware: when it's specified, QEMU will +# populate the board with only the builtin peripherals, +# such as the PL011 UART, plus a PCI Express Root Bus; the +# user will then have to explicitly add further devices. +# +# The PCI Express Root Bus shows up in the guest as: +# +# 00:00.0 Host bridge +# +# This configuration file adds a number of other useful +# devices, more specifically: +# +# 00.1c.* PCI bridge (PCI Express Root Ports) +# 01:00.0 SCSI storage controller +# 02:00.0 Ethernet controller +# +# More information about these devices is available below. +# +# We use '-display none' to prevent QEMU from creating a +# graphical display window, which would serve no use in +# this specific configuration, and '-serial mon:stdio' to +# multiplex the guest's serial console and the QEMU monitor +# to the host's stdio; use 'Ctrl+A h' to learn how to +# switch between the two and more. + + +# Machine options +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# We use the virt machine type and enable KVM acceleration +# for better performance. +# +# Using less than 1 GiB of memory is probably not going to +# yield good performance in the guest, and might even lead +# to obscure boot issues in some cases. +# +# Unfortunately, there is no way to configure the CPU model +# in this file, so it will have to be provided on the +# command line, but we can configure the guest to use the +# same GIC version as the host. + +[machine] + type =3D "virt" + accel =3D "kvm" + gic-version =3D "host" + +[memory] + size =3D "1024" + + +# Firmware configuration +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# There are two parts to the firmware: a read-only image +# containing the executable code, which is shared between +# guests, and a read/write variable store that is owned +# by one specific guest, exclusively, and is used to +# record information such as the UEFI boot order. +# +# For any new guest, its permanent, private variable store +# should initially be copied from the template file +# provided along with the firmware binary. +# +# Depending on the OS distribution you're using on the +# host, the name of the package containing the firmware +# binary and variable store template, as well as the paths +# to the files themselves, will be different. For example: +# +# Fedora +# edk2-aarch64 (pkg) +# /usr/share/edk2/aarch64/QEMU_EFI-pflash.raw (bin) +# /usr/share/edk2/aarch64/vars-template-pflash.raw (var) +# +# RHEL +# AAVMF (pkg) +# /usr/share/AAVMF/AAVMF_CODE.fd (bin) +# /usr/share/AAVMF/AAVMF_VARS.fd (var) +# +# Debian/Ubuntu +# qemu-efi (pkg) +# /usr/share/AAVMF/AAVMF_CODE.fd (bin) +# /usr/share/AAVMF/AAVMF_VARS.fd (var) + +[drive "uefi-binary"] + file =3D "/usr/share/AAVMF/AAVMF_CODE.fd" # CHANGE ME + format =3D "raw" + if =3D "pflash" + unit =3D "0" + readonly =3D "on" + +[drive "uefi-varstore"] + file =3D "guest_VARS.fd" # CHANGE ME + format =3D "raw" + if =3D "pflash" + unit =3D "1" + + +# PCI bridge (PCI Express Root Ports) +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# We create eight PCI Express Root Ports, and we plug them +# all into separate functions of the same slot. Some of +# them will be used by devices, the rest will remain +# available for hotplug. + +[device "pcie.1"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.0" + port =3D "1" + chassis =3D "1" + multifunction =3D "on" + +[device "pcie.2"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.1" + port =3D "2" + chassis =3D "2" + +[device "pcie.3"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.2" + port =3D "3" + chassis =3D "3" + +[device "pcie.4"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.3" + port =3D "4" + chassis =3D "4" + +[device "pcie.5"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.4" + port =3D "5" + chassis =3D "5" + +[device "pcie.6"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.5" + port =3D "6" + chassis =3D "6" + +[device "pcie.7"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.6" + port =3D "7" + chassis =3D "7" + +[device "pcie.8"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.7" + port =3D "8" + chassis =3D "8" + + +# SCSI storage controller (and storage) +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# We use virtio-scsi here so that we can (hot)plug a large +# number of disks without running into issues; a SCSI disk, +# backed by a qcow2 disk image on the host's filesystem, is +# attached to it. +# +# We also create an optical disk, mostly for installation +# purposes: once the guest OS has been succesfully +# installed, the guest will no longer boot from optical +# media. If you don't want, or no longer want, to have an +# optical disk in the guest you can safely comment out +# all relevant sections below. + +[device "scsi"] + driver =3D "virtio-scsi-pci" + bus =3D "pcie.1" + addr =3D "00.0" + +[device "scsi-disk"] + driver =3D "scsi-hd" + bus =3D "scsi.0" + drive =3D "disk" + bootindex =3D "1" + +[drive "disk"] + file =3D "guest.qcow2" # CHANGE ME + format =3D "qcow2" + if =3D "none" + +[device "scsi-optical-disk"] + driver =3D "scsi-cd" + bus =3D "scsi.0" + drive =3D "optical-disk" + bootindex =3D "2" + +[drive "optical-disk"] + file =3D "install.iso" # CHANGE ME + format =3D "raw" + if =3D "none" + + +# Ethernet controller +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# We use virtio-net for improved performance over emulated +# hardware; on the host side, we take advantage of user +# networking so that the QEMU process doesn't require any +# additional privileges. + +[netdev "hostnet"] + type =3D "user" + +[device "net"] + driver =3D "virtio-net-pci" + netdev =3D "hostnet" + bus =3D "pcie.2" + addr =3D "00.0" --=20 1.8.3.1