On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote: > Christophe de Dinechin <dinec...@redhat.com> writes: > > > Thanks a bunch. This clarifies a number of my misconceptions about > > how this is currently used. Most notably this one: > > > >> On 15 Jan 2020, at 10:20, Markus Armbruster <arm...@redhat.com> wrote: > >> > >>> We don’t want the QAPI to let arbitrary fields of a QOM object > >>> be modified, do we? > >> > >> We already do: QMP command qom-set. If it breaks your guest, you get to > >> keep the pieces. > > > > Ouch. I certainly did not expect that. > > > > "It is not what you don’t know that kills you, it is what you know that > > ain’t so". > > Do we have a legitimate use for qom-set right now? Hmm, let's check > libvirt... aha: > > * qemuMonitorJSONSetMemoryStatsPeriod() uses it to control > virtio-balloon's guest-stats-polling-interval property, in accordance > with docs/virtio-balloon-stats.txt. > > * qemuMonitorJSONSetIOThread() uses it to control iothread's properties > poll-max-ns, poll-grow, poll-shrink. Their use with -object is > documented (in qemu-options.hx), their use with qom-set is not. > > Oh well.
Libvirt is of course happy to switch to something else instead of qom-set for these features if QEMU wants to provide a safer alternative. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
