Re: [Qemu-devel] [PATCH] qmp: add query-qemu-capabilities

[Stefan Hajnoczi]

On Tue, Feb 26, 2019 at 10:09:19AM +0100, Markus Armbruster wrote:
> Stefan Hajnoczi <address@hidden> writes:
> > On Mon, Feb 25, 2019 at 10:28:46AM +0100, Peter Krempa wrote:
> >> On Mon, Feb 25, 2019 at 09:50:26 +0100, Markus Armbruster wrote:
> >> > Stefan Hajnoczi <address@hidden> writes:
> >> Other than the above, this is a welcome improvement as I've personally
> >> ran into scenarios where a feature in qemu was fixed but it was
> >> impossible to detect whether given qemu version contains the fix as it
> >> did not have any influence on the QMP schema.
> >
> > I'd like to make things as simpler as possible, but no simpler :).
> >
> > The simplest option is that the advertised features are set in stone at
> > build time (e.g. selected with #ifdef if necessary).  But then we have
> > no way of selecting features at runtime (e.g. based on kernel features).
> >
> > What do you think?
> 
> I think we should map the problem space, identify cases with actual
> uses, then design a solution that covers them and can plausibly grow to
> cover cases we anticipate.
> 
> The migrate-with-cache-direct-off-on-linux case is compile-time static.
> 
> Do we have or have we had a case that is not compile-time static?

I can't think of something that both requires query-qemu-features and
isn't compile-time static.  But that could be because not many things
require query-qemu-features :).

The philosophy on Linux seems to be: distros compile QEMU against
headers that accurately reflect the system features that are available.
Therefore there isn't a lot of runtime fallback logic in case a new QEMU
is running on an old host.  This means we can get by with compile-time
static features only.

One possible exception is the ENOSYS/ENOTSUP fallback code in
block/file-posix.c:handle_aiocb_write_zeroes() and
handle_aiocb_copy_range().

Stefan

signature.asc
Description: PGP signature