qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Bolognani <abologna@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 2/2] mach-virt: Provide sample configuration files
Date: Thu, 09 Feb 2017 16:10:43 +0100	[thread overview]
Message-ID: <1486653043.3641.47.camel@redhat.com> (raw)
In-Reply-To: <20170209122819.ajgatpsnxj7cdjq2@kamzik.brq.redhat.com>

On Thu, 2017-02-09 at 13:28 +0100, Andrew Jones wrote:
> > Please keep in mind that I want to be able
> > to use the very same paragraph both for q35 and mach-virt.
> 
> I'm not sure having the exact same paragraph is a reasonable
> goal.

If not the exact same, there is no reason for it not to
be at least 90% shareable IMHO.

> Does q35 have platform devices like mach-virt?

I don't know. And I'm not sure we need to talk about them
or their aarch64 counterparts at all in the sample
configuration file, because AFAIK with the exception of the
GIC version they are not user configurable, or at the very
least not something the user will actively want to
configure (correct me if I'm wrong).

> The
> devices we get on a 'qemu -nodefaults -machine virt' instance
> are MMIO driven devices on the board, rather than devices
> hung off the pcie host bridge.

We want people to use PCIe instead of MMIO, though, so
again why should we even mention those?

It's just a sample configuration file we're talking about,
not a complete reference of the aarch64 architecture, so
it's entirely okay to skimp on details that don't directly
impact most users and be opinionated.

> Perhaps we can list the uart as an example; I don't suppose
> it'll ever be removed. If we use wording such as "such as",
> then it allows expansion to the board without a commitment to
> update the list.
> 
> BTW, when I stated "-nodefaults provides us a base mach-virt
> board with no peripherals.", I meant no _additional_
> peripherals plugged into the board's virtio-mmio transports,
> nor hung off the host bridge. Is there a word for those?
> Maybe just non-builtin peripherals?

Please propose the alternative wording you'd like to see
so we can discuss it :)

-- 
Andrea Bolognani / Red Hat / Virtualization

  parent reply	other threads:[~2017-02-09 15:10 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-08 17:35 [Qemu-devel] [PATCH v5 0/2] docs: Improve sample configuration files Andrea Bolognani
2017-02-08 17:35 ` [Qemu-devel] [PATCH v5 1/2] q35: " Andrea Bolognani
2017-02-08 17:35 ` [Qemu-devel] [PATCH v5 2/2] mach-virt: Provide " Andrea Bolognani
2017-02-08 18:11   ` Laszlo Ersek
2017-02-08 18:49     ` Andrea Bolognani
2017-02-08 19:34       ` Laszlo Ersek
2017-02-08 19:47         ` Andrea Bolognani
2017-02-09  9:49     ` Andrew Jones
2017-02-09 10:52       ` Andrea Bolognani
2017-02-08 18:32   ` Peter Maydell
2017-02-08 19:23     ` Laszlo Ersek
2017-02-08 19:40       ` Peter Maydell
2017-02-08 19:28     ` Andrea Bolognani
2017-02-08 19:36       ` Peter Maydell
2017-02-08 19:49         ` Laszlo Ersek
2017-02-09 13:53         ` Andrea Bolognani
2017-02-09 14:14           ` Andrew Jones
2017-02-08 19:36       ` Laszlo Ersek
2017-02-09  9:42   ` Andrew Jones
2017-02-09  9:57     ` Peter Maydell
2017-02-09 10:51       ` Andrea Bolognani
2017-02-09 12:28         ` Andrew Jones
2017-02-09 13:27           ` Andrea Bolognani
2017-02-09 14:08             ` Andrew Jones
2017-02-09 14:56               ` Andrea Bolognani
2017-02-09 15:26                 ` Gerd Hoffmann
2017-02-09 15:10           ` Andrea Bolognani [this message]
2017-02-09 15:35             ` Andrew Jones
2017-02-09 16:11               ` Andrea Bolognani
2017-02-09 16:36                 ` Andrew Jones
2017-02-09 17:06                   ` Andrea Bolognani
2017-02-09 18:05                     ` Andrew Jones

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=1486653043.3641.47.camel@redhat.com \
    --to=abologna@redhat.com \
    --cc=drjones@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=marcel@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).