From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
qemu-devel@nongnu.org, "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Gerd Hoffmann" <kraxel@redhat.com>,
Laurent@vivier.eu
Subject: Re: [PATCH 08/11] mos6522: add "info via" HMP command for debugging
Date: Tue, 8 Feb 2022 10:29:09 +0000 [thread overview]
Message-ID: <YgJF9SDwb93k5/fg@work-vm> (raw)
In-Reply-To: <877da5wzgp.fsf@pond.sub.org>
* Markus Armbruster (armbru@redhat.com) wrote:
> Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
>
> > On 7/2/22 20:34, Peter Maydell wrote:
> >> On Thu, 27 Jan 2022 at 21:03, Mark Cave-Ayland
> >> <mark.cave-ayland@ilande.co.uk> wrote:
> >>>
> >>> This displays detailed information about the device registers and timers to aid
> >>> debugging problems with timers and interrupts.
> >>>
> >>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> >>> ---
> >>> hmp-commands-info.hx | 12 ++++++
> >>> hw/misc/mos6522.c | 92 ++++++++++++++++++++++++++++++++++++++++++++
> >>> 2 files changed, 104 insertions(+)
> >>
> >> I'm not sure how keen we are on adding new device-specific
> >> HMP info commands, but it's not my area of expertise. Markus ?
> >
> > HMP is David :)
>
> Yes.
So let me start with an:
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(If it's useful info for the author of the device, then I'm happy for
HMP to have that), but then - (moving the reply around a bit):
> Should this be conditional on the targets where we actually link the
> device, like info skeys?
>
Yes, I think so; it's a reasonably old/obscure device, there's no reason
everyone having it built in.
> > IIRC it is OK as long as HMP is a QMP wrapper.
>
> That's "how to do it", and I'll get back to it in a jiffie, but Peter
> was wondering about the "whether to do it".
>
> Most HMP commands are always there.
>
> We have a few specific to compile-time configurable features: TCG, VNC,
> Spice, Slirp, Linux. Does not apply here.
>
> We have a few specific to targets, such as dump-skeys and info skeys for
> s390. Target-specific is not quite the same as device-specific.
>
> We have no device-specific commands so far. However, dump-skeys and
> info skeys appear to be about the skeys *device*, not the s390 target.
> Perhaps any s390 target has such a device? I don't know. My point is
> we already have device-specific commands, they're just masquerading as
> target-specific commands.
Yeh we've got info lapic/ioapic as well.
> The proposed device-specific command uses a mechanism originally made
> for modules instead (more on that below).
>
> I think we should make up our minds which way we want device-specific
> commands done, then do *all* of them that way.
I think device specific commands make sense, but I think it would
probably be better if we had an 'info dev $name' and that a method on
the device rather than registering each one separately.
I'd assume that this would be a QMP level thing that got unwrapped at
HMP.
But that's not a problem for this contribution; someone else can figure
that out later.
Dave
>
> On to "how to do it", part 1.
>
> Most of the time, the command handler is declared with the command in
> hmp-commands{,-info}.hx, possibly with compile-time conditionals.
>
> But it can also be left null there, and set with monitor_register_hmp()
> or monitor_register_hmp_info_hrt(). This is intended for modules; see
> commit f0e48cbd791^..bca6eb34f03.
>
> Aside: can modules be unloaded? If yes, we better zap the handler
> then.
>
> The proposed "info via" uses monitor_register_hmp_info_hrt(). No
> objection from me, requires David's ACK.
>
>
> "How to do it", part 2, in reply to Philippe's remark.
>
> Ideally, HMP commands wrap around QMP commands, but we accept exceptions
> for certain use cases where the wrapping is more trouble than it's
> worth, with justification. I've explained this several times, and I'm
> happy to dig up a reference or explain it again if there's a need.
>
> Justifying an exception is bothersome, too. Daniel Berrangé recently
> created a way to reduce the wrapping trouble (merge commit
> e86e00a2493). The proposed "info via" makes use of it.
>
> >> (patch below for context)
> >> thanks
> >> -- PMM
> >>
> >>>
> >>> diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> >>> index e90f20a107..4e714e79a2 100644
> >>> --- a/hmp-commands-info.hx
> >>> +++ b/hmp-commands-info.hx
> >>> @@ -879,3 +879,15 @@ SRST
> >>> ``info sgx``
> >>> Show intel SGX information.
> >>> ERST
> >>> +
> >>> + {
> >>> + .name = "via",
> >>> + .args_type = "",
> >>> + .params = "",
> >>> + .help = "show guest 6522 VIA devices",
> >>> + },
> >>> +
> >>> +SRST
> >>> + ``info via``
> >>> + Show guest 6522 VIA devices.
> >>> +ERST
>
> [...]
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2022-02-08 11:07 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 20:53 [PATCH 00/11] mos6522: switch to gpios, add control line edge-triggering and extra debugging Mark Cave-Ayland
2022-01-27 20:53 ` [PATCH 01/11] mos6522: add defines for IFR bit flags Mark Cave-Ayland
2022-01-27 23:16 ` BALATON Zoltan
2022-02-05 10:51 ` Mark Cave-Ayland
2022-02-05 11:16 ` Philippe Mathieu-Daudé via
2022-02-05 12:06 ` BALATON Zoltan
2022-02-20 10:53 ` Mark Cave-Ayland
2022-02-20 19:21 ` BALATON Zoltan
2022-01-27 20:53 ` [PATCH 02/11] mac_via: use IFR bit flag constants for VIA1 IRQs Mark Cave-Ayland
2022-01-27 20:53 ` [PATCH 03/11] mac_via: use IFR bit flag constants for VIA2 IRQs Mark Cave-Ayland
2022-01-27 20:53 ` [PATCH 04/11] mos6522: switch over to use qdev gpios for IRQs Mark Cave-Ayland
2022-02-07 19:29 ` Peter Maydell
2022-02-20 11:01 ` Mark Cave-Ayland
2022-01-27 20:53 ` [PATCH 05/11] mos6522: remove update_irq() and set_sr_int() methods from MOS6522DeviceClass Mark Cave-Ayland
2022-02-07 19:30 ` Peter Maydell
2022-01-27 20:54 ` [PATCH 06/11] mos6522: use device_class_set_parent_reset() to propagate reset to parent Mark Cave-Ayland
2022-02-07 19:31 ` Peter Maydell
2022-01-27 20:54 ` [PATCH 07/11] mos6522: add register names to register read/write trace events Mark Cave-Ayland
2022-02-07 19:32 ` Peter Maydell
2022-01-27 20:54 ` [PATCH 08/11] mos6522: add "info via" HMP command for debugging Mark Cave-Ayland
2022-02-07 19:34 ` Peter Maydell
2022-02-08 5:14 ` Philippe Mathieu-Daudé via
2022-02-08 8:10 ` Markus Armbruster
2022-02-08 10:29 ` Dr. David Alan Gilbert [this message]
2022-02-08 11:52 ` Daniel P. Berrangé
2022-02-08 12:43 ` Mark Cave-Ayland
2022-02-08 13:03 ` Dr. David Alan Gilbert
2022-02-08 15:13 ` Markus Armbruster
2022-02-08 12:32 ` Mark Cave-Ayland
2022-02-08 13:04 ` Dr. David Alan Gilbert
2022-02-08 11:38 ` Daniel P. Berrangé
2022-02-08 12:39 ` Mark Cave-Ayland
2022-02-08 12:49 ` Daniel P. Berrangé
2022-02-08 13:06 ` Mark Cave-Ayland
2022-02-08 13:10 ` Daniel P. Berrangé
2022-02-20 17:18 ` Mark Cave-Ayland
2022-02-21 12:20 ` Philippe Mathieu-Daudé
2022-02-21 22:27 ` Mark Cave-Ayland
2022-02-21 17:11 ` Daniel P. Berrangé
2022-02-21 22:29 ` Mark Cave-Ayland
2022-02-22 15:03 ` Dr. David Alan Gilbert
2022-02-24 12:26 ` Mark Cave-Ayland
2022-01-27 20:54 ` [PATCH 09/11] mos6522: record last_irq_levels in mos6522_set_irq() Mark Cave-Ayland
2022-01-27 20:54 ` [PATCH 10/11] mos6522: implement edge-triggering for CA1/2 and CB1/2 control line IRQs Mark Cave-Ayland
2022-01-27 20:54 ` [PATCH 11/11] macio/pmu.c: remove redundant code Mark Cave-Ayland
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=YgJF9SDwb93k5/fg@work-vm \
--to=dgilbert@redhat.com \
--cc=Laurent@vivier.eu \
--cc=armbru@redhat.com \
--cc=f4bug@amsat.org \
--cc=kraxel@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=peter.maydell@linaro.org \
--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).