Hyman Huang <yong.hu...@smartx.com> writes: > x-query-virtio-status returns several sets of virtio feature and > status flags. It goes back to v7.2.0. > > In the initial commit 90c066cd682 (qmp: add QMP command > x-query-virtio-status), we returned them as numbers, using virtio's > well-known binary encoding. > > The next commit f3034ad71fc (qmp: decode feature & status bits in > virtio-status) replaced the numbers by objects. The objects represent > bits QEMU knows symbolically, and any unknown bits numerically just like > before. > > Commit 8a8287981d1 (hmp: add virtio commands) the matching HMP command
added the matching HMP command > "info virtio" (and a few more, which aren't relevant here). > > The symbolic representation uses lists of strings. The string format is > undocumented. The strings look like "WELL_KNOWN_SYMBOL: human readable > explanation". > > This symbolic representation is nice for humans. Machines it can save > the trouble of decoding virtio's well-known binary encoding. > > However, we sometimes want to compare features and status bits without > caring for their exact meaning. Say we want to verify the correctness > of the virtio negotiation between guest, QEMU, and OVS-DPDK. We can use > QMP command x-query-virtio-status to retrieve vhost-user net device > features, and the "ovs-vsctl list interface" command to retrieve > interface features. Without commit f3034ad71fc, we could then simply > compare the numbers. With this commit, we first have to map from the > strings back to the numeric encoding. > > Revert the decoding for QMP, but keep it for HMP. > > This makes the QMP command easier to use for use cases where we > don't need to decode, like the comparison above. For use cases > where we need to decode, we replace parsing undocumented strings by > decoding virtio's well-known binary encoding. > > Incompatible change; acceptable because x-query-virtio-status does Scratch "does". > comes without a stability promise. > > Signed-off-by: Hyman Huang <yong.hu...@smartx.com> Acked-by: Markus Armbruster <arm...@redhat.com>
