Re: [PATCH v4 0/3] Adjust the output of x-query-virtio-status

[Markus Armbruster <armbru@redhat.com>]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Wed, Mar 13, 2024 at 10:40:21AM +0100, Markus Armbruster wrote:
>> I could be awkward for the use case described in PATCH 1's commit
>> message:
>> 
>>     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.
>
> So, consider how guest kernel presents features then. Do you happen to know?
> It's actually a binary string:
>
> static ssize_t features_show(struct device *_d,
>                              struct device_attribute *attr, char *buf)
> {
>         struct virtio_device *dev = dev_to_virtio(_d);
>         unsigned int i;
>         ssize_t len = 0;
>
>         /* We actually represent this as a bitstring, as it could be
>          * arbitrary length in future. */
>         for (i = 0; i < sizeof(dev->features)*8; i++)
>                 len += sysfs_emit_at(buf, len, "%c",
>                                __virtio_test_bit(dev, i) ? '1' : '0');
>         len += sysfs_emit_at(buf, len, "\n");
>         return len;
> }
> static DEVICE_ATTR_RO(features);

I'm willing to accept any reasonably compact representation of the bits
that is easy to use for the comparison use case.

I strongly prefer integers as long as their width suffices.

Since out integers are limited to 64 bits, and you want us to design for
more, we need something else.

I'm fine with array of integers, but you don't like it.

We generally avoid encoding stuff in strings, but using strings for
"overwide" integers isn't as bad as using them for structured data.  I
guess I'd be okay with it.

I'd use decimal simply to keep these "overwide" integers as close as
possible to regular ones.

If using base 2 enables string compare for the comparison use case,
that's an argument for base 2.

Hyman Huang, can you show us example output of "ovs-vsctl list
interface"?