On 3/11/19 2:59 PM, Peter Krempa wrote: >> auto-read-only was introduced in 3.1, at which point we intentionally >> had sufficiently loose wording to permit (but not require) dynamic state >> checking; so you are not breaking the interface. On the other hand, is >> libvirt going to have problems introspecting whether it can use >> auto-read-only and get the dynamic behavior it needs? Or is there >> enough else in the way of libvirt's switch to -blockdev that it won't >> attempt anything that needs auto-read-only without other 4.0 interfaces >> anyway, at which point detecting the presence of the field (but not >> whether the field has a guarantee of dynamic behavior) on 3.1 doesn't >> matter? > > I think we can use Stefan's capability detection mechanism he introduced > for the migration with cache enabled for local files to add a flag for > this as well.
Except I thought we decided that the most recent version of his QMP changes was now fully-introspectible, thanks to using conditional compilation. https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02510.html Well, that may prove to be a short-lived hiatus, if libvirt would happily attempt to use qemu 3.1 and fail without some other introspectible hook to know whether auto-read-only has required semantics. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature