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

[Mark McLoughlin <markmc@redhat.com>]

On Thu, 2008-11-13 at 21:28 -0600, Anthony Liguori wrote:

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

I dig the distinction - but I'm not sure it's all that helpful.

e.g. the drive cache options are example of features which aren't
visible to the guest, but if you go to migrate a guest using
cache=writethrough and discover the target host doesn't support that,
then presumably you don't proceed. Which is similar to not migrating a
virtio using guest to a host without virtio support.

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

Fair enough, we can drop the limits stuff.

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

Certainly in favour of that. I've very little in the way of strong
opinions on this thing, except to advertise IFF_VNET_HDR :-)

Any suggestions on what the minimal starting point should be?

Cheers,
Mark.