[Qemu-devel] [PATCH v5 0/2] docs: Improve sample configuration files

[Qemu-devel] [PATCH v5 0/2] docs: Improve sample configuration files

[Andrea Bolognani]

The previous version of this series, that only included
the first of the two patches, has already been reviewed
by Gerd, but since it's not been pushed yet I figured I
would post this as a full new series instead of an
incremental improvement over the previous one.

The big difference compared to the previous version is
that sample configuration files are now provided for the
mach-virt machine type.

There are some small improvements to the q35 sample
configuration files as well, which are documented fully
in the relevant patch.

I'm adding Laszlo to CC:, so he can point out any
inaccurate statement I might have made about AAVMF.

Andrea Bolognani (2):
  q35: Improve sample configuration files
  mach-virt: Provide sample configuration files

 docs/mach-virt-graphical.cfg  | 245 ++++++++++++++++++++++++++++++++++++++
 docs/mach-virt-serial.cfg     | 234 +++++++++++++++++++++++++++++++++++++
 docs/q35-chipset.cfg          | 152 ------------------------
 docs/q35-emulated.cfg         | 265 ++++++++++++++++++++++++++++++++++++++++++
 docs/q35-virtio-graphical.cfg | 229 ++++++++++++++++++++++++++++++++++++
 docs/q35-virtio-serial.cfg    | 201 ++++++++++++++++++++++++++++++++
 6 files changed, 1174 insertions(+), 152 deletions(-)
 create mode 100644 docs/mach-virt-graphical.cfg
 create mode 100644 docs/mach-virt-serial.cfg
 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

-- 
2.7.4

[Qemu-devel] [PATCH v5 1/2] q35: Improve sample configuration files

