On 8 February 2017 at 17:35, Andrea Bolognani <[email protected]> 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
