qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Alistair Francis <alistair23@gmail.com>
Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	Alistair Francis <alistair.francis@xilinx.com>
Subject: Re: [Qemu-devel] MTTCG External Halt
Date: Thu, 04 Jan 2018 11:08:33 +0000	[thread overview]
Message-ID: <87lghd3mq6.fsf@linaro.org> (raw)
In-Reply-To: <CAKmqyKPZ3AUwGFwp6zK+aFSd6R3p8c+pP-i-W-g=t6ZfR5GVaA@mail.gmail.com>


Alistair Francis <alistair23@gmail.com> writes:

> Hey guys, I'm super stuck with an ugly MTTCG issue and was wondering
> if anyone had any ideas.
>
> In the Xilinx fork of QEMU (based on 2.11) we have a way for CPUs to
> halt other CPUs. This is used for example when the power control unit
> halts the ARM A53s. To do this we have internal GPIO signals that end
> up calling a function that basically does this:
>
> To halt:
>     cpu->halted = true;
>     cpu_interrupt(cpu, CPU_INTERRUPT_HALT);

Hmm I don't think you should be setting cpu->halted unless you know it
is safe to do so. As the other CPUs free-run during BQL this isn't
enough for a cross vCPU interaction. However you can schedule work to
run in the target vCPUs context safely.

That said isn't the cpu_interrupt enough to trigger the target vCPU to
halt?

>
> To un-halt
>     cpu->halted = false;
>     cpu_reset_interrupt(cpu, CPU_INTERRUPT_HALT);

Again if cross vCPU context this needs to be scheduled against the
target vCPU.

>
> We also have the standard ARM WFI (Wait For Interrupt) implementation
> in op_helper.c:
>     cs->halted = 1;
>     cs->exception_index = EXCP_HLT;
>     cpu_loop_exit(cs);
>
> Before MTTCG this used to work great, but now either we end up with
> the guest Linux complaining about CPU stalls or we hit:
> ERROR:/scratch/alistai/master-qemu/cpus.c:1516:qemu_tcg_cpu_thread_fn:
> assertion failed: (cpu->halted)
>
> If I remove the instances of manually setting cpu->halted then I don't
> see the asserts(), but the the WFI instruction doesn't work correctly.
> So it seems like setting the halted status externally from the CPU
> causes the issue.

  /* during start-up the vCPU is reset and the thread is
   * kicked several times. If we don't ensure we go back
   * to sleep in the halted state we won't cleanly
   * start-up when the vCPU is enabled.
   *
   * cpu->halted should ensure we sleep in wait_io_event
   */

I think what I'm trying to say is we should never be halted without
having gone via wait_io_event where we can sleep.


> I have tried setting it inside a lock, using atomic
> operations and running the setter async on the CPU, but nothing works.
>
> Any chance any one has some insight into a way to externally set a
> vCPU as halted/un-halted?

See the PSCI code which uses the async interface for exactly this.

>
> Thanks,
> Alistair


--
Alex Bennée

  parent reply	other threads:[~2018-01-04 11:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-03 22:10 [Qemu-devel] MTTCG External Halt Alistair Francis
2018-01-03 22:14 ` Peter Maydell
2018-01-03 22:23   ` Alistair Francis
2018-01-04  1:14     ` Alistair Francis
2018-01-04 11:08 ` Alex Bennée [this message]
2018-01-06  2:23   ` Alistair Francis
2018-01-30 23:56     ` Alistair Francis
2018-01-31  4:26       ` Paolo Bonzini
2018-01-31 16:08         ` Alistair Francis
2018-01-31 20:32           ` Alex Bennée
2018-01-31 22:31             ` Alistair Francis
2018-02-01 12:01               ` Alex Bennée
2018-02-01 17:13                 ` Alistair Francis
2018-02-01 21:00                   ` Alistair Francis
2018-02-02 20:37                     ` Alex Bennée
2018-02-02 21:49                       ` Alistair Francis
2018-02-02 21:59                         ` Alistair Francis
2018-04-22 23:03                           ` Philippe Mathieu-Daudé
2018-01-31 17:13 ` Paolo Bonzini
2018-01-31 18:17   ` Alistair Francis
2018-01-31 18:48     ` Peter Maydell
2018-01-31 18:51       ` Alistair Francis
2018-01-31 18:56         ` Alistair Francis
2018-01-31 18:59         ` Peter Maydell
2018-01-31 19:37           ` Alistair Francis

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=87lghd3mq6.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=alistair.francis@xilinx.com \
    --cc=alistair23@gmail.com \
    --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).