Re: [Qemu-devel] [PATCH v7 2/2] mach-virt: Provide sample configuration files

[Andrew Jones <drjones@redhat.com>]

On Fri, Feb 10, 2017 at 06:25:06PM +0100, Andrea Bolognani wrote:
> 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 | 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

Reviewed-by: Andrew Jones <drjones@redhat.com>

Thanks Andrea!

> 
> 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)
> +# =========================================================
> +#
> +# 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
> +# =========================================================
> +#
> +# 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 = "virt"
> +  accel = "kvm"
> +  gic-version = "host"
> +
> +[memory]
> +  size = "1024"
> +
> +
> +# Firmware configuration
> +# =========================================================
> +#
> +# 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 = "/usr/share/AAVMF/AAVMF_CODE.fd"       # CHANGE ME
> +  format = "raw"
> +  if = "pflash"
> +  unit = "0"
> +  readonly = "on"
> +
> +[drive "uefi-varstore"]
> +  file = "guest_VARS.fd"                        # CHANGE ME
> +  format = "raw"
> +  if = "pflash"
> +  unit = "1"
> +
> +
> +# PCI bridge (PCI Express Root Ports)
> +# =========================================================
> +#
> +# 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 = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.0"
> +  port = "1"
> +  chassis = "1"
> +  multifunction = "on"
> +
> +[device "pcie.2"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.1"
> +  port = "2"
> +  chassis = "2"
> +
> +[device "pcie.3"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.2"
> +  port = "3"
> +  chassis = "3"
> +
> +[device "pcie.4"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.3"
> +  port = "4"
> +  chassis = "4"
> +
> +[device "pcie.5"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.4"
> +  port = "5"
> +  chassis = "5"
> +
> +[device "pcie.6"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.5"
> +  port = "6"
> +  chassis = "6"
> +
> +[device "pcie.7"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.6"
> +  port = "7"
> +  chassis = "7"
> +
> +[device "pcie.8"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.7"
> +  port = "8"
> +  chassis = "8"
> +
> +
> +# SCSI storage controller (and storage)
> +# =========================================================
> +#
> +# 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 = "virtio-scsi-pci"
> +  bus = "pcie.1"
> +  addr = "00.0"
> +
> +[device "scsi-disk"]
> +  driver = "scsi-hd"
> +  bus = "scsi.0"
> +  drive = "disk"
> +  bootindex = "1"
> +
> +[drive "disk"]
> +  file = "guest.qcow2"                          # CHANGE ME
> +  format = "qcow2"
> +  if = "none"
> +
> +[device "scsi-optical-disk"]
> +  driver = "scsi-cd"
> +  bus = "scsi.0"
> +  drive = "optical-disk"
> +  bootindex = "2"
> +
> +[drive "optical-disk"]
> +  file = "install.iso"                          # CHANGE ME
> +  format = "raw"
> +  if = "none"
> +
> +
> +# Ethernet controller
> +# =========================================================
> +#
> +# 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 = "user"
> +
> +[device "net"]
> +  driver = "virtio-net-pci"
> +  netdev = "hostnet"
> +  bus = "pcie.2"
> +  addr = "00.0"
> +
> +
> +# USB controller (and input devices)
> +# =========================================================
> +#
> +# 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 = "nec-usb-xhci"
> +  bus = "pcie.3"
> +  addr = "00.0"
> +
> +[device "keyboard"]
> +  driver = "usb-kbd"
> +  bus = "usb.0"
> +
> +[device "tablet"]
> +  driver = "usb-tablet"
> +  bus = "usb.0"
> +
> +
> +# Display controller
> +# =========================================================
> +#
> +# 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=127.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 = "virtio-gpu"
> +  bus = "pcie.0"
> +  addr = "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)
> +# =========================================================
> +#
> +# 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
> +# =========================================================
> +#
> +# 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 = "virt"
> +  accel = "kvm"
> +  gic-version = "host"
> +
> +[memory]
> +  size = "1024"
> +
> +
> +# Firmware configuration
> +# =========================================================
> +#
> +# 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 = "/usr/share/AAVMF/AAVMF_CODE.fd"       # CHANGE ME
> +  format = "raw"
> +  if = "pflash"
> +  unit = "0"
> +  readonly = "on"
> +
> +[drive "uefi-varstore"]
> +  file = "guest_VARS.fd"                        # CHANGE ME
> +  format = "raw"
> +  if = "pflash"
> +  unit = "1"
> +
> +
> +# PCI bridge (PCI Express Root Ports)
> +# =========================================================
> +#
> +# 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 = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.0"
> +  port = "1"
> +  chassis = "1"
> +  multifunction = "on"
> +
> +[device "pcie.2"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.1"
> +  port = "2"
> +  chassis = "2"
> +
> +[device "pcie.3"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.2"
> +  port = "3"
> +  chassis = "3"
> +
> +[device "pcie.4"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.3"
> +  port = "4"
> +  chassis = "4"
> +
> +[device "pcie.5"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.4"
> +  port = "5"
> +  chassis = "5"
> +
> +[device "pcie.6"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.5"
> +  port = "6"
> +  chassis = "6"
> +
> +[device "pcie.7"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.6"
> +  port = "7"
> +  chassis = "7"
> +
> +[device "pcie.8"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.7"
> +  port = "8"
> +  chassis = "8"
> +
> +
> +# SCSI storage controller (and storage)
> +# =========================================================
> +#
> +# 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 = "virtio-scsi-pci"
> +  bus = "pcie.1"
> +  addr = "00.0"
> +
> +[device "scsi-disk"]
> +  driver = "scsi-hd"
> +  bus = "scsi.0"
> +  drive = "disk"
> +  bootindex = "1"
> +
> +[drive "disk"]
> +  file = "guest.qcow2"                          # CHANGE ME
> +  format = "qcow2"
> +  if = "none"
> +
> +[device "scsi-optical-disk"]
> +  driver = "scsi-cd"
> +  bus = "scsi.0"
> +  drive = "optical-disk"
> +  bootindex = "2"
> +
> +[drive "optical-disk"]
> +  file = "install.iso"                          # CHANGE ME
> +  format = "raw"
> +  if = "none"
> +
> +
> +# Ethernet controller
> +# =========================================================
> +#
> +# 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 = "user"
> +
> +[device "net"]
> +  driver = "virtio-net-pci"
> +  netdev = "hostnet"
> +  bus = "pcie.2"
> +  addr = "00.0"
> -- 
> 2.7.4
> 
>