From nobody Thu May 2 01:23:46 2024 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 1486575658695784.6634285401523; Wed, 8 Feb 2017 09:40:58 -0800 (PST) Received: from localhost ([::1]:60726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbWEh-00056k-RZ for importer@patchew.org; Wed, 08 Feb 2017 12:40:55 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbW9w-00028V-5S for qemu-devel@nongnu.org; Wed, 08 Feb 2017 12:36:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbW9s-0005ke-Pl for qemu-devel@nongnu.org; Wed, 08 Feb 2017 12:36:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34710) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cbW9s-0005kP-E5 for qemu-devel@nongnu.org; Wed, 08 Feb 2017 12:35:56 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 8DD8D61E4D for ; Wed, 8 Feb 2017 17:35:56 +0000 (UTC) Received: from inaba.usersys.redhat.com ([10.34.129.229]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v18HZqWX014352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Feb 2017 12:35:54 -0500 From: Andrea Bolognani To: qemu-devel@nongnu.org Date: Wed, 8 Feb 2017 18:35:30 +0100 Message-Id: <1486575331-14455-2-git-send-email-abologna@redhat.com> In-Reply-To: <1486575331-14455-1-git-send-email-abologna@redhat.com> References: <1486575331-14455-1-git-send-email-abologna@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 08 Feb 2017 17:35:56 +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] [PATCH v5 1/2] q35: Improve 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: marcel@redhat.com, drjones@redhat.com, lersek@redhat.com, kraxel@redhat.com 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" Instead of having a single sample configuration file, we now have several: * q35-emulated.cfg documents the default devices QEMU adds to a q35 guest and the additional devices that are pretty much guaranteed to be present in a physical q35-based machine; * q35-virtio-graphical.cfg can be used to start a fully-featured (USB, graphical console, audio, etc.) guest that uses VirtIO instead of emulated devices; * q35-virtio-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. --- Changes since [v4] * Improvements: - move storage configuration from the command line to the configuration files so that the command line is shorter and we can provide better documentation for the various parts; - configure the amount of memory for the guest in the file too; - document the fact that you might want/need to use '-serial stdio' and '-display vnc=3D...' in some situations; - fix the value of 'port' for one of the pcie-root-port devices; - fix some inaccurate comments. * Arguably the opposite: - remove the sample command line for running a live OS from the file header. I could be convinced to add it back as a (commented) section about it, if people think it's useful enough. Changes since [v3] * Address review comments: - place VGA at 00:01.0; - use pcie-root-port instead of ioh3420 in q35-virtio-*.cfg; - add a comment to let users know that PCI Express devices should not be placed on the legacy PCI bridge. Changes since [v2] * Address review comments: - use -nodefaults in q35-emulated.cfg too; - add explicit VGA and Ethernet. * Improvements: - use virtconsole and virtio-serial instead of isa-serial in q35-virtio-serial.cfg. * Possibily controversial: - get rid of q35-virtio-common.cfg and add the PCIe Root Ports back into q35-virtio-*.cfg: while this leads to having some duplicated content, I feel like the sample configurations are much more useful when they can stand entirely on their own, especially now that they start with a detailed hardware listing. * Cosmetic stuff: - hardware listing looks like the output of lspci; - section names match what's used in the hardware listing so it's faster to jump to the section; - PCI addresses also match the output of lspci; - PCI Express is used instead of PCIe. Changes since [v1] * Address review comments: - improve the existing configuration file instead of removing it; - split off the common part for VirtIO guests; - plug all ioh3420 devices in a single slot; - use slot 1c for ioh3420 devices; - remove useless USB keyboard. * Improve usage description: - make sure the OS disk actually uses the VirtIO SCSI controller, as intended, rather than the built-in SATA one; - provide a command line for running live CDs. * Document more devices: - the video card is added by default; - so is the Ethernet adapter, apparently. [v1] http://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg06342.html [v2] http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg00184.html [v3] http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg00461.html [v4] http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg00672.html docs/q35-chipset.cfg | 152 ------------------------ docs/q35-emulated.cfg | 265 ++++++++++++++++++++++++++++++++++++++= ++++ docs/q35-virtio-graphical.cfg | 229 ++++++++++++++++++++++++++++++++++++ docs/q35-virtio-serial.cfg | 201 ++++++++++++++++++++++++++++++++ 4 files changed, 695 insertions(+), 152 deletions(-) delete mode 100644 docs/q35-chipset.cfg create mode 100644 docs/q35-emulated.cfg create mode 100644 docs/q35-virtio-graphical.cfg create mode 100644 docs/q35-virtio-serial.cfg diff --git a/docs/q35-chipset.cfg b/docs/q35-chipset.cfg deleted file mode 100644 index e4ddb7d..0000000 --- a/docs/q35-chipset.cfg +++ /dev/null @@ -1,152 +0,0 @@ -################################################################ -# -# qemu -M q35 creates a bare machine with just the very essential -# chipset devices being present: -# -# 00.0 - Host bridge -# 1f.0 - ISA bridge / LPC -# 1f.2 - SATA (AHCI) controller -# 1f.3 - SMBus controller -# -# This config file documents the other devices and how they are -# created. You can simply use "-readconfig $thisfile" to create -# them all. Here is a overview: -# -# 19.0 - Ethernet controller (not created, our e1000 emulation -# doesn't emulate the ich9 device). -# 1a.* - USB Controller #2 (ehci + uhci companions) -# 1b.0 - HD Audio Controller -# 1c.* - PCI Express Ports -# 1d.* - USB Controller #1 (ehci + uhci companions, -# "qemu -M q35 -usb" creates these too) -# 1e.0 - PCI Bridge -# - -[device "ich9-ehci-2"] - driver =3D "ich9-usb-ehci2" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1a.7" - -[device "ich9-uhci-4"] - driver =3D "ich9-usb-uhci4" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1a.0" - masterbus =3D "ich9-ehci-2.0" - firstport =3D "0" - -[device "ich9-uhci-5"] - driver =3D "ich9-usb-uhci5" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1a.1" - masterbus =3D "ich9-ehci-2.0" - firstport =3D "2" - -[device "ich9-uhci-6"] - driver =3D "ich9-usb-uhci6" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1a.2" - masterbus =3D "ich9-ehci-2.0" - firstport =3D "4" - - -[device "ich9-hda-audio"] - driver =3D "ich9-intel-hda" - bus =3D "pcie.0" - addr =3D "1b.0" - - -[device "ich9-pcie-port-1"] - driver =3D "ioh3420" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1c.0" - port =3D "1" - chassis =3D "1" - -[device "ich9-pcie-port-2"] - driver =3D "ioh3420" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1c.1" - port =3D "2" - chassis =3D "2" - -[device "ich9-pcie-port-3"] - driver =3D "ioh3420" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1c.2" - port =3D "3" - chassis =3D "3" - -[device "ich9-pcie-port-4"] - driver =3D "ioh3420" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1c.3" - port =3D "4" - chassis =3D "4" - -## -# Example PCIe switch with two downstream ports -# -#[device "pcie-switch-upstream-port-1"] -# driver =3D "x3130-upstream" -# bus =3D "ich9-pcie-port-4" -# addr =3D "00.0" -# -#[device "pcie-switch-downstream-port-1-1"] -# driver =3D "xio3130-downstream" -# multifunction =3D "on" -# bus =3D "pcie-switch-upstream-port-1" -# addr =3D "00.0" -# port =3D "1" -# chassis =3D "5" -# -#[device "pcie-switch-downstream-port-1-2"] -# driver =3D "xio3130-downstream" -# multifunction =3D "on" -# bus =3D "pcie-switch-upstream-port-1" -# addr =3D "00.1" -# port =3D "1" -# chassis =3D "6" - -[device "ich9-ehci-1"] - driver =3D "ich9-usb-ehci1" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1d.7" - -[device "ich9-uhci-1"] - driver =3D "ich9-usb-uhci1" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1d.0" - masterbus =3D "ich9-ehci-1.0" - firstport =3D "0" - -[device "ich9-uhci-2"] - driver =3D "ich9-usb-uhci2" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1d.1" - masterbus =3D "ich9-ehci-1.0" - firstport =3D "2" - -[device "ich9-uhci-3"] - driver =3D "ich9-usb-uhci3" - multifunction =3D "on" - bus =3D "pcie.0" - addr =3D "1d.2" - masterbus =3D "ich9-ehci-1.0" - firstport =3D "4" - - -[device "ich9-pci-bridge"] - driver =3D "i82801b11-bridge" - bus =3D "pcie.0" - addr =3D "1e.0" diff --git a/docs/q35-emulated.cfg b/docs/q35-emulated.cfg new file mode 100644 index 0000000..7f8e68b --- /dev/null +++ b/docs/q35-emulated.cfg @@ -0,0 +1,265 @@ +# q35 - Emulated 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 +# +# You will probably need to tweak the lines marked as +# CHANGE ME before being able to use this configuration! +# +# Usage: +# +# $ qemu-system-x86_64 \ +# -nodefaults \ +# -readconfig q35-emulated.cfg +# +# The guest will have a selection of emulated devices that +# closely resembles that of a physical machine, 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 +# create a bare machine with just the very essential +# chipset devices being present: +# +# 00:00.0 Host bridge +# 00:1f.0 ISA bridge / LPC +# 00:1f.2 SATA (AHCI) controller +# 00:1f.3 SMBus controller +# +# This configuration file adds a number of devices that +# are pretty much guaranteed to be present in every single +# physical machine based on q35, more specifically: +# +# 00:01.0 VGA compatible controller +# 00:19.0 Ethernet controller +# 00:1a.* USB controller (#2) +# 00:1b.0 Audio device +# 00:1c.* PCI bridge (PCI Express Root Ports) +# 00:1d.* USB Controller (#1) +# 00:1e.0 PCI bridge (legacy PCI bridge) +# +# 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 q35 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. + +[machine] + type =3D "q35" + accel =3D "kvm" + +[memory] + size =3D "1024" + + +# 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 add four PCI Express Root Ports, all sharing the same +# slot on the PCI Express Root Bus. These ports support +# hotplug. + +[device "ich9-pcie-port-1"] + driver =3D "ioh3420" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1c.0" + port =3D "1" + chassis =3D "1" + +[device "ich9-pcie-port-2"] + driver =3D "ioh3420" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1c.1" + port =3D "2" + chassis =3D "2" + +[device "ich9-pcie-port-3"] + driver =3D "ioh3420" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1c.2" + port =3D "3" + chassis =3D "3" + +[device "ich9-pcie-port-4"] + driver =3D "ioh3420" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1c.3" + port =3D "4" + chassis =3D "4" + + +# PCI bridge (legacy PCI bridge) +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# This bridge can be used to build an independent topology +# for legacy PCI devices. PCI Express devices should be +# plugged into PCI Express slots instead, so ideally there +# will be no devices connected to this bridge. + +[device "ich9-pci-bridge"] + driver =3D "i82801b11-bridge" + bus =3D "pcie.0" + addr =3D "1e.0" + + +# SATA 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 +# +# An implicit SATA controller is created automatically for +# every single q35 guest; here we create a disk, backed by +# a qcow2 disk image on the host's filesystem, and attach +# it to that controller so that the guest can use it. + +[device "sata-disk"] + driver =3D "ide-hd" + bus =3D "ide.0" + drive =3D "disk" + +[drive "disk"] + file =3D "guest.qcow2" # CHANGE ME + format =3D "qcow2" + if =3D "none" + + +# USB controller (#1) +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# EHCI controller + UHCI companion controllers. + +[device "ich9-ehci-1"] + driver =3D "ich9-usb-ehci1" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1d.7" + +[device "ich9-uhci-1"] + driver =3D "ich9-usb-uhci1" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1d.0" + masterbus =3D "ich9-ehci-1.0" + firstport =3D "0" + +[device "ich9-uhci-2"] + driver =3D "ich9-usb-uhci2" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1d.1" + masterbus =3D "ich9-ehci-1.0" + firstport =3D "2" + +[device "ich9-uhci-3"] + driver =3D "ich9-usb-uhci3" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1d.2" + masterbus =3D "ich9-ehci-1.0" + firstport =3D "4" + + +# USB controller (#2) +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# EHCI controller + UHCI companion controllers. + +[device "ich9-ehci-2"] + driver =3D "ich9-usb-ehci2" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1a.7" + +[device "ich9-uhci-4"] + driver =3D "ich9-usb-uhci4" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1a.0" + masterbus =3D "ich9-ehci-2.0" + firstport =3D "0" + +[device "ich9-uhci-5"] + driver =3D "ich9-usb-uhci5" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1a.1" + masterbus =3D "ich9-ehci-2.0" + firstport =3D "2" + +[device "ich9-uhci-6"] + driver =3D "ich9-usb-uhci6" + multifunction =3D "on" + bus =3D "pcie.0" + addr =3D "1a.2" + masterbus =3D "ich9-ehci-2.0" + firstport =3D "4" + + +# 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 add a Gigabit Ethernet interface to the guest; 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 "e1000" + netdev =3D "hostnet" + bus =3D "pcie.0" + addr =3D "19.0" + + +# VGA compatible 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 stdvga instead of Cirrus as it supports more video +# modes and is closer to what actual hardware looks like. +# +# 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 trying +# to display a GTK+ window on the host and enable remote +# access instead. + +[device "video"] + driver =3D "VGA" + bus =3D "pcie.0" + addr =3D "01.0" + + +# Audio device +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# The sound card is a legacy PCI device that is plugged +# directly into the PCI Express Root Bus. + +[device "ich9-hda-audio"] + driver =3D "ich9-intel-hda" + bus =3D "pcie.0" + addr =3D "1b.0" + +[device "ich9-hda-duplex"] + driver =3D "hda-duplex" + bus =3D "ich9-hda-audio.0" + cad =3D "0" diff --git a/docs/q35-virtio-graphical.cfg b/docs/q35-virtio-graphical.cfg new file mode 100644 index 0000000..3904a1f --- /dev/null +++ b/docs/q35-virtio-graphical.cfg @@ -0,0 +1,229 @@ +# q35 - 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 +# +# You will probably need to tweak the lines marked as +# CHANGE ME before being able to use this configuration! +# +# Usage: +# +# $ qemu-system-x86_64 \ +# -nodefaults \ +# -readconfig q35-virtio-graphical.cfg +# +# 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 +# create a bare machine with just the very essential +# chipset devices being present: +# +# 00:00.0 Host bridge +# 00:1f.0 ISA bridge / LPC +# 00:1f.2 SATA (AHCI) controller +# 00:1f.3 SMBus controller +# +# This configuration file adds a number of other useful +# devices, more specifically: +# +# 00:01.0 VGA compatible controller +# 00:1b.0 Audio device +# 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 q35 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. + +[machine] + type =3D "q35" + accel =3D "kvm" + +[memory] + size =3D "1024" + + +# 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 "pci.1"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.0" + port =3D "1" + chassis =3D "1" + multifunction =3D "on" + +[device "pci.2"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.1" + port =3D "2" + chassis =3D "2" + +[device "pci.3"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.2" + port =3D "3" + chassis =3D "3" + +[device "pci.4"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.3" + port =3D "4" + chassis =3D "4" + +[device "pci.5"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.4" + port =3D "5" + chassis =3D "5" + +[device "pci.6"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.5" + port =3D "6" + chassis =3D "6" + +[device "pci.7"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.6" + port =3D "7" + chassis =3D "7" + +[device "pci.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. + +[device "scsi"] + driver =3D "virtio-scsi-pci" + bus =3D "pci.1" + addr =3D "00.0" + +[device "scsi-disk"] + driver =3D "scsi-hd" + bus =3D "scsi.0" + drive =3D "disk" + +[drive "disk"] + file =3D "guest.qcow2" # CHANGE ME + format =3D "qcow2" + 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 "pci.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 tablet so that graphical guests can be controlled +# appropriately. A USB keyboard is not needed, as q35 +# guests get a PS/2 one added automatically. + +[device "usb"] + driver =3D "nec-usb-xhci" + bus =3D "pci.3" + addr =3D "00.0" + +[device "tablet"] + driver =3D "usb-tablet" + bus =3D "usb.0" + + +# VGA compatible 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 plug the QXL video card directly into the PCI Express +# Root Bus as it is a legacy PCI device; this way, we can +# reduce the number of PCI Express controllers in the +# guest. +# +# 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 trying +# to display a GTK+ window on the host and enable remote +# access instead. + +[device "video"] + driver =3D "qxl-vga" + bus =3D "pcie.0" + addr =3D "01.0" + + +# Audio device +# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +# +# Like the video card, the sound card is a legacy PCI +# device and as such can be plugged directly into the PCI +# Express Root Bus. + +[device "sound"] + driver =3D "ich9-intel-hda" + bus =3D "pcie.0" + addr =3D "1b.0" + +[device "duplex"] + driver =3D "hda-duplex" + bus =3D "sound.0" + cad =3D "0" diff --git a/docs/q35-virtio-serial.cfg b/docs/q35-virtio-serial.cfg new file mode 100644 index 0000000..da16f89 --- /dev/null +++ b/docs/q35-virtio-serial.cfg @@ -0,0 +1,201 @@ +# q35 - 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 +# +# You will probably need to tweak the lines marked as +# CHANGE ME before being able to use this configuration! +# +# Usage: +# +# $ qemu-system-x86_64 \ +# -nographic -nodefaults \ +# -readconfig q35-virtio-serial.cfg +# +# The guest will have a selection of VirtIO devices +# tailored towards optimal performance with modern guests, +# and will be accessed through the serial console. +# +# --------------------------------------------------------- +# +# We need -nographic to prevent QEMU from creating an empty +# display window, which we're not interested in. +# +# Using -nodefaults is required to have full control over +# the virtual hardware: when it's specified, QEMU will +# create a bare machine with just the very essential +# chipset devices being present: +# +# 00:00.0 Host bridge +# 00:1f.0 ISA bridge / LPC +# 00:1f.2 SATA (AHCI) controller +# 00:1f.3 SMBus controller +# +# 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 +# 03:00.0 Communication controller (serial console) +# +# 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 q35 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. + +[machine] + type =3D "q35" + accel =3D "kvm" + +[memory] + size =3D "1024" + + +# 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 "pci.1"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.0" + port =3D "1" + chassis =3D "1" + multifunction =3D "on" + +[device "pci.2"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.1" + port =3D "2" + chassis =3D "2" + +[device "pci.3"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.2" + port =3D "3" + chassis =3D "3" + +[device "pci.4"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.3" + port =3D "4" + chassis =3D "4" + +[device "pci.5"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.4" + port =3D "5" + chassis =3D "5" + +[device "pci.6"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.5" + port =3D "6" + chassis =3D "6" + +[device "pci.7"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.6" + port =3D "7" + chassis =3D "7" + +[device "pci.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. + +[device "scsi"] + driver =3D "virtio-scsi-pci" + bus =3D "pci.1" + addr =3D "00.0" + +[device "scsi-disk"] + driver =3D "scsi-hd" + bus =3D "scsi.0" + drive =3D "disk" + +[drive "disk"] + file =3D "guest.qcow2" # CHANGE ME + format =3D "qcow2" + 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 "pci.2" + addr =3D "00.0" + + +# Communication controller (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 +# +# We use virtconsole along with virtio-serial, and connect +# it with the host's standard input / output channels. In +# this configuration, the guest will behave pretty much +# like any other Unix utility: that includes terminating +# as soon as Ctrl-C is pressed, so caution is advised. +# +# If you want to use the platform's native serial console +# instead, you should comment out this section and append +# +# -serial stdio +# +# to the QEMU command line. Doing so might be needed to be +# able to access the GRUB menu or see the output from the +# boot process. + +[chardev "hostconsole"] + backend =3D "stdio" + +[device "serial"] + driver =3D "virtio-serial-pci" + bus =3D "pci.3" + addr =3D "00.0" + +[device "console"] + driver =3D "virtconsole" + chardev =3D "hostconsole" --=20 2.7.4 From nobody Thu May 2 01:23:46 2024 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 1486575448857475.10749176959655; Wed, 8 Feb 2017 09:37:28 -0800 (PST) Received: from localhost ([::1]:60703 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbWBJ-0002i9-S2 for importer@patchew.org; Wed, 08 Feb 2017 12:37:25 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbW9v-00028T-Ty for qemu-devel@nongnu.org; Wed, 08 Feb 2017 12:36:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbW9u-0005lC-2O for qemu-devel@nongnu.org; Wed, 08 Feb 2017 12:35:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41390) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cbW9t-0005kn-R9 for qemu-devel@nongnu.org; Wed, 08 Feb 2017 12:35:58 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 06DEF804EF for ; Wed, 8 Feb 2017 17:35:58 +0000 (UTC) Received: from inaba.usersys.redhat.com ([10.34.129.229]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v18HZqWY014352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Feb 2017 12:35:56 -0500 From: Andrea Bolognani To: qemu-devel@nongnu.org Date: Wed, 8 Feb 2017 18:35:31 +0100 Message-Id: <1486575331-14455-3-git-send-email-abologna@redhat.com> In-Reply-To: <1486575331-14455-1-git-send-email-abologna@redhat.com> References: <1486575331-14455-1-git-send-email-abologna@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 08 Feb 2017 17:35:58 +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] [PATCH v5 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: marcel@redhat.com, drjones@redhat.com, lersek@redhat.com, kraxel@redhat.com 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" 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. --- docs/mach-virt-graphical.cfg | 245 +++++++++++++++++++++++++++++++++++++++= ++++ docs/mach-virt-serial.cfg | 234 +++++++++++++++++++++++++++++++++++++++= ++ 2 files changed, 479 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..d942394 --- /dev/null +++ b/docs/mach-virt-graphical.cfg @@ -0,0 +1,245 @@ +# 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 +# +# You will probably need to tweak the lines marked as +# CHANGE ME before being able to use this configuration! +# +# Usage: +# +# $ qemu-system-aarch64 \ +# -nodefaults \ +# -readconfig mach-virt-graphical.cfg \ +# -cpu host +# +# 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 +# create a bare machine with just the very essential +# chipset devices being present: +# +# 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. + +[machine] + type =3D "virt" + accel =3D "kvm" + +[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 used by +# to record information such as the boot device. An empty +# variable store can be created by simply copying a +# template provided as part of AAVMF. +# +# Depending on the distribution you're using on the host, +# paths to the firmware itself and variable store template +# will be different. Some examples: +# +# Fedora: +# /usr/share/edk2/aarch64/QEMU_EFI.fd +# /usr/share/edk2/aarch64/QEMU_VARS.fd +# RHEL: +# /usr/share/AAVMF/AAVMF_CODE.fd +# /usr/share/AAVMF/AAVMF_VARS.fd + +[drive "aavmf-code"] + file =3D "/usr/share/edk2/aarch64/QEMU_EFI.fd" # CHANGE ME + format =3D "raw" + if =3D "pflash" + unit =3D "0" + readonly =3D "on" + +[drive "aavmf-vars"] + 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 "pci.1"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.0" + port =3D "1" + chassis =3D "1" + multifunction =3D "on" + +[device "pci.2"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.1" + port =3D "2" + chassis =3D "2" + +[device "pci.3"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.2" + port =3D "3" + chassis =3D "3" + +[device "pci.4"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.3" + port =3D "4" + chassis =3D "4" + +[device "pci.5"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.4" + port =3D "5" + chassis =3D "5" + +[device "pci.6"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.5" + port =3D "6" + chassis =3D "6" + +[device "pci.7"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.6" + port =3D "7" + chassis =3D "7" + +[device "pci.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. + +[device "scsi"] + driver =3D "virtio-scsi-pci" + bus =3D "pci.1" + addr =3D "00.0" + +[device "scsi-disk"] + driver =3D "scsi-hd" + bus =3D "scsi.0" + drive =3D "disk" + +[drive "disk"] + file =3D "guest.qcow2" # CHANGE ME + format =3D "qcow2" + 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 "pci.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 "pci.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 trying +# to display a GTK+ 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..6bf8cb2 --- /dev/null +++ b/docs/mach-virt-serial.cfg @@ -0,0 +1,234 @@ +# 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 +# +# You will probably need to tweak the lines marked as +# CHANGE ME before being able to use this configuration! +# +# Usage: +# +# $ qemu-system-aarch64 \ +# -nographic -nodefaults \ +# -readconfig mach-virt-serial.cfg \ +# -cpu host +# +# The guest will have a selection of VirtIO devices +# tailored towards optimal performance with modern guests, +# and will be accessed through the serial console. +# +# --------------------------------------------------------- +# +# We need -nographic to prevent QEMU from creating an empty +# display window, which we're not interested in. +# +# Using -nodefaults is required to have full control over +# the virtual hardware: when it's specified, QEMU will +# create a bare machine with just the very essential +# chipset devices being present: +# +# 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 +# 03:00.0 Communication controller (serial console) +# +# 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. + +[machine] + type =3D "virt" + accel =3D "kvm" + +[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 used by +# to record information such as the boot device. An empty +# variable store can be created by simply copying a +# template provided as part of AAVMF. +# +# Depending on the distribution you're using on the host, +# paths to the firmware itself and variable store template +# will be different. Some examples: +# +# Fedora: +# /usr/share/edk2/aarch64/QEMU_EFI.fd +# /usr/share/edk2/aarch64/QEMU_VARS.fd +# RHEL: +# /usr/share/AAVMF/AAVMF_CODE.fd +# /usr/share/AAVMF/AAVMF_VARS.fd + +[drive "aavmf-code"] + file =3D "/usr/share/edk2/aarch64/QEMU_EFI.fd" # CHANGE ME + format =3D "raw" + if =3D "pflash" + unit =3D "0" + readonly =3D "on" + +[drive "aavmf-vars"] + 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 "pci.1"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.0" + port =3D "1" + chassis =3D "1" + multifunction =3D "on" + +[device "pci.2"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.1" + port =3D "2" + chassis =3D "2" + +[device "pci.3"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.2" + port =3D "3" + chassis =3D "3" + +[device "pci.4"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.3" + port =3D "4" + chassis =3D "4" + +[device "pci.5"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.4" + port =3D "5" + chassis =3D "5" + +[device "pci.6"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.5" + port =3D "6" + chassis =3D "6" + +[device "pci.7"] + driver =3D "pcie-root-port" + bus =3D "pcie.0" + addr =3D "1c.6" + port =3D "7" + chassis =3D "7" + +[device "pci.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. + +[device "scsi"] + driver =3D "virtio-scsi-pci" + bus =3D "pci.1" + addr =3D "00.0" + +[device "scsi-disk"] + driver =3D "scsi-hd" + bus =3D "scsi.0" + drive =3D "disk" + +[drive "disk"] + file =3D "guest.qcow2" # CHANGE ME + format =3D "qcow2" + 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 "pci.2" + addr =3D "00.0" + + +# Communication controller (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 +# +# We use virtconsole along with virtio-serial, and connect +# it with the host's standard input / output channels. In +# this configuration, the guest will behave pretty much +# like any other Unix utility: that includes terminating +# as soon as Ctrl-C is pressed, so caution is advised. +# +# If you want to use the platform's native serial console +# instead, you should comment out this section and append +# +# -serial stdio +# +# to the QEMU command line. Doing so might be needed to be +# able to access the GRUB menu or see the output from the +# boot process. + +[chardev "hostconsole"] + backend =3D "stdio" + +[device "serial"] + driver =3D "virtio-serial-pci" + bus =3D "pci.3" + addr =3D "00.0" + +[device "console"] + driver =3D "virtconsole" + chardev =3D "hostconsole" --=20 2.7.4