[Andrea Bolognani]

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=...' 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 = "ich9-usb-ehci2"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1a.7"
-
-[device "ich9-uhci-4"]
-  driver = "ich9-usb-uhci4"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1a.0"
-  masterbus = "ich9-ehci-2.0"
-  firstport = "0"
-
-[device "ich9-uhci-5"]
-  driver = "ich9-usb-uhci5"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1a.1"
-  masterbus = "ich9-ehci-2.0"
-  firstport = "2"
-
-[device "ich9-uhci-6"]
-  driver = "ich9-usb-uhci6"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1a.2"
-  masterbus = "ich9-ehci-2.0"
-  firstport = "4"
-
-
-[device "ich9-hda-audio"]
-  driver = "ich9-intel-hda"
-  bus = "pcie.0"
-  addr = "1b.0"
-
-
-[device "ich9-pcie-port-1"]
-  driver = "ioh3420"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1c.0"
-  port = "1"
-  chassis = "1"
-
-[device "ich9-pcie-port-2"]
-  driver = "ioh3420"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1c.1"
-  port = "2"
-  chassis = "2"
-
-[device "ich9-pcie-port-3"]
-  driver = "ioh3420"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1c.2"
-  port = "3"
-  chassis = "3"
-
-[device "ich9-pcie-port-4"]
-  driver = "ioh3420"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1c.3"
-  port = "4"
-  chassis = "4"
-
-##
-# Example PCIe switch with two downstream ports
-#
-#[device "pcie-switch-upstream-port-1"]
-#  driver = "x3130-upstream"
-#  bus = "ich9-pcie-port-4"
-#  addr = "00.0"
-#
-#[device "pcie-switch-downstream-port-1-1"]
-#  driver = "xio3130-downstream"
-#  multifunction = "on"
-#  bus = "pcie-switch-upstream-port-1"
-#  addr = "00.0"
-#  port = "1"
-#  chassis = "5"
-#
-#[device "pcie-switch-downstream-port-1-2"]
-#  driver = "xio3130-downstream"
-#  multifunction = "on"
-#  bus = "pcie-switch-upstream-port-1"
-#  addr = "00.1"
-#  port = "1"
-#  chassis = "6"
-
-[device "ich9-ehci-1"]
-  driver = "ich9-usb-ehci1"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1d.7"
-
-[device "ich9-uhci-1"]
-  driver = "ich9-usb-uhci1"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1d.0"
-  masterbus = "ich9-ehci-1.0"
-  firstport = "0"
-
-[device "ich9-uhci-2"]
-  driver = "ich9-usb-uhci2"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1d.1"
-  masterbus = "ich9-ehci-1.0"
-  firstport = "2"
-
-[device "ich9-uhci-3"]
-  driver = "ich9-usb-uhci3"
-  multifunction = "on"
-  bus = "pcie.0"
-  addr = "1d.2"
-  masterbus = "ich9-ehci-1.0"
-  firstport = "4"
-
-
-[device "ich9-pci-bridge"]
-  driver = "i82801b11-bridge"
-  bus = "pcie.0"
-  addr = "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)
+# =========================================================
+#
+# 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
+# =========================================================
+#
+# 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 = "q35"
+  accel = "kvm"
+
+[memory]
+  size = "1024"
+
+
+# PCI bridge (PCI Express Root Ports)
+# =========================================================
+#
+# 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 = "ioh3420"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1c.0"
+  port = "1"
+  chassis = "1"
+
+[device "ich9-pcie-port-2"]
+  driver = "ioh3420"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1c.1"
+  port = "2"
+  chassis = "2"
+
+[device "ich9-pcie-port-3"]
+  driver = "ioh3420"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1c.2"
+  port = "3"
+  chassis = "3"
+
+[device "ich9-pcie-port-4"]
+  driver = "ioh3420"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1c.3"
+  port = "4"
+  chassis = "4"
+
+
+# PCI bridge (legacy PCI bridge)
+# =========================================================
+#
+# 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 = "i82801b11-bridge"
+  bus = "pcie.0"
+  addr = "1e.0"
+
+
+# SATA storage
+# =========================================================
+#
+# 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 = "ide-hd"
+  bus = "ide.0"
+  drive = "disk"
+
+[drive "disk"]
+  file = "guest.qcow2"                          # CHANGE ME
+  format = "qcow2"
+  if = "none"
+
+
+# USB controller (#1)
+# =========================================================
+#
+# EHCI controller + UHCI companion controllers.
+
+[device "ich9-ehci-1"]
+  driver = "ich9-usb-ehci1"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1d.7"
+
+[device "ich9-uhci-1"]
+  driver = "ich9-usb-uhci1"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1d.0"
+  masterbus = "ich9-ehci-1.0"
+  firstport = "0"
+
+[device "ich9-uhci-2"]
+  driver = "ich9-usb-uhci2"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1d.1"
+  masterbus = "ich9-ehci-1.0"
+  firstport = "2"
+
+[device "ich9-uhci-3"]
+  driver = "ich9-usb-uhci3"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1d.2"
+  masterbus = "ich9-ehci-1.0"
+  firstport = "4"
+
+
+# USB controller (#2)
+# =========================================================
+#
+# EHCI controller + UHCI companion controllers.
+
+[device "ich9-ehci-2"]
+  driver = "ich9-usb-ehci2"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1a.7"
+
+[device "ich9-uhci-4"]
+  driver = "ich9-usb-uhci4"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1a.0"
+  masterbus = "ich9-ehci-2.0"
+  firstport = "0"
+
+[device "ich9-uhci-5"]
+  driver = "ich9-usb-uhci5"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1a.1"
+  masterbus = "ich9-ehci-2.0"
+  firstport = "2"
+
+[device "ich9-uhci-6"]
+  driver = "ich9-usb-uhci6"
+  multifunction = "on"
+  bus = "pcie.0"
+  addr = "1a.2"
+  masterbus = "ich9-ehci-2.0"
+  firstport = "4"
+
+
+# Ethernet controller
+# =========================================================
+#
+# 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 = "user"
+
+[device "net"]
+  driver = "e1000"
+  netdev = "hostnet"
+  bus = "pcie.0"
+  addr = "19.0"
+
+
+# VGA compatible controller
+# =========================================================
+#
+# 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=127.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 = "VGA"
+  bus = "pcie.0"
+  addr = "01.0"
+
+
+# Audio device
+# =========================================================
+#
+# The sound card is a legacy PCI device that is plugged
+# directly into the PCI Express Root Bus.
+
+[device "ich9-hda-audio"]
+  driver = "ich9-intel-hda"
+  bus = "pcie.0"
+  addr = "1b.0"
+
+[device "ich9-hda-duplex"]
+  driver = "hda-duplex"
+  bus = "ich9-hda-audio.0"
+  cad = "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)
+# =========================================================
+#
+# 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
+# =========================================================
+#
+# 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 = "q35"
+  accel = "kvm"
+
+[memory]
+  size = "1024"
+
+
+# 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 "pci.1"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.0"
+  port = "1"
+  chassis = "1"
+  multifunction = "on"
+
+[device "pci.2"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.1"
+  port = "2"
+  chassis = "2"
+
+[device "pci.3"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.2"
+  port = "3"
+  chassis = "3"
+
+[device "pci.4"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.3"
+  port = "4"
+  chassis = "4"
+
+[device "pci.5"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.4"
+  port = "5"
+  chassis = "5"
+
+[device "pci.6"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.5"
+  port = "6"
+  chassis = "6"
+
+[device "pci.7"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.6"
+  port = "7"
+  chassis = "7"
+
+[device "pci.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.
+
+[device "scsi"]
+  driver = "virtio-scsi-pci"
+  bus = "pci.1"
+  addr = "00.0"
+
+[device "scsi-disk"]
+  driver = "scsi-hd"
+  bus = "scsi.0"
+  drive = "disk"
+
+[drive "disk"]
+  file = "guest.qcow2"                          # CHANGE ME
+  format = "qcow2"
+  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 = "pci.2"
+  addr = "00.0"
+
+
+# USB controller (and input devices)
+# =========================================================
+#
+# 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 = "nec-usb-xhci"
+  bus = "pci.3"
+  addr = "00.0"
+
+[device "tablet"]
+  driver = "usb-tablet"
+  bus = "usb.0"
+
+
+# VGA compatible controller
+# =========================================================
+#
+# 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=127.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 = "qxl-vga"
+  bus = "pcie.0"
+  addr = "01.0"
+
+
+# Audio device
+# =========================================================
+#
+# 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 = "ich9-intel-hda"
+  bus = "pcie.0"
+  addr = "1b.0"
+
+[device "duplex"]
+  driver = "hda-duplex"
+  bus = "sound.0"
+  cad = "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)
+# =========================================================
+#
+# 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
+# =========================================================
+#
+# 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 = "q35"
+  accel = "kvm"
+
+[memory]
+  size = "1024"
+
+
+# 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 "pci.1"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.0"
+  port = "1"
+  chassis = "1"
+  multifunction = "on"
+
+[device "pci.2"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.1"
+  port = "2"
+  chassis = "2"
+
+[device "pci.3"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.2"
+  port = "3"
+  chassis = "3"
+
+[device "pci.4"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.3"
+  port = "4"
+  chassis = "4"
+
+[device "pci.5"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.4"
+  port = "5"
+  chassis = "5"
+
+[device "pci.6"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.5"
+  port = "6"
+  chassis = "6"
+
+[device "pci.7"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.6"
+  port = "7"
+  chassis = "7"
+
+[device "pci.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.
+
+[device "scsi"]
+  driver = "virtio-scsi-pci"
+  bus = "pci.1"
+  addr = "00.0"
+
+[device "scsi-disk"]
+  driver = "scsi-hd"
+  bus = "scsi.0"
+  drive = "disk"
+
+[drive "disk"]
+  file = "guest.qcow2"                          # CHANGE ME
+  format = "qcow2"
+  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 = "pci.2"
+  addr = "00.0"
+
+
+# Communication controller (serial console)
+# =========================================================
+#
+# 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 = "stdio"
+
+[device "serial"]
+  driver = "virtio-serial-pci"
+  bus = "pci.3"
+  addr = "00.0"
+
+[device "console"]
+  driver = "virtconsole"
+  chardev = "hostconsole"
-- 
2.7.4

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

[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.
---
 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)
+# =========================================================
+#
+# 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
+# =========================================================
+#
+# 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 = "virt"
+  accel = "kvm"
+
+[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 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 = "/usr/share/edk2/aarch64/QEMU_EFI.fd"  # CHANGE ME
+  format = "raw"
+  if = "pflash"
+  unit = "0"
+  readonly = "on"
+
+[drive "aavmf-vars"]
+  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 "pci.1"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.0"
+  port = "1"
+  chassis = "1"
+  multifunction = "on"
+
+[device "pci.2"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.1"
+  port = "2"
+  chassis = "2"
+
+[device "pci.3"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.2"
+  port = "3"
+  chassis = "3"
+
+[device "pci.4"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.3"
+  port = "4"
+  chassis = "4"
+
+[device "pci.5"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.4"
+  port = "5"
+  chassis = "5"
+
+[device "pci.6"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.5"
+  port = "6"
+  chassis = "6"
+
+[device "pci.7"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.6"
+  port = "7"
+  chassis = "7"
+
+[device "pci.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.
+
+[device "scsi"]
+  driver = "virtio-scsi-pci"
+  bus = "pci.1"
+  addr = "00.0"
+
+[device "scsi-disk"]
+  driver = "scsi-hd"
+  bus = "scsi.0"
+  drive = "disk"
+
+[drive "disk"]
+  file = "guest.qcow2"                          # CHANGE ME
+  format = "qcow2"
+  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 = "pci.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 = "pci.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 trying
+# to display a GTK+ 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..6bf8cb2
--- /dev/null
+++ b/docs/mach-virt-serial.cfg
@@ -0,0 +1,234 @@
+# mach-virt - VirtIO guest (serial console)
+# =========================================================
+#
+# 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
+# =========================================================
+#
+# 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 = "virt"
+  accel = "kvm"
+
+[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 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 = "/usr/share/edk2/aarch64/QEMU_EFI.fd"  # CHANGE ME
+  format = "raw"
+  if = "pflash"
+  unit = "0"
+  readonly = "on"
+
+[drive "aavmf-vars"]
+  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 "pci.1"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.0"
+  port = "1"
+  chassis = "1"
+  multifunction = "on"
+
+[device "pci.2"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.1"
+  port = "2"
+  chassis = "2"
+
+[device "pci.3"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.2"
+  port = "3"
+  chassis = "3"
+
+[device "pci.4"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.3"
+  port = "4"
+  chassis = "4"
+
+[device "pci.5"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.4"
+  port = "5"
+  chassis = "5"
+
+[device "pci.6"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.5"
+  port = "6"
+  chassis = "6"
+
+[device "pci.7"]
+  driver = "pcie-root-port"
+  bus = "pcie.0"
+  addr = "1c.6"
+  port = "7"
+  chassis = "7"
+
+[device "pci.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.
+
+[device "scsi"]
+  driver = "virtio-scsi-pci"
+  bus = "pci.1"
+  addr = "00.0"
+
+[device "scsi-disk"]
+  driver = "scsi-hd"
+  bus = "scsi.0"
+  drive = "disk"
+
+[drive "disk"]
+  file = "guest.qcow2"                          # CHANGE ME
+  format = "qcow2"
+  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 = "pci.2"
+  addr = "00.0"
+
+
+# Communication controller (serial console)
+# =========================================================
+#
+# 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 = "stdio"
+
+[device "serial"]
+  driver = "virtio-serial-pci"
+  bus = "pci.3"
+  addr = "00.0"
+
+[device "console"]
+  driver = "virtconsole"
+  chardev = "hostconsole"
-- 
2.7.4

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

[Laszlo Ersek]

Thanks for the CC!

On 02/08/17 18:35, Andrea Bolognani wrote:

> +# 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 used by

Apparently omitted:

  one specific virtual machine, exclusively,

Also, I would recommend replacing "used" with "owned".

> +# to record information such as the boot device. An empty

s/boot device/UEFI boot order/

> +# variable store can be created by simply copying a
> +# template provided as part of AAVMF.

How about:

  For any new guest, its permanent, private variable store should
  initially be copied from the template file provided as part of the
  ArmVirtQemu firmware platform (which is occasionally distributed
  under the AAVMF package).

> +#
> +# Depending on the distribution you're using on the host,

I recommend "OS distribution", "Linux distribution", or "GNU/Linux
distribution", as you prefer.

> +# paths to the firmware itself and variable store template

s/firmware/firmware binary/

> +# will be different. Some examples:
> +#
> +# Fedora:
> +#   /usr/share/edk2/aarch64/QEMU_EFI.fd
> +#   /usr/share/edk2/aarch64/QEMU_VARS.fd

Please annotate each as firmware binary & variable store template.

Also, I can't verify the exact pathnames for Fedora.

> +# RHEL:
> +#   /usr/share/AAVMF/AAVMF_CODE.fd
> +#   /usr/share/AAVMF/AAVMF_VARS.fd

Looks legit. (Might want to call "RHEL" "RHELSA" though, in this context
-- no clue. Ask Drew :))

> +
> +[drive "aavmf-code"]

Heh, I never specify "id" for these "-drive"s, but I definitely
appreciate the attention to detail. Let's call it "uefi-binary" though.

> +  file = "/usr/share/edk2/aarch64/QEMU_EFI.fd"  # CHANGE ME

Please replace the comment with

  CHANGE ME ACCORDING TO HOST LINUX DISTRO

or some such

> +  format = "raw"
> +  if = "pflash"
> +  unit = "0"
> +  readonly = "on"
> +
> +[drive "aavmf-vars"]

Let's call this "uefi-varstore".

> +  file = "guest_VARS.fd"                        # CHANGE ME

Many bonus points for providing a file name example that is *different*
from (QEMU|AAVMF)_VARS.fd. It should (and thankfully, does) reflect that
it's already a copy.

Please expand the comment:

  CHANGE ME TO THE NAME OF THE FILE THAT YOU CREATED AS A COPY of THE
  VARSTORE TEMPLATE

> +  format = "raw"
> +  if = "pflash"
> +  unit = "1"

Yes!

I apologize for being too detailed / pedantic about this.

Thanks!
Laszlo

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

[Peter Maydell]

On 8 February 2017 at 17:35, Andrea Bolognani <abologna@redhat.com> 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.

> --- /dev/null
> +++ b/docs/mach-virt-graphical.cfg
> @@ -0,0 +1,245 @@
> +# mach-virt - VirtIO guest (graphical console)
> +# =========================================================
> +#
> +# 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

What does nodefaults disable on the virt board?
(I've never looked into exactly what nodefaults does...)

There doesn't seem to be any specification of the GIC
version (unless I missed it in the config file); you
probably want -machine gic-version=host if you're using
-cpu host.

> +# 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:

The theory of 'virt' is it only has the essential
devices anyway.

> +#   00:00.0 Host bridge

I'm pretty sure -nodefaults isn't going to disable
the GIC, the UART, the flash devices, etc etc that
the virt board has. Not everything in the world is
a PCI device :-)

> +#
> +# 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.
> +

> +# 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 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

It's a shame that we've ended up with different
firmware names (even between RHEL and Fedora, without
getting to Debian or SUSE). Would making UEFI a
more "official" rom image in pc-bios/ help to
harmonise things, or just introduce yet another
possibility to the mix?

> +# Communication controller (serial console)
> +# =========================================================
> +#
> +# 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 = "stdio"
> +
> +[device "serial"]
> +  driver = "virtio-serial-pci"
> +  bus = "pci.3"
> +  addr = "00.0"
> +
> +[device "console"]
> +  driver = "virtconsole"
> +  chardev = "hostconsole"

Won't most guests expect serial to be the default
PL011 UART ?

thanks
-- PMM

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

[Andrea Bolognani]

On Wed, 2017-02-08 at 19:11 +0100, Laszlo Ersek wrote:
> How about:
> 
>   For any new guest, its permanent, private variable store should
>   initially be copied from the template file provided as part of the
>   ArmVirtQemu firmware platform (which is occasionally distributed
>   under the AAVMF package).

The naming is confusing enough as it is, no need to drag
ArmVirtQemu into this I think ;)

> > +# Fedora:
> > +#   /usr/share/edk2/aarch64/QEMU_EFI.fd
> > +#   /usr/share/edk2/aarch64/QEMU_VARS.fd
> 
> Please annotate each as firmware binary & variable store template.

I had such annotations at some points, I got rid of them
because they seemed a bit redundant. Added them back in.

> Also, I can't verify the exact pathnames for Fedora.

https://koji.fedoraproject.org/koji/rpminfo?rpmID=8491933 ;)

[...]
> > +# RHEL:
> > +#   /usr/share/AAVMF/AAVMF_CODE.fd
> > +#   /usr/share/AAVMF/AAVMF_VARS.fd
> 
> Looks legit. (Might want to call "RHEL" "RHELSA" though, in this context
> -- no clue. Ask Drew :))

Yeah, you're probably right.

[...]
> Please expand the comment:
> 
>   CHANGE ME TO THE NAME OF THE FILE THAT YOU CREATED AS A COPY of THE
>   VARSTORE TEMPLATE

Nope. The line would get waaay too long, and I trust the
user to understand the basic idea after having gone through
the paragraphs above.

Here's an updated version, what do you think about it?


# 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, as well as the paths to the
# files themselves, will be different. Some examples:
#
# Fedora:
#   edk2-aarch64                          (package)
#   /usr/share/edk2/aarch64/QEMU_EFI.fd   (binary)
#   /usr/share/edk2/aarch64/QEMU_VARS.fd  (template)
#
# RHELSA:
#   AAVMF                                 (package)
#   /usr/share/AAVMF/AAVMF_CODE.fd        (binary)
#   /usr/share/AAVMF/AAVMF_VARS.fd        (varstore)

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Laszlo Ersek]

On 02/08/17 19:32, Peter Maydell wrote:
> On 8 February 2017 at 17:35, Andrea Bolognani <abologna@redhat.com> wrote:

>> +# 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 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
> 
> It's a shame that we've ended up with different
> firmware names (even between RHEL and Fedora, without
> getting to Debian or SUSE).

The root cause (or, well, *one* root cause) is that OVMF used to be
un-distributable in Fedora (and I assume, Debian), due to the
requirements that Fedora presented (and presents) for package licenses.
In particular, the FAT driver in OVMF used not to be free software (no
freedom #0 -- "use for any purpose"). The RHEL Supplementary channel
could however accommodate OVMF (as Tech Preview).

So this was a strange situation where a package first entered RHEL (even
if in a "side channel"), and Fedora picked it up way later.

Also, my personal workflow does not really match Fedora. I'll break my
back for upstream and for RHEL (I *am* serious about "upstream first"),
but community distros are not a good fit for me, either technically or
socially. They are neither upstreams (with nicely bisectable git repos,
sane mailing lists -- have you seen HyperKitty? -- or sane bug trackers,
for example), nor real supported, stable downstreams, with necks and
money on the line. In the virt team @RH, I'm responsible for upstream
and RHEL, but I specifically requested to be independent of Fedora.

Whenever OVMF or AAVMF bugs are reported in RHBZ, for Fedora, I do take
a look, but I don't take responsibility. I'm not even a "proven
packager" for Fedora.

(I guess I'll be crucified for the above paragraph, but I guess I might
as well speak my mind on this, for one data point.)

Re: Debian, I *had* been on the lookout for OVMF-related Debian bugs
(and some other community distro bugs), and I used to comment on them
quite liberally, especially when it came to packaging. Example:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918

I also try to respond to OVMF-related reports that people file in the
QEMU LaunchPad tracker (... despite TianoCore having a real Bugzilla bug
tracker, which I'm forced to say runs circles around LaunchPad.)

But, packaging questions and uniformity across distros aren't my stuff.

> Would making UEFI a
> more "official" rom image in pc-bios/ help to
> harmonise things, or just introduce yet another
> possibility to the mix?

On one hand, it would be the best possible solution. I believe we've
been thinking on-and-off about bundling OVMF and ArmVirtQemu with QEMU,
since FatPkg in edk2 became free software. (... Because Microsoft
graciously liberated the license, after Intel worked with them for a
looong time on that. Kudos again to both companies!)

On the other hand, upstream edk2 doesn't do releases (not in the "whole
community stabilization / soft freeze / hard freeze / merge window
closed" sense anyway). So Gerd -- because it would fall under Gerd's
maintainership I think -- would have to deal with yet another project
like iPXE (no releases). It's up to him, I guess.

NB: Gerd maintains a distro-independent set of RPM packages at
<https://www.kraxel.org/repos/>, which provide bleeding edge upstream
builds. For "wide community" purposes, I tend to view those as the "gold
standard". If they run into build or functional failures, in the minimal
amount of private (but still open source) patches that we carry in them,
I do consider helping out with those as a priority.

So I guess Gerd would have to decide which of the both (or maybe both?)
streams he'd want to maintain -- the one bundled with QEMU, or the one
in his "bleeding edge" repo. ... If iPXE is any example, then my guess
is "both" :)

Sheesh, sorry about this huge rant. Don't push my buttons, people. ;)

Thanks
Laszlo

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

[Andrea Bolognani]

On Wed, 2017-02-08 at 18:32 +0000, Peter Maydell wrote:
> What does nodefaults disable on the virt board?
> (I've never looked into exactly what nodefaults does...)

When -nodefaults is missing, a default virtio-net-pci
plugged into 00:01.0 is automatically added.

> There doesn't seem to be any specification of the GIC
> version (unless I missed it in the config file); you
> probably want -machine gic-version=host if you're using
> -cpu host.

Very good point! I've added it.

I would really, really like to be able to specify the
CPU model in the configuration file as well, but I haven't
found a way to do so :(

On the other hand, I just realized that I can add

  [machine]
    graphics = "off"

to get rid of -nographic on the command line! \o/

> > +# 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:
> 
> The theory of 'virt' is it only has the essential
> devices anyway.

See above ;)

The use of -nodefaults is there mostly to guarantee that we
always start from a clean slate, like for example add the
Ethernet adapter ourselves (giving us a chance to comment
on its usage) instead of using the default one.

Another goal is to be consistent with the q35 sample
configuration files: ideally comparing mach-virt-serial.cfg
and q35-virtio-serial.cfg, for example, should yield a
very minimal diff.

> > +#   00:00.0 Host bridge
> 
> I'm pretty sure -nodefaults isn't going to disable
> the GIC, the UART, the flash devices, etc etc that
> the virt board has. Not everything in the world is
> a PCI device :-)

Right. So far I've basically stuck with PCI devices: even
the device listing, as you can see, is modeled after the
output of lspci.

That said, I'm not against documenting more devices.

[...]
> It's a shame that we've ended up with different
> firmware names (even between RHEL and Fedora, without
> getting to Debian or SUSE).

Yeah, it's pretty unfortunate :(

> Would making UEFI a
> more "official" rom image in pc-bios/ help to
> harmonise things, or just introduce yet another
> possibility to the mix?

Sorry, no idea. I'll let someone else comment on this one.

[...]
> > +[device "console"]
> > +  driver = "virtconsole"
> > +  chardev = "hostconsole"
> 
> Won't most guests expect serial to be the default
> PL011 UART ?

Possibly. I'm using virtconsole here (and in q35*serial.cfg)
mostly to have as much VirtIO as possible, but I also
document the fact that you might want or need to use the
native serial console instead.

Moreover, something that I haven't been able to do on
mach-virt (even though I could on q35, but again, I want the
files to be as close as possible) is to configure the serial
console from the configuration file.

Seeing as we have an alternative, I'd rather keep it this
way and minimize the number of command line arguments the
user needs to specify.

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Laszlo Ersek]

On 02/08/17 19:49, Andrea Bolognani wrote:
> On Wed, 2017-02-08 at 19:11 +0100, Laszlo Ersek wrote:
>> How about:
>>  
>>    For any new guest, its permanent, private variable store should
>>    initially be copied from the template file provided as part of the
>>    ArmVirtQemu firmware platform (which is occasionally distributed
>>    under the AAVMF package).
> 
> The naming is confusing enough as it is, no need to drag
> ArmVirtQemu into this I think ;)

Yeah, that's the upstream platform name, and I know that Leif and Ard
dislike "AAVMF". In downstream, we needed some name for the package,
when -- if memory serves -- upstream was still called
"ArmPlatformPkg/ArmVirtualizationPkg", and there was no Xen support,
only QEMU, so QEMU wasn't even in the name, because it was implied.

We agreed upon "AAVMF" (don't say anything), and of course the name
percolated to the outside, via mailing lists, other projects that
embedded the name (libguestfs, maybe?), and so on.

> 
>>> +# Fedora:
>>> +#   /usr/share/edk2/aarch64/QEMU_EFI.fd
>>> +#   /usr/share/edk2/aarch64/QEMU_VARS.fd
>>  
>> Please annotate each as firmware binary & variable store template.
> 
> I had such annotations at some points, I got rid of them
> because they seemed a bit redundant. Added them back in.
> 
>> Also, I can't verify the exact pathnames for Fedora.
> 
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=8491933 ;)

Ahhh, it's *very* good that you provided this reference, because now I
see that the file names below are incorrect. Namely, for aarch64 guests,
you have to use the files that are padded to 64MB, *not* the files as
they fall out of the edk2 build process.

> 
> [...]
>>> +# RHEL:
>>> +#   /usr/share/AAVMF/AAVMF_CODE.fd
>>> +#   /usr/share/AAVMF/AAVMF_VARS.fd
>>  
>> Looks legit. (Might want to call "RHEL" "RHELSA" though, in this context
>> -- no clue. Ask Drew :))
> 
> Yeah, you're probably right.
> 
> [...]
>> Please expand the comment:
>>  
>>    CHANGE ME TO THE NAME OF THE FILE THAT YOU CREATED AS A COPY of THE
>>    VARSTORE TEMPLATE
> 
> Nope. The line would get waaay too long, and I trust the
> user

Good for you :)

> to understand the basic idea after having gone through
> the paragraphs above.

Okay ;)

> 
> Here's an updated version, what do you think about it?
> 
> 
> # 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, as well as the paths to the

red flag: please say "variable store *template*"

> # files themselves, will be different. Some examples:
> #
> # Fedora:
> #   edk2-aarch64                          (package)
> #   /usr/share/edk2/aarch64/QEMU_EFI.fd   (binary)
> #   /usr/share/edk2/aarch64/QEMU_VARS.fd  (template)
> #
> # RHELSA:
> #   AAVMF                                 (package)
> #   /usr/share/AAVMF/AAVMF_CODE.fd        (binary)
> #   /usr/share/AAVMF/AAVMF_VARS.fd        (varstore)

Two comments:

- Under Fedora, you have (template), which is cool, (varstore) is bad. :)

- Again, the files you note above for Fedora are 2MB and 768KB in size,
respectively, which is wrong. The files you note for RHELSA are both
64MB in size, which is right. Fedora ships the according files as well,
but their names are different:

/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw      (binary)
/usr/share/edk2/aarch64/vars-template-pflash.raw (varstore template)

Thanks!
Laszlo

> 
> -- 
> Andrea Bolognani / Red Hat / Virtualization
> 

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

[Peter Maydell]

On 8 February 2017 at 19:28, Andrea Bolognani <abologna@redhat.com> wrote:
> On Wed, 2017-02-08 at 18:32 +0000, Peter Maydell wrote:
>> What does nodefaults disable on the virt board?
>> (I've never looked into exactly what nodefaults does...)
>
> When -nodefaults is missing, a default virtio-net-pci
> plugged into 00:01.0 is automatically added.

Ah, right, default -net commands. Is that it?

> On the other hand, I just realized that I can add
>
>   [machine]
>     graphics = "off"
>
> to get rid of -nographic on the command line! \o/

-nographic is kind of odd if you're taking the
"use -nodefaults and specify everything manually"
because it wraps up a whole pile of default config
in one oddball legacy config switch. I would have
expected -display none and whatever other options
you wanted.

> [...]
>> > +[device "console"]
>> > +  driver = "virtconsole"
>> > +  chardev = "hostconsole"
>>
>> Won't most guests expect serial to be the default
>> PL011 UART ?
>
> Possibly. I'm using virtconsole here (and in q35*serial.cfg)
> mostly to have as much VirtIO as possible, but I also
> document the fact that you might want or need to use the
> native serial console instead.
>
> Moreover, something that I haven't been able to do on
> mach-virt (even though I could on q35, but again, I want the
> files to be as close as possible) is to configure the serial
> console from the configuration file.

If there's stuff we can fix in the virt board to make
this work the way it does on the PC model I'm happy
to make fixes to help.

> Seeing as we have an alternative, I'd rather keep it this
> way and minimize the number of command line arguments the
> user needs to specify.

The trouble with using virtconsole is that you have to
get quite a long way forward (probing and setting up
PCI, etc) before you can get any kind of console output.
"System doesn't boot and doesn't produce any output"
is a common and really annoying failure mode in the
ARM world, and I think that using virtconsole is
asking for that kind of thing to happen more rather
than less often. (Plus having two different serial
ports in the guest means that now the user has to
configure where both of them are supposed to output.)

thanks
-- PMM

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

[Laszlo Ersek]

On 02/08/17 20:28, Andrea Bolognani wrote:
> On Wed, 2017-02-08 at 18:32 +0000, Peter Maydell wrote:
>> What does nodefaults disable on the virt board?
>> (I've never looked into exactly what nodefaults does...)
> 
> When -nodefaults is missing, a default virtio-net-pci
> plugged into 00:01.0 is automatically added.
> 
>> There doesn't seem to be any specification of the GIC
>> version (unless I missed it in the config file); you
>> probably want -machine gic-version=host if you're using
>> -cpu host.
> 
> Very good point! I've added it.
> 
> I would really, really like to be able to specify the
> CPU model in the configuration file as well, but I haven't
> found a way to do so :(
> 
> On the other hand, I just realized that I can add
> 
>   [machine]
>     graphics = "off"
> 
> to get rid of -nographic on the command line! \o/
> 
>>> +# 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:
>>  
>> The theory of 'virt' is it only has the essential
>> devices anyway.
> 
> See above ;)
> 
> The use of -nodefaults is there mostly to guarantee that we
> always start from a clean slate, like for example add the
> Ethernet adapter ourselves (giving us a chance to comment
> on its usage) instead of using the default one.
> 
> Another goal is to be consistent with the q35 sample
> configuration files: ideally comparing mach-virt-serial.cfg
> and q35-virtio-serial.cfg, for example, should yield a
> very minimal diff.
> 
>>> +#   00:00.0 Host bridge
>>  
>> I'm pretty sure -nodefaults isn't going to disable
>> the GIC, the UART, the flash devices, etc etc that
>> the virt board has. Not everything in the world is
>> a PCI device :-)
> 
> Right. So far I've basically stuck with PCI devices: even
> the device listing, as you can see, is modeled after the
> output of lspci.
> 
> That said, I'm not against documenting more devices.
> 
> [...]
>> It's a shame that we've ended up with different
>> firmware names (even between RHEL and Fedora, without
>> getting to Debian or SUSE).
> 
> Yeah, it's pretty unfortunate :(
> 
>> Would making UEFI a
>> more "official" rom image in pc-bios/ help to
>> harmonise things, or just introduce yet another
>> possibility to the mix?
> 
> Sorry, no idea. I'll let someone else comment on this one.
> 
> [...]
>>> +[device "console"]
>>> +  driver = "virtconsole"
>>> +  chardev = "hostconsole"
>>  
>> Won't most guests expect serial to be the default
>> PL011 UART ?
> 
> Possibly. I'm using virtconsole here (and in q35*serial.cfg)
> mostly to have as much VirtIO as possible, but I also
> document the fact that you might want or need to use the
> native serial console instead.

If you care about firmware logs, or early guest kernel logs, from
aarch64 guests, you absolutely need a PL011 UART.

> 
> Moreover, something that I haven't been able to do on
> mach-virt (even though I could on q35, but again, I want the
> files to be as close as possible) is to configure the serial
> console from the configuration file.

What do you mean by "configure the serial console"?

Thanks
Laszlo

> 
> Seeing as we have an alternative, I'd rather keep it this
> way and minimize the number of command line arguments the
> user needs to specify.
> 
> -- 
> Andrea Bolognani / Red Hat / Virtualization
> 

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

[Peter Maydell]

On 8 February 2017 at 19:23, Laszlo Ersek <lersek@redhat.com> wrote:
> On 02/08/17 19:32, Peter Maydell wrote:
>> Would making UEFI a
>> more "official" rom image in pc-bios/ help to
>> harmonise things, or just introduce yet another
>> possibility to the mix?
>
> On one hand, it would be the best possible solution. I believe we've
> been thinking on-and-off about bundling OVMF and ArmVirtQemu with QEMU,
> since FatPkg in edk2 became free software. (... Because Microsoft
> graciously liberated the license, after Intel worked with them for a
> looong time on that. Kudos again to both companies!)
>
> On the other hand, upstream edk2 doesn't do releases (not in the "whole
> community stabilization / soft freeze / hard freeze / merge window
> closed" sense anyway). So Gerd -- because it would fall under Gerd's
> maintainership I think -- would have to deal with yet another project
> like iPXE (no releases). It's up to him, I guess.

Yes, since I don't personally have the time or expertise this
definitely comes down to "does whoever would be doing
the work think it's a good idea or not".

thanks
-- PMM

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

[Andrea Bolognani]

On Wed, 2017-02-08 at 20:34 +0100, Laszlo Ersek wrote:
> > > Also, I can't verify the exact pathnames for Fedora.
> > 
> > https://koji.fedoraproject.org/koji/rpminfo?rpmID=8491933 ;)
> 
> Ahhh, it's *very* good that you provided this reference, because now I
> see that the file names below are incorrect. Namely, for aarch64 guests,
> you have to use the files that are padded to 64MB, *not* the files as
> they fall out of the edk2 build process.

Go figure... Thanks for spotting that!

[...]
> > # Depending on the OS distribution you're using on the
> > # host, the name of the package containing the firmware
> > # binary and variable store, as well as the paths to the
> 
> red flag: please say "variable store *template*"

Right. Missed it, sorry.

[...]
> > # Fedora:
> > #   edk2-aarch64                          (package)
> > #   /usr/share/edk2/aarch64/QEMU_EFI.fd   (binary)
> > #   /usr/share/edk2/aarch64/QEMU_VARS.fd  (template)
> > #
> > # RHELSA:
> > #   AAVMF                                 (package)
> > #   /usr/share/AAVMF/AAVMF_CODE.fd        (binary)
> > #   /usr/share/AAVMF/AAVMF_VARS.fd        (varstore)
> 
> Two comments:
> 
> - Under Fedora, you have (template), which is cool, (varstore) is bad. :)

That just shows that I'm getting really tired and I should
step away from the keyboard for the day :/

> - Again, the files you note above for Fedora are 2MB and 768KB in size,
> respectively, which is wrong. The files you note for RHELSA are both
> 64MB in size, which is right. Fedora ships the according files as well,
> but their names are different:
> 
> /usr/share/edk2/aarch64/QEMU_EFI-pflash.raw      (binary)
> /usr/share/edk2/aarch64/vars-template-pflash.raw (varstore template)

Consider it fixed!

(Those filenames, though... Ewww.)

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Laszlo Ersek]

On 02/08/17 20:36, Peter Maydell wrote:
> On 8 February 2017 at 19:28, Andrea Bolognani <abologna@redhat.com> wrote:
>> On Wed, 2017-02-08 at 18:32 +0000, Peter Maydell wrote:

>>> Won't most guests expect serial to be the default
>>> PL011 UART ?
>>
>> Possibly. I'm using virtconsole here (and in q35*serial.cfg)
>> mostly to have as much VirtIO as possible, but I also
>> document the fact that you might want or need to use the
>> native serial console instead.
>>
>> Moreover, something that I haven't been able to do on
>> mach-virt (even though I could on q35, but again, I want the
>> files to be as close as possible) is to configure the serial
>> console from the configuration file.
> 
> If there's stuff we can fix in the virt board to make
> this work the way it does on the PC model I'm happy
> to make fixes to help.
> 
>> Seeing as we have an alternative, I'd rather keep it this
>> way and minimize the number of command line arguments the
>> user needs to specify.
> 
> The trouble with using virtconsole is that you have to
> get quite a long way forward (probing and setting up
> PCI, etc) before you can get any kind of console output.
> "System doesn't boot and doesn't produce any output"
> is a common and really annoying failure mode in the
> ARM world, and I think that using virtconsole is
> asking for that kind of thing to happen more rather
> than less often.

My point exactly.
Thanks
Laszlo

> (Plus having two different serial
> ports in the guest means that now the user has to
> configure where both of them are supposed to output.)
> 
> thanks
> -- PMM
> 

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

[Andrew Jones]

Hi Andrea,

Thanks for this! I see there's already been plenty of discussion
and comments (you guys work too late...). I'll try to add my own
couple of cents now too.

On Wed, Feb 08, 2017 at 06:35:31PM +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 | 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)
> +# =========================================================
> +#
> +# 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

I see Peter and you are discussing what to document here. IMO,
we should simply state -nodefaults provides us a base mach-virt
board with no peripherals. If we were to list all the platform
devices then we add another place to maintain every time we
change the board code. It would just be a matter of time before
they're out of synch.

> +#
> +# 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.
> +
> +[machine]
> +  type = "virt"
> +  accel = "kvm"
> +
> +[memory]
> +  size = "1024"

So I'm not sure about providing this, at least not in this
config file. I think we should expect the user to provide ram
size explicitly, as this depends on what they want to do with
the guest. Even accel is debatable, as many users may want to
use tcg from their x86 machines.

How about focusing this config on the PCIe topology and default
devices? Additional config defaults like accel and ram could
be added to an additional config, if we want.

> +
> +
> +# 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 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 = "/usr/share/edk2/aarch64/QEMU_EFI.fd"  # CHANGE ME
> +  format = "raw"
> +  if = "pflash"
> +  unit = "0"
> +  readonly = "on"
> +
> +[drive "aavmf-vars"]
> +  file = "guest_VARS.fd"                        # CHANGE ME
> +  format = "raw"
> +  if = "pflash"
> +  unit = "1"

The fact these entries need 'CHANGE ME' comments make me think they
should also be removed from this config and required explicitly,
or provided by other configs. Perhaps we can create a config for
each firmware path we know of? Or, is there any way for a user
to override the file path from the command line? Does

 -readconfig config -drive id=aavmf-vars,file=new-path

work? If so, then we can document how CHANGEME's can be easily
changed without touching the file.

> +
> +
> +# 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 "pci.1"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.0"
> +  port = "1"
> +  chassis = "1"
> +  multifunction = "on"
> +
> +[device "pci.2"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.1"
> +  port = "2"
> +  chassis = "2"
> +
> +[device "pci.3"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.2"
> +  port = "3"
> +  chassis = "3"
> +
> +[device "pci.4"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.3"
> +  port = "4"
> +  chassis = "4"
> +
> +[device "pci.5"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.4"
> +  port = "5"
> +  chassis = "5"
> +
> +[device "pci.6"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.5"
> +  port = "6"
> +  chassis = "6"
> +
> +[device "pci.7"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.6"
> +  port = "7"
> +  chassis = "7"
> +
> +[device "pci.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.
> +
> +[device "scsi"]
> +  driver = "virtio-scsi-pci"
> +  bus = "pci.1"
> +  addr = "00.0"
> +
> +[device "scsi-disk"]
> +  driver = "scsi-hd"
> +  bus = "scsi.0"
> +  drive = "disk"
> +
> +[drive "disk"]
> +  file = "guest.qcow2"                          # CHANGE ME
> +  format = "qcow2"
> +  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 = "pci.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 = "pci.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

We use virtio-gpu because emulating a legacy VGA framebuffer
is not possible on AArch64 KVM guests due to unavoidable
stage1 / stage2 page table cache mode mismatches.

Or just leave the troublesome comment...

> +# 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 trying
> +# to display a GTK+ 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..6bf8cb2
> --- /dev/null
> +++ b/docs/mach-virt-serial.cfg
> @@ -0,0 +1,234 @@
> +# mach-virt - VirtIO guest (serial console)
> +# =========================================================
> +#
> +# 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
> +# =========================================================
> +#
> +# 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 = "virt"
> +  accel = "kvm"
> +
> +[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 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 = "/usr/share/edk2/aarch64/QEMU_EFI.fd"  # CHANGE ME
> +  format = "raw"
> +  if = "pflash"
> +  unit = "0"
> +  readonly = "on"
> +
> +[drive "aavmf-vars"]
> +  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 "pci.1"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.0"
> +  port = "1"
> +  chassis = "1"
> +  multifunction = "on"
> +
> +[device "pci.2"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.1"
> +  port = "2"
> +  chassis = "2"
> +
> +[device "pci.3"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.2"
> +  port = "3"
> +  chassis = "3"
> +
> +[device "pci.4"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.3"
> +  port = "4"
> +  chassis = "4"
> +
> +[device "pci.5"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.4"
> +  port = "5"
> +  chassis = "5"
> +
> +[device "pci.6"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.5"
> +  port = "6"
> +  chassis = "6"
> +
> +[device "pci.7"]
> +  driver = "pcie-root-port"
> +  bus = "pcie.0"
> +  addr = "1c.6"
> +  port = "7"
> +  chassis = "7"
> +
> +[device "pci.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.
> +
> +[device "scsi"]
> +  driver = "virtio-scsi-pci"
> +  bus = "pci.1"
> +  addr = "00.0"
> +
> +[device "scsi-disk"]
> +  driver = "scsi-hd"
> +  bus = "scsi.0"
> +  drive = "disk"
> +
> +[drive "disk"]
> +  file = "guest.qcow2"                          # CHANGE ME
> +  format = "qcow2"
> +  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 = "pci.2"
> +  addr = "00.0"
> +
> +
> +# Communication controller (serial console)
> +# =========================================================
> +#
> +# 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 = "stdio"
> +
> +[device "serial"]
> +  driver = "virtio-serial-pci"
> +  bus = "pci.3"
> +  addr = "00.0"
> +
> +[device "console"]
> +  driver = "virtconsole"
> +  chardev = "hostconsole"
> -- 
> 2.7.4
> 
>

I agree with the comments of others that we should be using
the PL011 instead. We should also set it up such that the
monitor is multiplexed, so ^C won't terminate the guest and
^A will allow us to go to the monitor.

Thanks,
drew 

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

[Andrew Jones]

On Wed, Feb 08, 2017 at 07:11:42PM +0100, Laszlo Ersek wrote:
> > +# RHEL:
> > +#   /usr/share/AAVMF/AAVMF_CODE.fd
> > +#   /usr/share/AAVMF/AAVMF_VARS.fd
> 
> Looks legit. (Might want to call "RHEL" "RHELSA" though, in this context
> -- no clue. Ask Drew :))
>

The first choice "RHEL" is correct. "RHELSA" still exists today,
but eventually that name should be phased out (IIUC), as AArch64
will be "just another RHEL arch", requiring no special name.

Thanks,
drew

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

[Peter Maydell]

On 9 February 2017 at 09:42, Andrew Jones <drjones@redhat.com> wrote:
> I see Peter and you are discussing what to document here. IMO,
> we should simply state -nodefaults provides us a base mach-virt
> board with no peripherals.

The thing about saying that is that it's not actually
correct -- you get the UART, etc etc peripherals whether
you say -nodefaults or not. I agree that listing them
in multiple places isn't a good idea though. Maybe
there's some wording that will work here.

thanks
-- PMM

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

[Andrea Bolognani]

On Thu, 2017-02-09 at 09:57 +0000, Peter Maydell wrote:
> > I see Peter and you are discussing what to document here. IMO,
> > we should simply state -nodefaults provides us a base mach-virt
> > board with no peripherals.
> 
> The thing about saying that is that it's not actually
> correct -- you get the UART, etc etc peripherals whether
> you say -nodefaults or not. I agree that listing them
> in multiple places isn't a good idea though. Maybe
> there's some wording that will work here.

Agreed, we just have to find the right wording. Would
something like

  Using -nodefaults is required to have full control over
  the virtual hardware: when it's specified, QEMU will
  only automatically add a small selection of core PCI
  devices, and leave the user in charge of adding more as
  they see fit. More specifically, the PCI devices that
  will always be present are:

    00:00.0 Host bridge

  This configuration file adds a number of other...

work for you? Please keep in mind that I want to be able
to use the very same paragraph both for q35 and mach-virt.

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Andrea Bolognani]

On Thu, 2017-02-09 at 10:49 +0100, Andrew Jones wrote:
> > > +# RHEL:
> > > +#   /usr/share/AAVMF/AAVMF_CODE.fd
> > > +#   /usr/share/AAVMF/AAVMF_VARS.fd
> > 
> > Looks legit. (Might want to call "RHEL" "RHELSA" though, in this context
> > -- no clue. Ask Drew :))
> 
> The first choice "RHEL" is correct. "RHELSA" still exists today,
> but eventually that name should be phased out (IIUC), as AArch64
> will be "just another RHEL arch", requiring no special name.

Can't wait for that day! I'll leave it unchanged then :)

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Andrew Jones]

On Thu, Feb 09, 2017 at 11:51:13AM +0100, Andrea Bolognani wrote:
> On Thu, 2017-02-09 at 09:57 +0000, Peter Maydell wrote:
> > > I see Peter and you are discussing what to document here. IMO,
> > > we should simply state -nodefaults provides us a base mach-virt
> > > board with no peripherals.
> > 
> > The thing about saying that is that it's not actually
> > correct -- you get the UART, etc etc peripherals whether
> > you say -nodefaults or not. I agree that listing them
> > in multiple places isn't a good idea though. Maybe
> > there's some wording that will work here.
> 
> Agreed, we just have to find the right wording. Would
> something like
> 
>   Using -nodefaults is required to have full control over
>   the virtual hardware: when it's specified, QEMU will
>   only automatically add a small selection of core PCI
>   devices, and leave the user in charge of adding more as
>   they see fit. More specifically, the PCI devices that
>   will always be present are:
> 
>     00:00.0 Host bridge
> 
>   This configuration file adds a number of other...
> 
> work for you? Please keep in mind that I want to be able
> to use the very same paragraph both for q35 and mach-virt.

I'm not sure having the exact same paragraph is a reasonable
goal. Does q35 have platform devices like mach-virt? The
devices we get on a 'qemu -nodefaults -machine virt' instance
are MMIO driven devices on the board, rather than devices
hung off the pcie host bridge.

Perhaps we can list the uart as an example; I don't suppose
it'll ever be removed. If we use wording such as "such as",
then it allows expansion to the board without a commitment to
update the list.

BTW, when I stated "-nodefaults provides us a base mach-virt
board with no peripherals.", I meant no _additional_
peripherals plugged into the board's virtio-mmio transports,
nor hung off the host bridge. Is there a word for those?
Maybe just non-builtin peripherals?

Thanks,
drew

> 
> -- 
> Andrea Bolognani / Red Hat / Virtualization
> 

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

[Andrea Bolognani]

On Thu, 2017-02-09 at 10:42 +0100, Andrew Jones wrote:
> > +[machine]
> > +  type = "virt"
> > +  accel = "kvm"
> > +
> > +[memory]
> > +  size = "1024"
> 
> So I'm not sure about providing this, at least not in this
> config file. I think we should expect the user to provide ram
> size explicitly, as this depends on what they want to do with
> the guest. Even accel is debatable, as many users may want to
> use tcg from their x86 machines.
> 
> How about focusing this config on the PCIe topology and default
> devices? Additional config defaults like accel and ram could
> be added to an additional config, if we want.

Well, this is a sample configuration, not a one-size-fits-all
solution. It's okay for it to be opinionated.

The way I expect this file to be consumed is that people will
copy it over[1] to some location, tweak it to their liking by
adding and removing devices and altering settings such as
memory size, then use it to start a specific guest from that
moment on. When they need another guest, they can make another
copy of the sample and start over.

So the least parameters the user will have to specify outside
of the configuration file, the better. We actually moved *away*
from the idea of including multiple configuration files (one
for the "common" parts such as PCIe controllers, one for other
devices such as the video card as opposed to the serial
console) because it's much easier to have everything in one
place, for usability and for documentation purposes.

It's not a framework, just a decent starting point.

[...]
> > +[drive "aavmf-code"]
> > +  file = "/usr/share/edk2/aarch64/QEMU_EFI.fd"  # CHANGE ME
> > +  format = "raw"
> > +  if = "pflash"
> > +  unit = "0"
> > +  readonly = "on"
> > +
> > +[drive "aavmf-vars"]
> > +  file = "guest_VARS.fd"                        # CHANGE ME
> > +  format = "raw"
> > +  if = "pflash"
> > +  unit = "1"
> 
> The fact these entries need 'CHANGE ME' comments make me think they
> should also be removed from this config and required explicitly,
> or provided by other configs. Perhaps we can create a config for
> each firmware path we know of? Or, is there any way for a user
> to override the file path from the command line? Does
> 
>  -readconfig config -drive id=aavmf-vars,file=new-path
> 
> work? If so, then we can document how CHANGEME's can be easily
> changed without touching the file.

See above.

[...]
> > +# Display controller
> > +# =========================================================
> > +#
> > +# We use virtio-gpu because the legacy VGA framebuffer is
> > +# very troublesome on aarch64, and virtio-gpu is the only
> 
> We use virtio-gpu because emulating a legacy VGA framebuffer
> is not possible on AArch64 KVM guests due to unavoidable
> stage1 / stage2 page table cache mode mismatches.
> 
> Or just leave the troublesome comment...

I guess that depends a lot on how low-level we want them
be... Overall, I kept them fairly high-level, not least
because that's pretty much as far my knowledge goes.

In other words, your take on the description is certainly
100% accurate but also 100% flying way over my head ;)

[...]
> I agree with the comments of others that we should be using
> the PL011 instead. We should also set it up such that the
> monitor is multiplexed, so ^C won't terminate the guest and
> ^A will allow us to go to the monitor.

That sounds awesome, how do I actually make it work from
the configuration file though?


[1] Looks like these files are not being installed on the
    system by 'make install'. I'd argue having them in
    /usr/share/doc/qemu/examples would be nice for users.
-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Andrea Bolognani]

On Wed, 2017-02-08 at 19:36 +0000, Peter Maydell wrote:
> > When -nodefaults is missing, a default virtio-net-pci
> > plugged into 00:01.0 is automatically added.
> 
> Ah, right, default -net commands. Is that it?

I believe so, but double checking is never the wrong thing
to do ;)

> > On the other hand, I just realized that I can add
> > 
> >   [machine]
> >     graphics = "off"
> > 
> > to get rid of -nographic on the command line! \o/

... and after writing this, I actually tested it and
realized that it doesn't quite do what I want it to :(

> -nographic is kind of odd if you're taking the
> "use -nodefaults and specify everything manually"
> because it wraps up a whole pile of default config
> in one oddball legacy config switch. I would have
> expected -display none and whatever other options
> you wanted.

-nographic is just what libvirt uses: if there's a better
way to achieve the same result then I'm all for it!

Seems like '-display none' behaves the same as -nographic,
at least for my purposes. Unfortunately I still can't have
it inside the configuration file, it has to be on the
command line :(

[...]
> > Moreover, something that I haven't been able to do on
> > mach-virt (even though I could on q35, but again, I want the
> > files to be as close as possible) is to configure the serial
> > console from the configuration file.
> 
> If there's stuff we can fix in the virt board to make
> this work the way it does on the PC model I'm happy
> to make fixes to help.

Well, with a q35 guest I can just add

  [chardev "hostconsole"]
    backend = "stdio"

  [device "console"]
    driver = "isa-serial"
    chardev = "hostconsole"

to the configuration file and get the same behavior I would
get by adding '-serial stdio' to the command line, but I
haven't been able to find any device that I can use the same
way as isa-serial on mach-virt. Maybe I just missed it?

[...]
> The trouble with using virtconsole is that you have to
> get quite a long way forward (probing and setting up
> PCI, etc) before you can get any kind of console output.
> "System doesn't boot and doesn't produce any output"
> is a common and really annoying failure mode in the
> ARM world, and I think that using virtconsole is
> asking for that kind of thing to happen more rather
> than less often. (Plus having two different serial
> ports in the guest means that now the user has to
> configure where both of them are supposed to output.)

You don't get one unless you use '-serial stdio' or
something like that in my experience, so if you use the
sample configuration file as I posted it you will only
get one serial console, the VirtIO-based one.

I agree though that the lack of boot output and especially
GRUB menu access in virtconsole is less then ideal, because
even though the users will eventually get a login prompt,
the first few seconds without any output at all might lead
them to believe the guest is not working properly.

I just wish there were a way to add the default serial
console straight from the configuration file...

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Andrew Jones]

On Thu, Feb 09, 2017 at 02:27:45PM +0100, Andrea Bolognani wrote:
> On Thu, 2017-02-09 at 10:42 +0100, Andrew Jones wrote:
> > > +[machine]
> > > +  type = "virt"
> > > +  accel = "kvm"
> > > +
> > > +[memory]
> > > +  size = "1024"
> > 
> > So I'm not sure about providing this, at least not in this
> > config file. I think we should expect the user to provide ram
> > size explicitly, as this depends on what they want to do with
> > the guest. Even accel is debatable, as many users may want to
> > use tcg from their x86 machines.
> > 
> > How about focusing this config on the PCIe topology and default
> > devices? Additional config defaults like accel and ram could
> > be added to an additional config, if we want.
> 
> Well, this is a sample configuration, not a one-size-fits-all
> solution. It's okay for it to be opinionated.
> 
> The way I expect this file to be consumed is that people will
> copy it over[1] to some location, tweak it to their liking by
> adding and removing devices and altering settings such as
> memory size, then use it to start a specific guest from that
> moment on. When they need another guest, they can make another
> copy of the sample and start over.
> 
> So the least parameters the user will have to specify outside
> of the configuration file, the better. We actually moved *away*
> from the idea of including multiple configuration files (one
> for the "common" parts such as PCIe controllers, one for other
> devices such as the video card as opposed to the serial
> console) because it's much easier to have everything in one
> place, for usability and for documentation purposes.
> 
> It's not a framework, just a decent starting point.

OK, if that's the consensus on how they should be used, then
that's fine by me. I've actually never used files like these,
but I was imagining they'd be great to use like this

 qemu -nodefaults -readconfig configfile -more -params \
      -that -may -override -stuff -in -the -configfile

Actually, I don't think anything is stopping me from using this
file that way. I'll have to try the file name override that I
suggested below, but

 qemu -nodefaults -readconfig configfile -m $MEM -machine accel=tcg

should certainly override correctly.

> 
> [...]
> > > +[drive "aavmf-code"]
> > > +  file = "/usr/share/edk2/aarch64/QEMU_EFI.fd"  # CHANGE ME
> > > +  format = "raw"
> > > +  if = "pflash"
> > > +  unit = "0"
> > > +  readonly = "on"
> > > +
> > > +[drive "aavmf-vars"]
> > > +  file = "guest_VARS.fd"                        # CHANGE ME
> > > +  format = "raw"
> > > +  if = "pflash"
> > > +  unit = "1"
> > 
> > The fact these entries need 'CHANGE ME' comments make me think they
> > should also be removed from this config and required explicitly,
> > or provided by other configs. Perhaps we can create a config for
> > each firmware path we know of? Or, is there any way for a user
> > to override the file path from the command line? Does
> > 
> >  -readconfig config -drive id=aavmf-vars,file=new-path
> > 
> > work? If so, then we can document how CHANGEME's can be easily
> > changed without touching the file.
> 
> See above.
> 
> [...]
> > > +# Display controller
> > > +# =========================================================
> > > +#
> > > +# We use virtio-gpu because the legacy VGA framebuffer is
> > > +# very troublesome on aarch64, and virtio-gpu is the only
> > 
> > We use virtio-gpu because emulating a legacy VGA framebuffer
> > is not possible on AArch64 KVM guests due to unavoidable
> > stage1 / stage2 page table cache mode mismatches.
> > 
> > Or just leave the troublesome comment...
> 
> I guess that depends a lot on how low-level we want them
> be... Overall, I kept them fairly high-level, not least
> because that's pretty much as far my knowledge goes.
> 
> In other words, your take on the description is certainly
> 100% accurate but also 100% flying way over my head ;)
> 
> [...]
> > I agree with the comments of others that we should be using
> > the PL011 instead. We should also set it up such that the
> > monitor is multiplexed, so ^C won't terminate the guest and
> > ^A will allow us to go to the monitor.
> 
> That sounds awesome, how do I actually make it work from
> the configuration file though?

Sorry, dunno :-)

> 
> 
> [1] Looks like these files are not being installed on the
>     system by 'make install'. I'd argue having them in
>     /usr/share/doc/qemu/examples would be nice for users.

I agree.

Thanks,
drew

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

[Andrew Jones]

On Thu, Feb 09, 2017 at 02:53:52PM +0100, Andrea Bolognani wrote:
> On Wed, 2017-02-08 at 19:36 +0000, Peter Maydell wrote:
> > The trouble with using virtconsole is that you have to
> > get quite a long way forward (probing and setting up
> > PCI, etc) before you can get any kind of console output.
> > "System doesn't boot and doesn't produce any output"
> > is a common and really annoying failure mode in the
> > ARM world, and I think that using virtconsole is
> > asking for that kind of thing to happen more rather
> > than less often. (Plus having two different serial
> > ports in the guest means that now the user has to
> > configure where both of them are supposed to output.)
> 
> You don't get one unless you use '-serial stdio' or
> something like that in my experience, so if you use the
> sample configuration file as I posted it you will only
> get one serial console, the VirtIO-based one.

The emulated UART is there no matter what, it's built-in on
the board. Whether it gets wired up to the console, stdio in
this case, depends on the '-serial stdio'. Adding the virtio-
console introduces another serial port, but OSes can still
discover the PL011 and try to use that in addition.

Thanks,
drew

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

[Andrea Bolognani]

On Thu, 2017-02-09 at 15:08 +0100, Andrew Jones wrote:
[...]
> Actually, I don't think anything is stopping me from using this
> file that way. I'll have to try the file name override that I
> suggested below, but
> 
>  qemu -nodefaults -readconfig configfile -m $MEM -machine accel=tcg
> 
> should certainly override correctly.

I just tried and at least overriding the amount of memory
definitely works :)

> > > I agree with the comments of others that we should be using
> > > the PL011 instead. We should also set it up such that the
> > > monitor is multiplexed, so ^C won't terminate the guest and
> > > ^A will allow us to go to the monitor.
> > 
> > That sounds awesome, how do I actually make it work from
> > the configuration file though?
> 
> Sorry, dunno :-)

I don't think there's a way to make it work without adding
some parameters to the command line, I'm afraid :(

But if you use '-serial mon:stdio' you can indeed switch
between the serial console and the QEMU monitor at will,
and as a (quite interesting) side-effect Ctrl+C will no
longer kill QEMU :)

By the way, switching between serial and monitor is not
done with Ctrl+A but with Ctrl+A-c, which is not the most
convenient shortcut if you're running your guests on a
remote host due to GNU screen using the very same one ;)

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Andrea Bolognani]

On Thu, 2017-02-09 at 13:28 +0100, Andrew Jones wrote:
> > Please keep in mind that I want to be able
> > to use the very same paragraph both for q35 and mach-virt.
> 
> I'm not sure having the exact same paragraph is a reasonable
> goal.

If not the exact same, there is no reason for it not to
be at least 90% shareable IMHO.

> Does q35 have platform devices like mach-virt?

I don't know. And I'm not sure we need to talk about them
or their aarch64 counterparts at all in the sample
configuration file, because AFAIK with the exception of the
GIC version they are not user configurable, or at the very
least not something the user will actively want to
configure (correct me if I'm wrong).

> The
> devices we get on a 'qemu -nodefaults -machine virt' instance
> are MMIO driven devices on the board, rather than devices
> hung off the pcie host bridge.

We want people to use PCIe instead of MMIO, though, so
again why should we even mention those?

It's just a sample configuration file we're talking about,
not a complete reference of the aarch64 architecture, so
it's entirely okay to skimp on details that don't directly
impact most users and be opinionated.

> Perhaps we can list the uart as an example; I don't suppose
> it'll ever be removed. If we use wording such as "such as",
> then it allows expansion to the board without a commitment to
> update the list.
> 
> BTW, when I stated "-nodefaults provides us a base mach-virt
> board with no peripherals.", I meant no _additional_
> peripherals plugged into the board's virtio-mmio transports,
> nor hung off the host bridge. Is there a word for those?
> Maybe just non-builtin peripherals?

Please propose the alternative wording you'd like to see
so we can discuss it :)

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Gerd Hoffmann]

  Hi,

> By the way, switching between serial and monitor is not
> done with Ctrl+A but with Ctrl+A-c, which is not the most
> convenient shortcut if you're running your guests on a
> remote host due to GNU screen using the very same one ;)

And for the record: "Ctrl+a h" prints a list of hotkeys.

cheers,
  Gerd

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

[Andrew Jones]

On Thu, Feb 09, 2017 at 04:10:43PM +0100, Andrea Bolognani wrote:
> On Thu, 2017-02-09 at 13:28 +0100, Andrew Jones wrote:
> > > Please keep in mind that I want to be able
> > > to use the very same paragraph both for q35 and mach-virt.
> > 
> > I'm not sure having the exact same paragraph is a reasonable
> > goal.
> 
> If not the exact same, there is no reason for it not to
> be at least 90% shareable IMHO.
> 
> > Does q35 have platform devices like mach-virt?
> 
> I don't know. And I'm not sure we need to talk about them
> or their aarch64 counterparts at all in the sample
> configuration file, because AFAIK with the exception of the
> GIC version they are not user configurable, or at the very
> least not something the user will actively want to
> configure (correct me if I'm wrong).

I'm OK with not mentioning them "too much" in this file. I
agree with Peter though that to be more accurate we shouldn't
state that '-nodefaults' results in a machine with nothing.
Therefore, some wording that states -nodefaults ensures no
non-builtin peripherals are automatically added, but builtin
peripherals, such as the PL011, will remain, seems like a
good idea.

> 
> > The
> > devices we get on a 'qemu -nodefaults -machine virt' instance
> > are MMIO driven devices on the board, rather than devices
> > hung off the pcie host bridge.
> 
> We want people to use PCIe instead of MMIO, though, so
> again why should we even mention those?

We want to use virtio-pci devices, as opposed to virtio-mmio
devices, which means using the PCIe ports you add vs. the
virtio-mmio transports. That doesn't mean we don't still
want to use the MMIO devices builtin to the board though,
the PL011 (UART) being a prime example.

> 
> It's just a sample configuration file we're talking about,
> not a complete reference of the aarch64 architecture, so
> it's entirely okay to skimp on details that don't directly
> impact most users and be opinionated.

I agree with being skimpy, but we don't want to cross the line
into misleading.

> 
> > Perhaps we can list the uart as an example; I don't suppose
> > it'll ever be removed. If we use wording such as "such as",
> > then it allows expansion to the board without a commitment to
> > update the list.
> > 
> > BTW, when I stated "-nodefaults provides us a base mach-virt
> > board with no peripherals.", I meant no _additional_
> > peripherals plugged into the board's virtio-mmio transports,
> > nor hung off the host bridge. Is there a word for those?
> > Maybe just non-builtin peripherals?
> 
> Please propose the alternative wording you'd like to see
> so we can discuss it :)

I guess I did above with "... -nodefaults ensures no non-builtin
peripherals are automatically added, but builtin peripherals,
such as the PL011, will remain..."

Thanks,
drew

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

[Andrea Bolognani]

On Thu, 2017-02-09 at 16:35 +0100, Andrew Jones wrote:
> > Please propose the alternative wording you'd like to see
> > so we can discuss it :)
> 
> I guess I did above with "... -nodefaults ensures no non-builtin
> peripherals are automatically added, but builtin peripherals,
> such as the PL011, will remain..."

Trying to work your proposal into my most recent stab at
this, I ended up with:

  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 small selection of core
  PCI devices and controllers; the user will then have to
  esplicitly add further devices.

  More specifically, the PCI devices that will always be
  present in the guest are:

    00:00.0 Host bridge

  This configuration file adds a number of other...

Does it look acceptable?

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Andrew Jones]

On Thu, Feb 09, 2017 at 05:11:38PM +0100, Andrea Bolognani wrote:
> On Thu, 2017-02-09 at 16:35 +0100, Andrew Jones wrote:
> > > Please propose the alternative wording you'd like to see
> > > so we can discuss it :)
> > 
> > I guess I did above with "... -nodefaults ensures no non-builtin
> > peripherals are automatically added, but builtin peripherals,
> > such as the PL011, will remain..."
> 
> Trying to work your proposal into my most recent stab at
> this, I ended up with:
> 
>   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 small selection of core
>   PCI devices and controllers; the user will then have to

Well, mach-virt doesn't currently add any pci devices with
-nodefault; just the host bridge. Personally, I'd state it that
way to avoid confusion, but I know you're trying to keep the
paragraph similar to the q35 one, and you're not technically
wrong...

>   esplicitly add further devices.

explicitly

> 
>   More specifically, the PCI devices that will always be
>   present in the guest are:
> 
>     00:00.0 Host bridge
> 
>   This configuration file adds a number of other...
> 
> Does it look acceptable?

I'm good with it.

Thanks,
drew

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

[Andrea Bolognani]

On Thu, 2017-02-09 at 17:36 +0100, Andrew Jones wrote:
> On Thu, Feb 09, 2017 at 05:11:38PM +0100, Andrea Bolognani wrote:
> > 
> > On Thu, 2017-02-09 at 16:35 +0100, Andrew Jones wrote:
> > > 
> > > > 
> > > > Please propose the alternative wording you'd like to see
> > > > so we can discuss it :)
> > >  
> > > I guess I did above with "... -nodefaults ensures no non-builtin
> > > peripherals are automatically added, but builtin peripherals,
> > > such as the PL011, will remain..."
> > 
> > Trying to work your proposal into my most recent stab at
> > this, I ended up with:
> > 
> >   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 small selection of core
> >   PCI devices and controllers; the user will then have to
> 
> Well, mach-virt doesn't currently add any pci devices with
> -nodefault; just the host bridge. Personally, I'd state it that
> way to avoid confusion, but I know you're trying to keep the
> paragraph similar to the q35 one, and you're not technically
> wrong...

Okay, one more try! ;)

  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...

-- 
Andrea Bolognani / Red Hat / Virtualization

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

[Andrew Jones]

On Thu, Feb 09, 2017 at 06:06:19PM +0100, Andrea Bolognani wrote:
> On Thu, 2017-02-09 at 17:36 +0100, Andrew Jones wrote:
> > On Thu, Feb 09, 2017 at 05:11:38PM +0100, Andrea Bolognani wrote:
> > > 
> > > On Thu, 2017-02-09 at 16:35 +0100, Andrew Jones wrote:
> > > > 
> > > > > 
> > > > > Please propose the alternative wording you'd like to see
> > > > > so we can discuss it :)
> > > >  
> > > > I guess I did above with "... -nodefaults ensures no non-builtin
> > > > peripherals are automatically added, but builtin peripherals,
> > > > such as the PL011, will remain..."
> > > 
> > > Trying to work your proposal into my most recent stab at
> > > this, I ended up with:
> > > 
> > >   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 small selection of core
> > >   PCI devices and controllers; the user will then have to
> > 
> > Well, mach-virt doesn't currently add any pci devices with
> > -nodefault; just the host bridge. Personally, I'd state it that
> > way to avoid confusion, but I know you're trying to keep the
> > paragraph similar to the q35 one, and you're not technically
> > wrong...
> 
> Okay, one more try! ;)
> 
>   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...
> 
> -- 
> Andrea Bolognani / Red Hat / Virtualization

Sounds good to me :-)

Thanks,
drew