On 02/08/17 20:28, Andrea Bolognani 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. > >> There doesn't seem to be any specification of the GIC >> version (unless I missed it in the config file); you >> probably want -machine gic-version=host if you're using >> -cpu host. > > Very good point! I've added it. > > I would really, really like to be able to specify the > CPU model in the configuration file as well, but I haven't > found a way to do so :( > > On the other hand, I just realized that I can add > > [machine] > graphics = "off" > > to get rid of -nographic on the command line! \o/ > >>> +# Using -nodefaults is required to have full control over >>> +# the virtual hardware: when it's specified, QEMU will >>> +# create a bare machine with just the very essential >>> +# chipset devices being present: >> >> The theory of 'virt' is it only has the essential >> devices anyway. > > See above ;) > > The use of -nodefaults is there mostly to guarantee that we > always start from a clean slate, like for example add the > Ethernet adapter ourselves (giving us a chance to comment > on its usage) instead of using the default one. > > Another goal is to be consistent with the q35 sample > configuration files: ideally comparing mach-virt-serial.cfg > and q35-virtio-serial.cfg, for example, should yield a > very minimal diff. > >>> +# 00:00.0 Host bridge >> >> I'm pretty sure -nodefaults isn't going to disable >> the GIC, the UART, the flash devices, etc etc that >> the virt board has. Not everything in the world is >> a PCI device :-) > > Right. So far I've basically stuck with PCI devices: even > the device listing, as you can see, is modeled after the > output of lspci. > > That said, I'm not against documenting more devices. > > [...] >> It's a shame that we've ended up with different >> firmware names (even between RHEL and Fedora, without >> getting to Debian or SUSE). > > Yeah, it's pretty unfortunate :( > >> Would making UEFI a >> more "official" rom image in pc-bios/ help to >> harmonise things, or just introduce yet another >> possibility to the mix? > > Sorry, no idea. I'll let someone else comment on this one. > > [...] >>> +[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.
If you care about firmware logs, or early guest kernel logs, from aarch64 guests, you absolutely need a PL011 UART. > > 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. What do you mean by "configure the serial console"? Thanks Laszlo > > 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. > > -- > Andrea Bolognani / Red Hat / Virtualization >