All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Dakinevich <jan.dakinevich@virtuozzo.com>
To: qemu-devel@nongnu.org
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>,
	"Denis V. Lunev" <den@virtuozzo.com>,
	Cornelia Huck <cohuck@redhat.com>, Max Reitz <mreitz@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [RFC v5 0/2] virtio: introduce `info virtio' hmp command
Date: Tue, 12 Dec 2017 16:54:50 +0300	[thread overview]
Message-ID: <20171212165450.6b6e823f@virtuozzo.com> (raw)
In-Reply-To: <1508867404-18046-1-git-send-email-jan.dakinevich@virtuozzo.com>

I am going to reanimate works under this QMP/HMP. First of all, it
could be meaningful to settle what output would provide the QMP. I would
like to suggest the following description:

##
# @VirtioFeature:
##
{
    'struct': 'VirtioFeature',
    'data': {
        'name': 'str',
        'acked': 'bool'
    }
}

##
# @VirtioInfo:
##
{
    'struct': 'VirtioInfo',
    'data': {
        'qom-path': 'str',
        
        'status': 'uint8',
        'host-features': 'uint64',
        'guest-features': 'uint64',

        'status-names': ['str'],
        'common-features-names': ['VirtioFeature'],
        'device-features-names': ['VirtioFeature']
    }
}

##
# @query-virtio:
##
{
    'command': 'query-virtio',
    'data': {'*path': 'str'},
    'returns': ['VirtioInfo']
}

My final goal is to implement HMP which will print all exposed virtio
features (both common and device-specific) with their acknowledgements,
and virtio device configuration status. These are provided by last 3
fields in @VirtioInfo.

For these who are going make own decision on features and status
bitmask, respective fields with raw values are preserved.

So, I expect following data on the wire in response to `query-virtio'
command:

{
    "return": [
        {
            "qom-path": "/machine/peripheral-anon/device[0]/virtio-backend", "status": 15,
            "host-features": 6325010438,
            "guest-features": 5100273670,
            "status-names": [
                "acknowledge", 
                "driver", 
                "driver-ok", 
                "features-ok"
            ],
            "common-features-names": [
                {"name": "notify-on-empty", "acked": false},
                {"name": "any-layout", "acked": false},
                {"name": "indirect-desc", "acked": true},
                {"name": "event-idx", "acked": true},
                {"name": "bad-feature", "acked": false},
                {"name": "version-1", "acked": true}
            ],
            "device-features-names": [
                {"name": "hotplug", "acked": true},
                {"name": "change", "acked": true}
            ]
        }
    ]
}


Eric Blake, returning to your question which would probably appear again
after this mail:

>> +##
>> +# @query-virtio:
>> ...
>> +##
>> +{
>> +    'command': 'query-virtio',
>> +    'data': { '*path': 'str' },  
>
> Do we need filterable queries, or is it better to just have the
> command return info on all virtio devices at once and let the client
> filter the results as desired?

I think it would be better to do here. I suppose, the client which uses
HMP will not be happy on filtering monitor output.

-- 
Best regards
Jan Dakinevich

  parent reply	other threads:[~2017-12-12 13:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-24 17:50 [Qemu-devel] [RFC v5 0/2] virtio: introduce `info virtio' hmp command Jan Dakinevich
2017-10-24 17:50 ` [Qemu-devel] [RFC v5 1/2] virtio: introduce `query-virtio' QMP command Jan Dakinevich
2017-11-02 18:52   ` Eric Blake
2017-10-24 17:50 ` [Qemu-devel] [RFC v5 2/2] virtio: add `info virtio' HMP command Jan Dakinevich
2017-12-12 13:54 ` Jan Dakinevich [this message]
2017-12-14 11:05   ` [Qemu-devel] [RFC v5 0/2] virtio: introduce `info virtio' hmp command Cornelia Huck
2017-12-14 21:06     ` Jan Dakinevich
2017-12-15 14:41       ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171212165450.6b6e823f@virtuozzo.com \
    --to=jan.dakinevich@virtuozzo.com \
    --cc=armbru@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.