From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>, "Fam Zheng" <fam@euphon.net>,
"Thomas Huth" <thuth@redhat.com>,
"Michael Roth" <mdroth@linux.vnet.ibm.com>,
qemu-block@nongnu.org, "Amit Shah" <amit@kernel.org>,
"Jason Wang" <jasowang@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
"Eric Auger" <eric.auger@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Max Reitz" <mreitz@redhat.com>
Subject: Re: [RFC v4 6/6] hmp: add x-debug-virtio commands
Date: Fri, 15 May 2020 16:45:06 +0100 [thread overview]
Message-ID: <20200515154506.GC2955@work-vm> (raw)
In-Reply-To: <edc743ad-7e5d-ffc9-c0d0-676e4216386e@redhat.com>
* Laurent Vivier (lvivier@redhat.com) wrote:
> On 13/05/2020 12:51, Dr. David Alan Gilbert wrote:
> > * Laurent Vivier (lvivier@redhat.com) wrote:
> >> This patch implements HMP version of the virtio QMP commands
> >>
> >> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> >
> > Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> >
> > With a thought below....
> >
> >> ---
> >> Makefile | 2 +-
> >> Makefile.target | 7 +-
> >> docs/system/monitor.rst | 2 +
> >> hmp-commands-virtio.hx | 160 +++++++++++++++++++++++++++++++++
> >> hmp-commands.hx | 10 +++
> >> hw/virtio/virtio.c | 193 +++++++++++++++++++++++++++++++++++++++-
> >> include/monitor/hmp.h | 4 +
> >> monitor/misc.c | 17 ++++
> >> 8 files changed, 391 insertions(+), 4 deletions(-)
> >> create mode 100644 hmp-commands-virtio.hx
> >>
> ...
> >> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> >> index 66dc2cef1b39..c3d6b783417e 100644
> >> --- a/hw/virtio/virtio.c
> >> +++ b/hw/virtio/virtio.c
> ...
> >> @@ -4033,6 +4092,92 @@ VirtioStatus *qmp_x_debug_virtio_status(const char* path, Error **errp)
> >> return status;
> >> }
> >>
> >> +#define DUMP_FEATURES(type, field) \
> >> + do { \
> >> + type##FeatureList *list = features->device->u.field.data; \
> >> + if (list) { \
> >> + monitor_printf(mon, " "); \
> >> + while (list) { \
> >> + monitor_printf(mon, "%s", type##Feature_str(list->value)); \
> >> + list = list->next; \
> >> + if (list != NULL) { \
> >> + monitor_printf(mon, ", "); \
> >> + } \
> >> + } \
> >> + monitor_printf(mon, "\n"); \
> >> + } \
> >> + } while (0)
> >
> > It feels like you should be able to have an array of Feature_str's
> > indexed by VIRTIO_DEVICE_FEATURE_KIND_ enum, so that when a new
> > VIRTIO_DEVICE_FEATURE_KIND is added you don't need to fix this up.
>
> I don't understand what you mean here.
Instead of the switch below, I'm thinking you could have something like:
if (features->device->type < something_MAX) {
features_str = anarray[features->device->type];
....
monitor_printf(mon, "%s", features_str(list->value));
....
}
with 'anarray' somewhere more central, so we don't have to keep
these switch structures and macros spread around.
Dave
> >> +
> >> +static void hmp_virtio_dump_features(Monitor *mon,
> >> + VirtioStatusFeatures *features)
> >> +{
> >> + VirtioTransportFeatureList *transport_list = features->transport;
> >> + while (transport_list) {
> >> + monitor_printf(mon, "%s",
> >> + VirtioTransportFeature_str(transport_list->value));
> >> + transport_list = transport_list->next;
> >> + if (transport_list != NULL) {
> >> + monitor_printf(mon, ", ");
> >> + }
> >> + }
> >> + monitor_printf(mon, "\n");
> >> + switch (features->device->type) {
> >> + case VIRTIO_DEVICE_FEATURES_KIND_VIRTIO_SERIAL:
> >> + DUMP_FEATURES(VirtioSerial, virtio_serial);
> >> + break;
> >> + case VIRTIO_DEVICE_FEATURES_KIND_VIRTIO_BLK:
> >> + DUMP_FEATURES(VirtioBlk, virtio_blk);
> >> + break;
> >> + case VIRTIO_DEVICE_FEATURES_KIND_VIRTIO_GPU:
> >> + DUMP_FEATURES(VirtioGpu, virtio_gpu);
> >> + break;
> >> + case VIRTIO_DEVICE_FEATURES_KIND_VIRTIO_NET:
> >> + DUMP_FEATURES(VirtioNet, virtio_net);
> >> + break;
> >> + case VIRTIO_DEVICE_FEATURES_KIND_VIRTIO_SCSI:
> >> + DUMP_FEATURES(VirtioScsi, virtio_scsi);
> >> + break;
> >> + case VIRTIO_DEVICE_FEATURES_KIND_VIRTIO_BALLOON:
> >> + DUMP_FEATURES(VirtioBalloon, virtio_balloon);
> >> + break;
> >> + case VIRTIO_DEVICE_FEATURES_KIND_VIRTIO_IOMMU:
> >> + DUMP_FEATURES(VirtioIommu, virtio_iommu);
> >> + break;
> >> + default:
> >> + g_assert_not_reached();
> >> + }
> >> + if (features->unknown) {
> >> + monitor_printf(mon, " unknown(0x%016"PRIx64")\n", \
> >> + features->unknown);
> >> + }
> >> +}
> ...
>
> Thanks,
> Laurent
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2020-05-15 15:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 13:47 [RFC v4 0/6] hmp,qmp: Add some commands to introspect virtio devices Laurent Vivier
2020-05-07 13:47 ` [RFC v4 1/6] qmp: add QMP command x-debug-query-virtio Laurent Vivier
2020-05-07 13:47 ` [RFC v4 2/6] qmp: add QMP command x-debug-virtio-status Laurent Vivier
2020-05-07 13:47 ` [RFC v4 3/6] qmp: decode feature bits in virtio-status Laurent Vivier
2020-05-07 13:47 ` [RFC v4 4/6] qmp: add QMP command x-debug-virtio-queue-status Laurent Vivier
2020-05-07 13:47 ` [RFC v4 5/6] qmp: add QMP command x-debug-virtio-queue-element Laurent Vivier
2020-05-07 13:48 ` [RFC v4 6/6] hmp: add x-debug-virtio commands Laurent Vivier
2020-05-13 10:51 ` Dr. David Alan Gilbert
2020-05-15 15:20 ` Laurent Vivier
2020-05-15 15:45 ` Dr. David Alan Gilbert [this message]
2020-05-15 15:57 ` Laurent Vivier
2020-05-07 20:11 ` [RFC v4 0/6] hmp, qmp: Add some commands to introspect virtio devices no-reply
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=20200515154506.GC2955@work-vm \
--to=dgilbert@redhat.com \
--cc=amit@kernel.org \
--cc=armbru@redhat.com \
--cc=david@redhat.com \
--cc=eric.auger@redhat.com \
--cc=fam@euphon.net \
--cc=jasowang@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.