From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ePrAr-0008Sr-C3 for qemu-devel@nongnu.org; Fri, 15 Dec 2017 09:41:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ePrAo-0000Q4-6t for qemu-devel@nongnu.org; Fri, 15 Dec 2017 09:41:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58961) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ePrAn-0000No-Tu for qemu-devel@nongnu.org; Fri, 15 Dec 2017 09:41:14 -0500 Date: Fri, 15 Dec 2017 15:41:01 +0100 From: Cornelia Huck Message-ID: <20171215154101.00550c4a.cohuck@redhat.com> In-Reply-To: <20171215000606.382a3ce7@virtuozzo.com> References: <1508867404-18046-1-git-send-email-jan.dakinevich@virtuozzo.com> <20171212165450.6b6e823f@virtuozzo.com> <20171214120519.48edb873.cohuck@redhat.com> <20171215000606.382a3ce7@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v5 0/2] virtio: introduce `info virtio' hmp command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Dakinevich Cc: qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , "Michael S. Tsirkin" , Eric Blake , Markus Armbruster , Kevin Wolf , "Denis V. Lunev" , Max Reitz , Stefan Hajnoczi , Paolo Bonzini On Fri, 15 Dec 2017 00:06:06 +0300 Jan Dakinevich wrote: > On Thu, 14 Dec 2017 12:05:19 +0100 > Cornelia Huck wrote: > > > On Tue, 12 Dec 2017 16:54:50 +0300 > > Jan Dakinevich wrote: > > > > > 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. > > > > Looks sensible. What will you return an for the *-features-names > > fields if the status field indicates that negotiation is not yet done? > > (This has some fun interaction with the VERSION_1 feature bit...) > > > > Hmm... I was going to return current features and theirs > acknowledgments regardless if they were negotiated. Thus, > *-features-names would contain all exposed host features with `false' > in `acked' field. acked=false is probably the most sensible approach. > > > > > > > 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} > > > > I suggest to use the #defines as names, especially as they are also > > used in the spec. Makes grepping easier. > > > > You mean, for example "VIRTIO_RING_F_EVENT_IDX" instead of "event-idx" > should be used. Right? Right, that's what I meant. > > > > ] > > > } > > > ] > > > } > > > > > > > > > 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. > > > > I think being able to optionally specify a path is the most flexible > > solution. > > >