From: "Denis V. Lunev" <den@openvz.org>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [RFC for 2.7 0/2] virtio: show guest features in 'info qtree'
Date: Wed, 11 May 2016 16:49:45 +0300 [thread overview]
Message-ID: <57333879.3040509@openvz.org> (raw)
In-Reply-To: <20160511140243.7d0bd86d.cornelia.huck@de.ibm.com>
On 05/11/2016 03:02 PM, Cornelia Huck wrote:
> On Wed, 11 May 2016 14:06:57 +0300
> "Denis V. Lunev" <den@openvz.org> wrote:
>
>> On 05/11/2016 01:34 PM, Cornelia Huck wrote:
>>> On Wed, 11 May 2016 12:52:02 +0300
>>> "Denis V. Lunev" <den@openvz.org> wrote:
>>>
>>>> It is very convinient and useful for debug purpose to expose the set of
>>>> features negotiated with guest. The patch exports those features via
>>>> read-only bit properties.
>>> I agree that it would be very helpful to be able to access the
>>> negotiated features via the monitor, but I disagree with your approach,
>>> especially the need to expose every single feature bit via a property.
>>>
>>> What about a command like 'info virtio' instead? This would allow us to
>>> dump not only guest features, but the host features initially offered
>>> alongside them and things like the status byte (so you can actually
>>> check whether feature negotiation was successful). Maybe similar to
>>> 'info block'.
>>>
>> Hmmm. Do you propose to print bits as HEX?
> Just print a 1 if the bit is set. This would make it easy to see if
> e.g. the guest only negotiated a small subset of the offered features.
>
>> Because if we are going
>> have then splitted out we have to provide individual bit descriptions.
>> Thus the amount of code could be similar.
>>
>> Actually I can add generic dump code into VirtIODevice and will use
>> host_features/guest_features fields but we should have a callback
>> defined for each device which will provide bit names.
> What about the individual drivers providing an array of strings for the
> feature names? Then you could easily print a list of feature bit names.
>
> For the virtio status (which I would find as useful as the feature
> bits), it's even easier as the status bits are common.
>
OK. We could try this approach.
Do you know any reasonable way to enumerate all VirtIO devices?
There is no need for this in the older code. We will need to enumerate
all VirtIO devices within 'info virtio' command.
Den
next prev parent reply other threads:[~2016-05-11 15:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-11 9:52 [Qemu-devel] [RFC for 2.7 0/2] virtio: show guest features in 'info qtree' Denis V. Lunev
2016-05-11 9:52 ` [Qemu-devel] [RFC 1/2] qdev: add read-only bit/bit64 property Denis V. Lunev
2016-05-11 9:52 ` [Qemu-devel] [RFC 2/2] virtio: show features acked by guest in 'info qtree' dump Denis V. Lunev
2016-05-11 17:24 ` Michael S. Tsirkin
2016-05-11 10:34 ` [Qemu-devel] [RFC for 2.7 0/2] virtio: show guest features in 'info qtree' Cornelia Huck
2016-05-11 11:06 ` Denis V. Lunev
2016-05-11 12:02 ` Cornelia Huck
2016-05-11 13:49 ` Denis V. Lunev [this message]
2016-05-11 14:27 ` Cornelia Huck
2016-05-11 10:39 ` Denis V. Lunev
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=57333879.3040509@openvz.org \
--to=den@openvz.org \
--cc=cornelia.huck@de.ibm.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).