All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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 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.