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

On Wed, 2017-02-08 at 19:36 +0000, Peter Maydell wrote:
> > When -nodefaults is missing, a default virtio-net-pci
> > plugged into 00:01.0 is automatically added.
> 
> Ah, right, default -net commands. Is that it?

I believe so, but double checking is never the wrong thing
to do ;)

> > On the other hand, I just realized that I can add
> > 
> >   [machine]
> >     graphics = "off"
> > 
> > to get rid of -nographic on the command line! \o/

... and after writing this, I actually tested it and
realized that it doesn't quite do what I want it to :(

> -nographic is kind of odd if you're taking the
> "use -nodefaults and specify everything manually"
> because it wraps up a whole pile of default config
> in one oddball legacy config switch. I would have
> expected -display none and whatever other options
> you wanted.

-nographic is just what libvirt uses: if there's a better
way to achieve the same result then I'm all for it!

Seems like '-display none' behaves the same as -nographic,
at least for my purposes. Unfortunately I still can't have
it inside the configuration file, it has to be on the
command line :(

[...]
> > Moreover, something that I haven't been able to do on
> > mach-virt (even though I could on q35, but again, I want the
> > files to be as close as possible) is to configure the serial
> > console from the configuration file.
> 
> If there's stuff we can fix in the virt board to make
> this work the way it does on the PC model I'm happy
> to make fixes to help.

Well, with a q35 guest I can just add

  [chardev "hostconsole"]
    backend = "stdio"

  [device "console"]
    driver = "isa-serial"
    chardev = "hostconsole"

to the configuration file and get the same behavior I would
get by adding '-serial stdio' to the command line, but I
haven't been able to find any device that I can use the same
way as isa-serial on mach-virt. Maybe I just missed it?

[...]
> The trouble with using virtconsole is that you have to
> get quite a long way forward (probing and setting up
> PCI, etc) before you can get any kind of console output.
> "System doesn't boot and doesn't produce any output"
> is a common and really annoying failure mode in the
> ARM world, and I think that using virtconsole is
> asking for that kind of thing to happen more rather
> than less often. (Plus having two different serial
> ports in the guest means that now the user has to
> configure where both of them are supposed to output.)

You don't get one unless you use '-serial stdio' or
something like that in my experience, so if you use the
sample configuration file as I posted it you will only
get one serial console, the VirtIO-based one.

I agree though that the lack of boot output and especially
GRUB menu access in virtconsole is less then ideal, because
even though the users will eventually get a login prompt,
the first few seconds without any output at all might lead
them to believe the guest is not working properly.

I just wish there were a way to add the default serial
console straight from the configuration file...

-- 
Andrea Bolognani / Red Hat / Virtualization

  parent reply	other threads:[~2017-02-09 13:53 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 [this message]
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
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=1486648432.3641.43.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).