[Qemu-devel] [PATCH] q35: Provide improved sample configurations
Instead of having a single sample configuration file, now we have two: one gives access to the guest through the serial console and only includes a minimal set of devices, the other uses a graphical console and includes extra devices such as an audio card. Both configuration file are full commented, neatly organized, and use paravirtualized devices instead of emulated devices whenever possible for a better user experience. Moreover, they follow the PCI Express Guidelines (docs/pcie.txt) for their topology. --- I plan to provide similar sample configurations for aarch64/virt guests once the generic PCIe Root Ports have been merged. docs/q35-chipset.cfg | 152 docs/q35-graphical.cfg | 154 + docs/q35-serial.cfg| 110 +++ 3 files changed, 264 insertions(+), 152 deletions(-) delete mode 100644 docs/q35-chipset.cfg create mode 100644 docs/q35-graphical.cfg create mode 100644 docs/q35-serial.cfg diff --git a/docs/q35-chipset.cfg b/docs/q35-chipset.cfg deleted file mode 100644 index e4ddb7d..000 --- 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-graphical.cfg b/docs/q35-graphical.cfg new file mode 100644 index 000..90c25cc --- /dev/null +++ b/docs/q35-graphical.cfg @@ -0,0 +1,154 @@ +# q35 guest - sample configuration (graphical console) +# = +# +# Usage: +# +# $ qemu-system-x86_64 \ +# -nodefaults \ +#
Re: [Qemu-devel] [PATCH] q35: Provide improved sample configurations
Hi, > Both configuration file are full commented, neatly > organized, and use paravirtualized devices instead of > emulated devices whenever possible for a better user > experience. Moreover, they follow the PCI Express > Guidelines (docs/pcie.txt) for their topology. > --- > I plan to provide similar sample configurations for > aarch64/virt guests once the generic PCIe Root Ports > have been merged. > > docs/q35-chipset.cfg | 152 Please leave q35-chipset.cfg there. The purpose of q35-chipset.cfg is to document how you can build a virtual machine which comes as close as possible to physical hardware with q35 northbridge and ich9 southbridge. So it is pretty much fixed ;) Maybe it makes sense to add a comment at the top clarifying this. The (currently commented out) pcie switch configuration can be dropped or moved to another file. And maybe we can add the ethernet device meanwhile (has the e1000e emulation a ich9 device?). Adding another sample config focusing on pcie and good performance is perfectly fine of course. > docs/q35-graphical.cfg | 154 > + > docs/q35-serial.cfg| 110 +++ Note that you can specify -readconfig multiple times, so you can split out common stuff and ask people to run "qemu -readconfig q35-paravirt-base.cfg -readconfig q35-paravirt-$style.cfg" > +# PCIe controllers > +# = > +# > +# We create four PCIe Root Ports: the first three are used > +# by devices defined below, while the last one is left > +# unused so that one more device can be hotplugged. > + > +[device "pci.1"] > + driver = "ioh3420" > + bus = "pcie.0" > + addr = "0x2" > + port = "0x10" > + chassis = "1" I'd suggest to create 8 pcie root ports, as multifunction device in a single slot, following pcie.txt suggestions. And I'd pick slot 1c for that, simply because the pcie root ports are in that slot on physical hardware, but that is just cosmetic and a matter of taste. > +[device "usb"] > + driver = "nec-usb-xhci" > + bus = "pci.3" > + addr = "0x0" Good, needs promotion ;) > +[device "keyboard"] > + driver = "usb-kbd" > + bus = "usb.0" > + port = "1" We have a ps/2 keyboard anyway, so this is pointless (on x86, arm is a different story of course). > +[device "tablet"] > + driver = "usb-tablet" > + bus = "usb.0" > + port = "2" There is also virtio-tablet, but for a generic config usb is probably the better choice as virtio-tablet is supported by modern linux only (on x86, on arm we have only modern linux anyway so picking virtio-tablet should be fine). > +# Video card > +# = > +# > +# We plug the QXL video card directly into the PCIe Root > +# Bus as it is a legacy PCI device; this way, we can reduce > +# the number of PCIe controllers in the guest. > + > +[device "video"] > + driver = "qxl-vga" > + bus = "pcie.0" > + addr = "0x1" Note that you can put multiple devices into a single root port, using multifunction. I have a guest here which looks like this: root@localhost ~# lspci -vt -[:00]-+-00.0 Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller +-02.0 Device 1234: +-1b.0 Intel Corporation 82801I (ICH9 Family) HD Audio Controller +-1c.0-[01]00.0 Red Hat, Inc Virtio SCSI +-1c.1-[02]00.0 Red Hat, Inc Virtio network device +-1c.2-[03]-- +-1c.3-[04]-- +-1c.4-[05]--+-00.0 Red Hat, Inc Virtio console |+-00.1 Red Hat, Inc Virtio memory balloon |\-00.2 Red Hat, Inc Virtio input +-1c.5-[06]00.0 NEC Corporation uPD720200 USB 3.0 Host Controller +-1c.6-[07]-- +-1c.7-[08]-- +-1e.0-[09-0a]00.0-[0a]-- +-1f.0 Intel Corporation 82801IB (ICH9) LPC Interface Controller +-1f.2 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] \-1f.3 Intel Corporation 82801I (ICH9 Family) SMBus Controller cheers, Gerd
Re: [Qemu-devel] [PATCH] q35: Provide improved sample configurations
On 01/31/2017 02:34 PM, Gerd Hoffmann wrote: > > Note that you can specify -readconfig multiple times, so you can split > out common stuff and ask people to run "qemu -readconfig > q35-paravirt-base.cfg -readconfig q35-paravirt-$style.cfg" Can we add #include-like semantics, so that one .cfg file can automatically pull in pre-requisites without having to document a command-line use of multiple -readconfig? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] q35: Provide improved sample configurations
On Tue, 2017-01-31 at 21:34 +0100, Gerd Hoffmann wrote: > > docs/q35-chipset.cfg | 152 > > > > Please leave q35-chipset.cfg there. > > The purpose of q35-chipset.cfg is to document how you can build a > virtual machine which comes as close as possible to physical hardware > with q35 northbridge and ich9 southbridge. So it is pretty much > fixed ;) Maybe it makes sense to add a comment at the top clarifying > this. The (currently commented out) pcie switch configuration can be > dropped or moved to another file. And maybe we can add the ethernet > device meanwhile (has the e1000e emulation a ich9 device?). > > Adding another sample config focusing on pcie and good performance is > perfectly fine of course. Gotcha. I'll try to get this file in line with the new ones where it comes to structure and add comments without messing with its purpose. > > docs/q35-graphical.cfg | 154 > >+ > > docs/q35-serial.cfg| 110 +++ > > Note that you can specify -readconfig multiple times, so you can split > out common stuff and ask people to run "qemu -readconfig > q35-paravirt-base.cfg -readconfig q35-paravirt-$style.cfg" Oh, I didn't know that! How about q35-emulated.cfg # emulated guest q35-virtio-common.cfg # shared by all VirtIO guests q35-virtio-graphical.cfg # VirtIO guest, graphical console q35-virtio-serial.cfg # VirtIO guest, serial console > > +# PCIe controllers > > +# = > > +# > > +# We create four PCIe Root Ports: the first three are used > > +# by devices defined below, while the last one is left > > +# unused so that one more device can be hotplugged. > > + > > +[device "pci.1"] > > + driver = "ioh3420" > > + bus = "pcie.0" > > + addr = "0x2" > > + port = "0x10" > > + chassis = "1" > > I'd suggest to create 8 pcie root ports, as multifunction device in a > single slot, following pcie.txt suggestions. > > And I'd pick slot 1c for that, simply because the pcie root ports are in > that slot on physical hardware, but that is just cosmetic and a matter > of taste. Okay. > > +[device "usb"] > > + driver = "nec-usb-xhci" > > + bus = "pci.3" > > + addr = "0x0" > > Good, needs promotion ;) Eheh :) > > +[device "keyboard"] > > + driver = "usb-kbd" > > + bus = "usb.0" > > + port = "1" > > We have a ps/2 keyboard anyway, so this is pointless (on x86, arm is a > different story of course). Okay. I will add a comment about why this is the case. > > +[device "tablet"] > > + driver = "usb-tablet" > > + bus = "usb.0" > > + port = "2" > > There is also virtio-tablet, but for a generic config usb is probably > the better choice as virtio-tablet is supported by modern linux only (on > x86, on arm we have only modern linux anyway so picking virtio-tablet > should be fine). Okay, I will keep this in mind when working on the aarch64/virt sample configuration. We can probably use virtio-keyboard-pci and virtio-tablet-pci there, avoiding the need to have a USB controller at all. > > +# Video card > > +# = > > +# > > +# We plug the QXL video card directly into the PCIe Root > > +# Bus as it is a legacy PCI device; this way, we can reduce > > +# the number of PCIe controllers in the guest. > > + > > +[device "video"] > > + driver = "qxl-vga" > > + bus = "pcie.0" > > + addr = "0x1" > > Note that you can put multiple devices into a single root port, using > multifunction. I have a guest here which looks like this: > > root@localhost ~# lspci -vt > -[:00]-+-00.0 Intel Corporation 82G33/G31/P35/P31 Express DRAM > Controller >+-02.0 Device 1234: >+-1b.0 Intel Corporation 82801I (ICH9 Family) HD Audio > Controller >+-1c.0-[01]00.0 Red Hat, Inc Virtio SCSI >+-1c.1-[02]00.0 Red Hat, Inc Virtio network device >+-1c.2-[03]-- >+-1c.3-[04]-- >+-1c.4-[05]--+-00.0 Red Hat, Inc Virtio console >|+-00.1 Red Hat, Inc Virtio memory balloon >|\-00.2 Red Hat, Inc Virtio input >+-1c.5-[06]00.0 NEC Corporation uPD720200 USB 3.0 Host > Controller >+-1c.6-[07]-- >+-1c.7-[08]-- >+-1e.0-[09-0a]00.0-[0a]-- >+-1f.0 Intel Corporation 82801IB (ICH9) LPC Interface > Controller >+-1f.2 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port > SATA Controller [AHCI mode] >\-1f.3 Intel Corporation 82801I (ICH9 Family) SMBus > Controller Mh, I think it's less confusing to only share a single port between devices when the devices in question are of the same type, ie. ioh3420s. So I'd rather leave this as it is. -- Andrea Bolognani / Red Hat / Virtualization
Re: [Qemu-devel] [PATCH] q35: Provide improved sample configurations
On Tue, 2017-01-31 at 15:03 -0600, Eric Blake wrote: > > Note that you can specify -readconfig multiple times, so you can split > > out common stuff and ask people to run "qemu -readconfig > > q35-paravirt-base.cfg -readconfig q35-paravirt-$style.cfg" > > Can we add #include-like semantics, so that one .cfg file can > automatically pull in pre-requisites without having to document a > command-line use of multiple -readconfig? That would be neat! But in the short term calling -readconfig multiple times does the trick ;) We can update the sample configurations if and when #include is implemented. -- Andrea Bolognani / Red Hat / Virtualization
Re: [Qemu-devel] [PATCH] q35: Provide improved sample configurations
Hi, > q35-emulated.cfg # emulated guest > q35-virtio-common.cfg # shared by all VirtIO guests > q35-virtio-graphical.cfg # VirtIO guest, graphical console > q35-virtio-serial.cfg # VirtIO guest, serial console Looks good to me. > > > +[device "tablet"] > > > + driver = "usb-tablet" > > > + bus = "usb.0" > > > + port = "2" > > > > There is also virtio-tablet, but for a generic config usb is probably > > the better choice as virtio-tablet is supported by modern linux only (on > > x86, on arm we have only modern linux anyway so picking virtio-tablet > > should be fine). > > Okay, I will keep this in mind when working on the > aarch64/virt sample configuration. We can probably use > virtio-keyboard-pci and virtio-tablet-pci there, avoiding > the need to have a USB controller at all. Not sure whenever we have firmware support for virtio-keyboard (which of course only matters with virtio-gpu being supported, otherwise we have to use the serial line anyway to operate the grub boot menu). cheers, Gerd