All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Bolognani <abologna@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, drjones@redhat.com
Subject: Re: [Qemu-devel] [PATCH] q35: Provide improved sample configurations
Date: Wed, 01 Feb 2017 15:09:43 +0100	[thread overview]
Message-ID: <1485958183.3484.13.camel@redhat.com> (raw)
In-Reply-To: <1485894840.1076.45.camel@redhat.com>

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

  parent reply	other threads:[~2017-02-01 14:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-30 15:07 [Qemu-devel] [PATCH] q35: Provide improved sample configurations Andrea Bolognani
2017-01-31 20:34 ` Gerd Hoffmann
2017-01-31 21:03   ` Eric Blake
2017-02-01 14:15     ` Andrea Bolognani
2017-02-01 14:09   ` Andrea Bolognani [this message]
2017-02-01 14:46     ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1485958183.3484.13.camel@redhat.com \
    --to=abologna@redhat.com \
    --cc=drjones@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.