qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] q35: Provide improved sample configurations


From: Andrea Bolognani
Subject: Re: [Qemu-devel] [PATCH] q35: Provide improved sample configurations
Date: Wed, 01 Feb 2017 15:09:43 +0100

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:
> 
> address@hidden ~# lspci -vt
> -[0000:00]-+-00.0  Intel Corporation 82G33/G31/P35/P31 Express DRAM
> Controller
>            +-02.0  Device 1234:1111
>            +-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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]