[Qemu-devel] Re: [PATCH 0/5] Add "info capabilities" monitor command

[Anthony Liguori]

Mark McLoughlin wrote:
> Hi,
>
> Management tools need to be able to handle different versions of qemu
> equally well. Such a tool might need to know whether a given version
> supports a recently added command line option, whether it was built
> with kqemu support or who many vcpus is allowed.
>
> One example of this is libvirt which does "qemu -help" and looks at
> the version string and which command line options are included in
> the output. That's a hack that works pretty well, but clearly
> "qemu -help" shouldn't be considered a stable interface.
>
> This came up recently in the context of GSO support the KVM virtio
> network device. Essentially, libvirt needs to know whether qemu will
> be able to handle a tapfd with the IFF_VNET_HDR flag set. Adding
> something about IFF_VNET_HDR to the -help output was rejected as
> taking an ugly hack way too far :-)
>
> The proposed solution is to add a new monitor command which will
> list exactly what this qemu binary is capable of. Rather than include
> every possible capability, I've limited it to:
>
>   1) New features; if a version of qemu supports the capabilities
>      info command, you can assume that it also supports features
>      that were added before that.
>
>   2) Compile time configurables which affect what features can be
>      requested on the command line - e.g. kqemu support
>
>   3) Magic numbers; a managment tool might know that qemu only
>      supports 2 IDE devices - and that may never change - but
>      it's much nicer if the tool can be coded generically rather
>      than hardcoding a magic number.
>
> The patch implementing this isn't perfect by any means, but since
> this could be implemented in so many different ways I thought I'd
> post it and get people's feedback.
>
> Cheers,
> Mark.
>
> Example output:
>   

There are really two types of features/options in QEMU.  There are 
features/options of the emulated hardware and there are features/options 
for how we present this hardware to the user.  The former is guest 
visible and part of the save/restore state whereas the later is 
transparent to the guest.

When enumerating capabilities, there really ought to be a clean split 
between the two.  The former should just describe the variety of 
hardware that can be presented to the guest.  This is important for 
determining things like whether a migration target's QEMU instance is 
compatible with the source.

With respect to limits, there are two types of limits.  There are 
architectural limits of the emulated hardware which are intrinsic to the 
hardware and vary for every machine.  Then there are the stupid QEMU 
limits.  The stupid QEMU limits should always be high enough such that 
it is greater than the architectural limits of any possible emulated 
hardware.  If not, that is a bug and should be fixed.

So there really is no need to expose limits because they have very 
little relationship to reality.  The stupid QEMU limits should 
effectively be infinite.  You need to look at the machine definition to 
determine what the real limits of the machine type are.  I don't 
necessarily think this should be explicitly described by QEMU either.  I 
don't mind a management tool having to be smart enough to know that an 
IDE controller can only support 4 disks.

As a general piece of advise, I think where you are starting from is a 
bit ambitious and far too open for bike shedding to be productive.  You 
may find it easier to start with something simpler, that has a real 
practical utility to libvirt, and then building on that incrementally.

Regards,

Anthony Liguori