All of lore.kernel.org
 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 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.