[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
Re: [Qemu-devel] [RFC for 2.7 0/2] virtio: show guest features in 'info qtree'
Wed, 11 May 2016 14:02:43 +0200
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.
Re: [Qemu-devel] [RFC for 2.7 0/2] virtio: show guest features in 'info qtree', Denis V. Lunev, 2016/05/11