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? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
