From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0VsR-0006b9-IA for qemu-devel@nongnu.org; Wed, 11 May 2016 11:16:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0VsL-0000gy-9C for qemu-devel@nongnu.org; Wed, 11 May 2016 11:16:43 -0400 Received: from mail-am1on0112.outbound.protection.outlook.com ([157.56.112.112]:51398 helo=emea01-am1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0VsJ-0000fM-S3 for qemu-devel@nongnu.org; Wed, 11 May 2016 11:16:37 -0400 References: <1462960324-4655-1-git-send-email-den@openvz.org> <20160511123419.0e96ee16.cornelia.huck@de.ibm.com> <57331251.1080301@openvz.org> <20160511140243.7d0bd86d.cornelia.huck@de.ibm.com> From: "Denis V. Lunev" Message-ID: <57333879.3040509@openvz.org> Date: Wed, 11 May 2016 16:49:45 +0300 MIME-Version: 1.0 In-Reply-To: <20160511140243.7d0bd86d.cornelia.huck@de.ibm.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC for 2.7 0/2] virtio: show guest features in 'info qtree' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" On 05/11/2016 03:02 PM, Cornelia Huck wrote: > On Wed, 11 May 2016 14:06:57 +0300 > "Denis V. Lunev" wrote: > >> On 05/11/2016 01:34 PM, Cornelia Huck wrote: >>> On Wed, 11 May 2016 12:52:02 +0300 >>> "Denis V. Lunev" 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