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

[Andrew Jones]

On Thu, Feb 09, 2017 at 02:27:45PM +0100, Andrea Bolognani wrote:
> 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.

OK, if that's the consensus on how they should be used, then
that's fine by me. I've actually never used files like these,
but I was imagining they'd be great to use like this

 qemu -nodefaults -readconfig configfile -more -params \
      -that -may -override -stuff -in -the -configfile

Actually, I don't think anything is stopping me from using this
file that way. I'll have to try the file name override that I
suggested below, but

 qemu -nodefaults -readconfig configfile -m $MEM -machine accel=tcg

should certainly override correctly.

> 
> [...]
> > > +[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?

Sorry, dunno :-)

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

I agree.

Thanks,
drew