qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 2/2] mach-virt: Provide sample configuration


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v5 2/2] mach-virt: Provide sample configuration files
Date: Wed, 8 Feb 2017 19:36:11 +0000

On 8 February 2017 at 19:28, Andrea Bolognani <address@hidden> wrote:
> On Wed, 2017-02-08 at 18:32 +0000, Peter Maydell wrote:
>> What does nodefaults disable on the virt board?
>> (I've never looked into exactly what nodefaults does...)
>
> 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?

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

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

> [...]
>> > +[device "console"]
>> > +  driver = "virtconsole"
>> > +  chardev = "hostconsole"
>>
>> Won't most guests expect serial to be the default
>> PL011 UART ?
>
> Possibly. I'm using virtconsole here (and in q35*serial.cfg)
> mostly to have as much VirtIO as possible, but I also
> document the fact that you might want or need to use the
> native serial console instead.
>
> 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.

> Seeing as we have an alternative, I'd rather keep it this
> way and minimize the number of command line arguments the
> user needs to specify.

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.)

thanks
-- PMM



reply via email to

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