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

[Laszlo Ersek]

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
>