On Mon, Mar 11, 2019 at 12:26:08 -0500, Eric Blake wrote: > On 3/11/19 11:50 AM, Kevin Wolf wrote: > > Until now, with auto-read-only=on we tried to open the file read-write > > first and if that failed, read-only was tried. This is actually not good > > enough for libvirt, which gives QEMU SELinux permissions for read-write > > only as soon as it actually intends to write to the image. So we need to > > be able to switch between read-only and read-write at runtime. > > > > This patch makes auto-read-only dynamic, i.e. the file is opened > > read-only as long as no user of the node has requested write > > permissions, but it is automatically reopened read-write as soon as the > > first writer is attached. Conversely, if the last writer goes away, the > > file is reopened read-only again. > > > > bs->read_only is no longer set for auto-read-only=on files even if the > > file descriptor is opened read-only because it will be transparently > > upgraded as soon as a writer is attached. This changes the output of > > qemu-iotests 232. > > 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.
signature.asc
Description: PGP signature