On 8 February 2017 at 19:28, Andrea Bolognani <[email protected]> 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
