| Message ID | 1485969640-8149-1-git-send-email-abologna@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, > * Document more devices: > - the video card is added by default; > - so is the Ethernet adapter, apparently. > > The last part seems to clash with some of Gerd's comments, > so I'm kinda puzzled. Oh yes, the wonderful confusing world of default devices ;) So, if you run qemu with "-nodefaults" it will not add those two devices. If you add a video card manually (via -device or config file entry) qemu will not add the default video card. Likewise, if you add a NIC manually, qemu will not add the default ethernet device (and IIRC creating the default netdev will be skipped too). cheers, Gerd
On Thu, 2017-02-02 at 08:49 +0100, Gerd Hoffmann wrote: > Oh yes, the wonderful confusing world of default devices ;) > > So, if you run qemu with "-nodefaults" it will not add those two > devices. And I wouldn't have it any other way ;) > If you add a video card manually (via -device or config file entry) qemu > will not add the default video card. > > Likewise, if you add a NIC manually, qemu will not add the default > ethernet device (and IIRC creating the default netdev will be skipped > too). This has the potential to give you some unexpected results but I'd say it's still entirely reasonable. So what do you think, should q35-emulated.cfg recommend the use of -nodefaults the same way q35-virtio-*.cfg do and add the video card (cirrus-vga?) and Ethernet adapter explicitly? The advantage in doing so would be that we would provide maybe slightly more documentation, and we would be able to plug the Ethernet adapter at 19.0 instead of 02.0, which as I understand it matches real hardware better. -- Andrea Bolognani / Red Hat / Virtualization
Hi, > > If you add a video card manually (via -device or config file entry) qemu > > will not add the default video card. > > > > Likewise, if you add a NIC manually, qemu will not add the default > > ethernet device (and IIRC creating the default netdev will be skipped > > too). > > This has the potential to give you some unexpected results Indeed. > but I'd say it's still entirely reasonable. Well, makes it easy for users to get started, just "qemu -cdrom $live" gives you a usable virtual machine without having to worry too much about what devices you want plug in. But that kind of magic -- while convenient at times -- can also easily get into the way. Guess why the -nodefaults switch exists ... > So what do you think, should q35-emulated.cfg recommend the > use of -nodefaults the same way q35-virtio-*.cfg do and add > the video card (cirrus-vga?) and Ethernet adapter explicitly? I think that would be good, for consistency across all q35*.cfg files. But please don't use cirrus[1], it isn't the default any more for good reasons. I'd suggest to go with our new default, which is stdvga (-device VGA), as we don't have intel graphics emulation. > The advantage in doing so would be that we would provide > maybe slightly more documentation, and we would be able to > plug the Ethernet adapter at 19.0 instead of 02.0, which as > I understand it matches real hardware better. Yes. cheers, Gerd [1] https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
On 02/01/2017 07:20 PM, Andrea Bolognani wrote: > 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; > Hi Andrea, > * 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. Appreciated. > --- > 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. > > The last part seems to clash with some of Gerd's comments, > so I'm kinda puzzled. > > > [v1] http://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg06342.html > > [...] > + > +# Machine options > +# ========================================================= > +# > +# We use the q35 machine type and enable KVM acceleration > +# for better performance. > + > +[machine] > + type = "q35" > + accel = "kvm" > + > + > +# PCI Express controllers > +# ========================================================= > +# > +# We add four PCIe Root Ports, all sharing the same slot > +# on the PCIe Root Bus. These ports support hotplug. > + > +[device "ich9-pcie-port-1"] I would use the new generic root port. > + 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" > + > + > +# Legacy PCI controllers > +# ========================================================= > +# > +# This bridge can be used to build an independent topology > +# for legacy PCI devices. > + > +[device "ich9-pci-bridge"] > + driver = "i82801b11-bridge" > + bus = "pcie.0" > + addr = "1e.0" > + I am not sure about having the DMI-PCI bridge "by default". Users can understand is actually a good idea to have it by default while we don't really want them to use legacy PCI devices on Q35; and even if so, they should use them as Integrated Endpoints. They don't have hotplug for the DMI-PCI bridge anyway. [...] > --- /dev/null > +++ b/docs/q35-virtio-common.cfg > @@ -0,0 +1,82 @@ > +# q35 - VirtIO guest (common bits) > +# ========================================================= > +# > +# Not very useful on its own. See q35-virtio-graphical.cfg > +# and q35-virtio-serial.cfg for usage instructions. > + > + > +# Machine options > +# ========================================================= > +# > +# We use the q35 machine type and enable KVM acceleration > +# for better performance. > + > +[machine] > + type = "q35" > + accel = "kvm" > + > + > +# PCIe controllers > +# ========================================================= > +# > +# We create eight PCIe 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 = "ioh3420" Same here, maybe we can use the new generic port. Thanks for taking your time to update the configuration files! Marcel I personally don't use them because every time I try, I find something with no config support.... > + bus = "pcie.0" > + addr = "0x1c.0x0" > + port = "0x10" > + chassis = "1" > + multifunction = "on" > + > +[device "pci.2"] > + driver = "ioh3420" > + bus = "pcie.0" > + addr = "0x1c.0x1" > + port = "0x11" > + chassis = "2" > + > +[device "pci.3"] > + driver = "ioh3420" > + bus = "pcie.0" > + addr = "0x1c.0x2" > + port = "0x12" > + chassis = "3" > + > +[device "pci.4"] > + driver = "ioh3420" > + bus = "pcie.0" > + addr = "0x1c.0x3" > + port = "0x13" > + chassis = "4" > + > +[device "pci.5"] > + driver = "ioh3420" > + bus = "pcie.0" > + addr = "0x1c.0x4" > + port = "0x14" > + chassis = "5" > + > +[device "pci.6"] > + driver = "ioh3420" > + bus = "pcie.0" > + addr = "0x1c.0x5" > + port = "0x15" > + chassis = "6" > + > +[device "pci.7"] > + driver = "ioh3420" > + bus = "pcie.0" > + addr = "0x1c.0x6" > + port = "0x16" > + chassis = "7" > + > +[device "pci.8"] > + driver = "ioh3420" > + bus = "pcie.0" > + addr = "0x1c.0x7" > + port = "0x17" > + chassis = "8" [...]
On Thu, 2017-02-02 at 16:42 +0200, Marcel Apfelbaum wrote: [...] > > +[device "ich9-pcie-port-1"] > > I would use the new generic root port. This sample configuration (q35-emulated.cfg) is supposed to match physical hardware as closely as possible, so we should stick with ioh3420s. [...] > > +[device "pci.1"] > > + driver = "ioh3420" > > Same here, maybe we can use the new generic port. These sample configuration files (q35-virtio-*.cfg) should probably use the generic ports instead, yes. It's just that they were not merged yet when I started working on this :) [...] > > +[device "ich9-pci-bridge"] > > + driver = "i82801b11-bridge" > > + bus = "pcie.0" > > + addr = "1e.0" > > I am not sure about having the DMI-PCI bridge "by default". > Users can understand is actually a good idea to have it by default > while we don't really want them to use legacy PCI devices on Q35; > and even if so, they should use them as Integrated Endpoints. > They don't have hotplug for the DMI-PCI bridge anyway. Not sure about this one. It doesn't show up on my laptop, so it's not like every single q35-based physical machine has it. I'd be okay with dropping it, but I leave the decision to Gerd. [...] > Thanks for taking your time to update the configuration files! > Marcel > > > I personally don't use them because every time I try, I > find something with no config support.... Is that so? Can you please test these new ones and see whether they work for you? -- Andrea Bolognani / Red Hat / Virtualization
On 02/02/2017 05:20 PM, Andrea Bolognani wrote: > On Thu, 2017-02-02 at 16:42 +0200, Marcel Apfelbaum wrote: > [...] >>> +[device "ich9-pcie-port-1"] >> >> I would use the new generic root port. > > This sample configuration (q35-emulated.cfg) is supposed to > match physical hardware as closely as possible, so we should > stick with ioh3420s. > Good point. > [...] >>> +[device "pci.1"] >>> + driver = "ioh3420" >> >> Same here, maybe we can use the new generic port. > > These sample configuration files (q35-virtio-*.cfg) should > probably use the generic ports instead, yes. It's just that > they were not merged yet when I started working on this :) > Indeed, they've been merged only today. So good timing :) > [...] >>> +[device "ich9-pci-bridge"] >>> + driver = "i82801b11-bridge" >>> + bus = "pcie.0" >>> + addr = "1e.0" >> >> I am not sure about having the DMI-PCI bridge "by default". >> Users can understand is actually a good idea to have it by default >> while we don't really want them to use legacy PCI devices on Q35; >> and even if so, they should use them as Integrated Endpoints. >> They don't have hotplug for the DMI-PCI bridge anyway. > > Not sure about this one. It doesn't show up on my laptop, Do you have a Q35 laptop ? Good for you, I thought Q35 machines are lost in time. I have a really old PC with Q35 chipset and I thought I am "special". > so it's not like every single q35-based physical machine has That was my point. > it. I'd be okay with dropping it, but I leave the decision > to Gerd. > Sure > [...] >> Thanks for taking your time to update the configuration files! >> Marcel >> >> >> I personally don't use them because every time I try, I >> find something with no config support.... > > Is that so? Can you please test these new ones and see > whether they work for you? > Well, I am sure they work :), I'll give them a try (I'll beon PTO next week), but their purpose is to be a template for more complex configurations. Once I start to tweak them for my needs I hit a dead end. I don't remember anything specific though. Thanks, Marcel > -- > Andrea Bolognani / Red Hat / Virtualization >
On Do, 2017-02-02 at 16:20 +0100, Andrea Bolognani wrote: > On Thu, 2017-02-02 at 16:42 +0200, Marcel Apfelbaum wrote: > [...] > > > +[device "ich9-pcie-port-1"] > > > > I would use the new generic root port. > > This sample configuration (q35-emulated.cfg) is supposed to > match physical hardware as closely as possible, so we should > stick with ioh3420s. Agree. > [...] > > > +[device "pci.1"] > > > + driver = "ioh3420" > > > > Same here, maybe we can use the new generic port. > > These sample configuration files (q35-virtio-*.cfg) should > probably use the generic ports instead, yes. It's just that > they were not merged yet when I started working on this :) Agree too. > > I am not sure about having the DMI-PCI bridge "by default". > > Users can understand is actually a good idea to have it by default > > while we don't really want them to use legacy PCI devices on Q35; > > and even if so, they should use them as Integrated Endpoints. > > They don't have hotplug for the DMI-PCI bridge anyway. > > Not sure about this one. It doesn't show up on my laptop, > so it's not like every single q35-based physical machine has > it. Is your laptop really q35+ich9 or something newer? > I'd be okay with dropping it, but I leave the decision > to Gerd. Please leave it in for qemu-emulated.cfg, as this is supposed to serve as documentation how real q35 hardware looks like. From the virtio variants it can be dropped. > > I personally don't use them because every time I try, I > > find something with no config support.... > > Is that so? Can you please test these new ones and see > whether they work for you? I think mst means that not all qemu command line switches are using QemuOpts, and the ones which don't can't be used with -readconfig. cheers, Gerd
On 02/03/2017 12:13 AM, Gerd Hoffmann wrote: > On Do, 2017-02-02 at 16:20 +0100, Andrea Bolognani wrote: >> On Thu, 2017-02-02 at 16:42 +0200, Marcel Apfelbaum wrote: [...] > >>> I personally don't use them because every time I try, I >>> find something with no config support.... >> >> Is that so? Can you please test these new ones and see >> whether they work for you? > > I think mst means that not all qemu command line switches are using ^^^ Marcel, not mst, but I am flattered :) > QemuOpts, and the ones which don't can't be used with -readconfig. > Yes, this is exactly what I meant, this is why I *personally* don't find -readconfig usable. Thanks, Marcel > cheers, > Gerd >
On Thu, 2017-02-02 at 23:13 +0100, Gerd Hoffmann wrote: > > Not sure about this one. It doesn't show up on my laptop, > > so it's not like every single q35-based physical machine has > > it. > > Is your laptop really q35+ich9 or something newer? Nope, something newer. Sorry for overlooking this. > > I'd be okay with dropping it, but I leave the decision > > to Gerd. > > Please leave it in for qemu-emulated.cfg, as this is supposed to serve > as documentation how real q35 hardware looks like. > > From the virtio variants it can be dropped. It was not there to begin with ;) -- Andrea Bolognani / Red Hat / Virtualization
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..aaa86e1 --- /dev/null +++ b/docs/q35-emulated.cfg @@ -0,0 +1,196 @@ +# q35 - Emulated guest (graphical console) +# ========================================================= +# +# Usage: +# +# $ qemu-system-x86_64 \ +# -readconfig q35-emulated.cfg \ +# -drive file=os.qcow2,format=qcow2 +# +# Or: +# +# $ qemu-system-x86_64 \ +# -readconfig q35-emulated.cfg \ +# -cdrom live.iso +# +# --------------------------------------------------------- +# +# This file contains a working configuration that can be +# used for booting a generic q35 guest without too much +# fuss, or as a starting point for a more fine-tuned +# configuration. The guest in question will be accessed +# using a graphical console. +# +# If not instructed otherwise, QEMU will create a bare +# machine with just the very essential chipset devices +# being present: +# +# 00.0 - Host bridge +# 01.0 - VGA compatible controller +# 02.0 - Ethernet controller +# 1f.0 - ISA bridge / LPC +# 1f.2 - SATA (AHCI) controller +# 1f.3 - SMBus controller +# +# This configuration file adds a number of devices that +# are very likely to be present in physical machines based +# on q35, more specifically: +# +# 1a.* - USB Controller #2 (EHCI + UHCI companions) +# 1b.0 - HD Audio Controller +# 1c.* - PCI Express Ports +# 1d.* - USB Controller #1 (EHCI + UHCI companions) +# 1e.0 - 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. + +[machine] + type = "q35" + accel = "kvm" + + +# PCI Express controllers +# ========================================================= +# +# We add four PCIe Root Ports, all sharing the same slot +# on the PCIe 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" + + +# Legacy PCI controllers +# ========================================================= +# +# This bridge can be used to build an independent topology +# for legacy PCI devices. + +[device "ich9-pci-bridge"] + driver = "i82801b11-bridge" + bus = "pcie.0" + addr = "1e.0" + + +# 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" + + +# Sound card +# ========================================================= +# +# The sound card is a legacy PCI device that is plugged +# directly into the PCIe 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-common.cfg b/docs/q35-virtio-common.cfg new file mode 100644 index 0000000..b143e65 --- /dev/null +++ b/docs/q35-virtio-common.cfg @@ -0,0 +1,82 @@ +# q35 - VirtIO guest (common bits) +# ========================================================= +# +# Not very useful on its own. See q35-virtio-graphical.cfg +# and q35-virtio-serial.cfg for usage instructions. + + +# Machine options +# ========================================================= +# +# We use the q35 machine type and enable KVM acceleration +# for better performance. + +[machine] + type = "q35" + accel = "kvm" + + +# PCIe controllers +# ========================================================= +# +# We create eight PCIe 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 = "ioh3420" + bus = "pcie.0" + addr = "0x1c.0x0" + port = "0x10" + chassis = "1" + multifunction = "on" + +[device "pci.2"] + driver = "ioh3420" + bus = "pcie.0" + addr = "0x1c.0x1" + port = "0x11" + chassis = "2" + +[device "pci.3"] + driver = "ioh3420" + bus = "pcie.0" + addr = "0x1c.0x2" + port = "0x12" + chassis = "3" + +[device "pci.4"] + driver = "ioh3420" + bus = "pcie.0" + addr = "0x1c.0x3" + port = "0x13" + chassis = "4" + +[device "pci.5"] + driver = "ioh3420" + bus = "pcie.0" + addr = "0x1c.0x4" + port = "0x14" + chassis = "5" + +[device "pci.6"] + driver = "ioh3420" + bus = "pcie.0" + addr = "0x1c.0x5" + port = "0x15" + chassis = "6" + +[device "pci.7"] + driver = "ioh3420" + bus = "pcie.0" + addr = "0x1c.0x6" + port = "0x16" + chassis = "7" + +[device "pci.8"] + driver = "ioh3420" + bus = "pcie.0" + addr = "0x1c.0x7" + port = "0x17" + chassis = "8" diff --git a/docs/q35-virtio-graphical.cfg b/docs/q35-virtio-graphical.cfg new file mode 100644 index 0000000..4948a20 --- /dev/null +++ b/docs/q35-virtio-graphical.cfg @@ -0,0 +1,113 @@ +# q35 - VirtIO guest (graphical console) +# ========================================================= +# +# Usage: +# +# $ qemu-system-x86_64 \ +# -nodefaults \ +# -readconfig q35-virtio-common.cfg \ +# -readconfig q35-virtio-graphical.cfg \ +# -device scsi-hd,bus=scsi.0,drive=disk \ +# -drive file=os.qcow2,format=qcow2,id=disk,if=none +# +# Or: +# +# $ qemu-system-x86_64 \ +# -nodefaults \ +# -readconfig q35-virtio-common.cfg \ +# -readconfig q35-virtio-graphical.cfg \ +# -cdrom live.iso +# +# --------------------------------------------------------- +# +# This file contains a working configuration that can be +# used for booting a generic q35 guest without too much +# fuss, or as a starting point for a more fine-tuned +# configuration. The guest in question will be accessed +# using a graphical console. +# +# Using -nodefaults is required to avoid duplicated +# devices and conflicting address assignments; all devices +# that are added by this file are explained in detail +# below. + + +# SCSI controller +# ========================================================= +# +# We use virtio-scsi here so that we can (hot)plug a large +# number of disks without running into issues. QEMU will +# automatically plug any guest disk into this controller. + +[device "scsi"] + driver = "virtio-scsi-pci" + bus = "pci.1" + addr = "0x0" + + +# Network interface +# ========================================================= +# +# 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 = "0x0" + + +# 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 = "0x0" + +[device "tablet"] + driver = "usb-tablet" + bus = "usb.0" + port = "2" + + +# 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" + + +# Sound card +# ========================================================= +# +# Like the video card, the sound card is a legacy PCI +# device and as such can be plugged directly into the PCIe +# 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..9ab3958 --- /dev/null +++ b/docs/q35-virtio-serial.cfg @@ -0,0 +1,80 @@ +# q35 - VirtIO guest (serial console) +# ========================================================= +# +# Usage: +# +# $ qemu-system-x86_64 \ +# -nographic -nodefaults \ +# -readconfig q35-virtio-common.cfg \ +# -readconfig q35-virtio-serial.cfg \ +# -device scsi-hd,bus=scsi.0,drive=disk \ +# -drive file=os.qcow2,format=qcow2,id=disk,if=none +# +# Or: +# +# $ qemu-system-x86_64 \ +# -nographic -nodefaults \ +# -readconfig q35-virtio-common.cfg \ +# -readconfig q35-virtio-serial.cfg \ +# -cdrom live.iso +# +# --------------------------------------------------------- +# +# This file contains a working configuration that can be +# used for booting a generic q35 guest without too much +# fuss, or as a starting point for a more fine-tuned +# configuration. The guest in question will be accessed +# using the serial console. +# +# Using -nodefaults is required to avoid duplicated +# devices and conflicting address assignments; all devices +# that are added by this file are explained in detail +# below. + + +# SCSI controller +# ========================================================= +# +# We use virtio-scsi here so that we can (hot)plug a large +# number of disks without running into issues. QEMU will +# automatically plug any guest disk into this controller. + +[device "scsi"] + driver = "virtio-scsi-pci" + bus = "pci.1" + addr = "0x0" + + +# Network interface +# ========================================================= +# +# 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 = "0x0" + + +# Serial console +# ========================================================= +# +# This provides access to the guest via the host's standard +# input / output channel, eg. 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. + +[chardev "console"] + backend = "stdio" + +[device "serial"] + driver = "isa-serial" + chardev = "console"
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 [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. The last part seems to clash with some of Gerd's comments, so I'm kinda puzzled. [v1] http://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg06342.html docs/q35-chipset.cfg | 152 -------------------------------- docs/q35-emulated.cfg | 196 ++++++++++++++++++++++++++++++++++++++++++ docs/q35-virtio-common.cfg | 82 ++++++++++++++++++ docs/q35-virtio-graphical.cfg | 113 ++++++++++++++++++++++++ docs/q35-virtio-serial.cfg | 80 +++++++++++++++++ 5 files changed, 471 insertions(+), 152 deletions(-) delete mode 100644 docs/q35-chipset.cfg create mode 100644 docs/q35-emulated.cfg create mode 100644 docs/q35-virtio-common.cfg create mode 100644 docs/q35-virtio-graphical.cfg create mode 100644 docs/q35-virtio-serial.cfg