All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ivan Shcherbakov" <ivan@sysprogs.com>
To: "'Alex Bennée'" <alex.bennee@linaro.org>
Cc: 'Peter Maydell' <peter.maydell@linaro.org>,
	mst@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com,
	'Paolo Bonzini' <pbonzini@redhat.com>
Subject: RE: [PATCH 3/3] whpx: Added support for breakpoints and stepping
Date: Mon, 28 Feb 2022 18:08:38 -0800	[thread overview]
Message-ID: <0aee01d82d11$450e03f0$cf2a0bd0$@sysprogs.com> (raw)
In-Reply-To: <87czj7nuy3.fsf@linaro.org>

Hi Alex,

Thanks for getting back to me. It is definitely the latter case (i.e. it is possible to change it while the target is stopped at a breakpoint before resuming any VCPUs).
vm_state_notify() does look like it's intended for this type of notifications, but unfortunately, it doesn't make a distinction between stepping and running normally.
Below is the relevant code from gdbstub.c:

>static int gdb_continue_partial(char *newstates)
>{
>    int flag = 0;
>
>    /* Various corner cases omitted for brevity  */
>        if (vm_prepare_start()) {
>            return 0;
>        }
>    CPU_FOREACH(cpu) {
>        switch (newstates[cpu->cpu_index]) {
>        case 's':
>            trace_gdbstub_op_stepping(cpu->cpu_index);
>            cpu_single_step(cpu, gdbserver_state.sstep_flags);
>            cpu_resume(cpu);
>            flag = 1;
>            break;
>        case 'c':
>            trace_gdbstub_op_continue_cpu(cpu->cpu_index);
>            cpu_resume(cpu);
>            flag = 1;
>            break;
>        default:
>            res = -1;
>            break;
>        }
>    }
>}

Also:

>int vm_prepare_start(void)
>{
>    runstate_set(RUN_STATE_RUNNING);
>    vm_state_notify(1, RUN_STATE_RUNNING);
>    return 0;
>}

and:

>void vm_state_notify(bool running, RunState state);

So, currently, vm_prepare_start() has no way of distinguishing between single-stepping and normal running unless gdb_continue_partial() scans the 'newstates' array before calling it, and passes some extra argument to vm_prepare_start(), indicating whether a step request was present anywhere in the array.

I couldn't find any existing run state that would match single-stepping, and adding another run state looks like a very non-trivial change that can easily backfire. Adding another argument to vm_state_notify() could be easier, but I am still afraid it could break some other part of QEMU, so I thought adding a new member to AccelOpsClass would be a safer bet. But again, if you think another way to do it is better, I am very open to it.

Best regards,
Ivan

-----Original Message-----
From: Alex Bennée <alex.bennee@linaro.org> 
Sent: Monday, February 28, 2022 2:28 AM
To: Ivan Shcherbakov <ivan@sysprogs.com>
Cc: 'Peter Maydell' <peter.maydell@linaro.org>; 'Paolo Bonzini' <pbonzini@redhat.com>; qemu-devel@nongnu.org; armbru@redhat.com; mst@redhat.com
Subject: Re: [PATCH 3/3] whpx: Added support for breakpoints and stepping

Is the limitation that whpx_set_exception_exit_bitmap needs to be set before any vCPU can be run or that it cannot be set if any vCPUs are currently running?
If it is the later wouldn't adding a hook into the vm_change_state_head callbacks be enough?



  reply	other threads:[~2022-03-01  2:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23  5:25 [PATCH 3/3] whpx: Added support for breakpoints and stepping Ivan Shcherbakov
2022-02-23  9:36 ` Paolo Bonzini
2022-02-23 20:05   ` Ivan Shcherbakov
2022-02-24  9:35     ` Peter Maydell
2022-02-24 11:22       ` Alex Bennée
2022-02-24 15:54         ` Ivan Shcherbakov
2022-02-28  4:31           ` Ivan Shcherbakov
2022-02-28 10:28             ` Alex Bennée
2022-03-01  2:08               ` Ivan Shcherbakov [this message]
2022-03-02  2:06                 ` Ivan Shcherbakov

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='0aee01d82d11$450e03f0$cf2a0bd0$@sysprogs.com' \
    --to=ivan@sysprogs.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --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.