[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC for 2.7 0/2] virtio: show guest features in 'info

From: Denis V. Lunev
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 05/11/2016 03:02 PM, Cornelia Huck wrote:
On Wed, 11 May 2016 14:06:57 +0300
"Denis V. Lunev" <address@hidden> wrote:

On 05/11/2016 01:34 PM, Cornelia Huck wrote:
On Wed, 11 May 2016 12:52:02 +0300
"Denis V. Lunev" <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]