On Wed, Feb 27, 2019 at 03:25:25PM +0000, Daniel P. Berrangé wrote:
> On Wed, Feb 27, 2019 at 03:15:35PM +0000, Stefan Hajnoczi wrote:
> > On Tue, Feb 26, 2019 at 10:09:19AM +0100, Markus Armbruster wrote:
> > > Stefan Hajnoczi <stefanha@redhat.com> 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 <stefanha@redhat.com> 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.
> 
> This assumption is probably going to be more troublesome in future. It
> is increasingly common to deploy libvirt & QEMU inside docker containers,
> and there's not a strict requirement that the docker container image
> is the same distro / version as the docker host. ie a Fedora docker
> image could be run on a RHEL host & vica-verca. IOW we could see an older

Off-topic, the standard spelling seems to be "vice versa".  Is this a
typo or another accepted spelling?

> kernel than what we compiled on. I don't know how common such mismatches
> will be in practice, but at the Docker level there's nothing preventing
> such mismatches, which means some people will inevitably end up running
> in such scenarios whether we like it or not. 

Good point.

Peter's suggestion for a cacheable flag sounds useful.  I can propose
that in the next revision.

Stefan