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

[Andrea Bolognani]

On Thu, 2017-02-09 at 10:42 +0100, Andrew Jones wrote:
> > +[machine]
> > +  type = "virt"
> > +  accel = "kvm"
> > +
> > +[memory]
> > +  size = "1024"
> 
> So I'm not sure about providing this, at least not in this
> config file. I think we should expect the user to provide ram
> size explicitly, as this depends on what they want to do with
> the guest. Even accel is debatable, as many users may want to
> use tcg from their x86 machines.
> 
> How about focusing this config on the PCIe topology and default
> devices? Additional config defaults like accel and ram could
> be added to an additional config, if we want.

Well, this is a sample configuration, not a one-size-fits-all
solution. It's okay for it to be opinionated.

The way I expect this file to be consumed is that people will
copy it over[1] to some location, tweak it to their liking by
adding and removing devices and altering settings such as
memory size, then use it to start a specific guest from that
moment on. When they need another guest, they can make another
copy of the sample and start over.

So the least parameters the user will have to specify outside
of the configuration file, the better. We actually moved *away*
from the idea of including multiple configuration files (one
for the "common" parts such as PCIe controllers, one for other
devices such as the video card as opposed to the serial
console) because it's much easier to have everything in one
place, for usability and for documentation purposes.

It's not a framework, just a decent starting point.

[...]
> > +[drive "aavmf-code"]
> > +  file = "/usr/share/edk2/aarch64/QEMU_EFI.fd"  # CHANGE ME
> > +  format = "raw"
> > +  if = "pflash"
> > +  unit = "0"
> > +  readonly = "on"
> > +
> > +[drive "aavmf-vars"]
> > +  file = "guest_VARS.fd"                        # CHANGE ME
> > +  format = "raw"
> > +  if = "pflash"
> > +  unit = "1"
> 
> The fact these entries need 'CHANGE ME' comments make me think they
> should also be removed from this config and required explicitly,
> or provided by other configs. Perhaps we can create a config for
> each firmware path we know of? Or, is there any way for a user
> to override the file path from the command line? Does
> 
>  -readconfig config -drive id=aavmf-vars,file=new-path
> 
> work? If so, then we can document how CHANGEME's can be easily
> changed without touching the file.

See above.

[...]
> > +# Display controller
> > +# =========================================================
> > +#
> > +# We use virtio-gpu because the legacy VGA framebuffer is
> > +# very troublesome on aarch64, and virtio-gpu is the only
> 
> We use virtio-gpu because emulating a legacy VGA framebuffer
> is not possible on AArch64 KVM guests due to unavoidable
> stage1 / stage2 page table cache mode mismatches.
> 
> Or just leave the troublesome comment...

I guess that depends a lot on how low-level we want them
be... Overall, I kept them fairly high-level, not least
because that's pretty much as far my knowledge goes.

In other words, your take on the description is certainly
100% accurate but also 100% flying way over my head ;)

[...]
> I agree with the comments of others that we should be using
> the PL011 instead. We should also set it up such that the
> monitor is multiplexed, so ^C won't terminate the guest and
> ^A will allow us to go to the monitor.

That sounds awesome, how do I actually make it work from
the configuration file though?


[1] Looks like these files are not being installed on the
    system by 'make install'. I'd argue having them in
    /usr/share/doc/qemu/examples would be nice for users.
-- 
Andrea Bolognani / Red Hat / Virtualization