[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] MTTCG External Halt
From: |
Alistair Francis |
Subject: |
Re: [Qemu-devel] MTTCG External Halt |
Date: |
Wed, 31 Jan 2018 08:08:30 -0800 |
On Tue, Jan 30, 2018 at 8:26 PM, Paolo Bonzini <address@hidden> wrote:
> On 30/01/2018 18:56, Alistair Francis wrote:
>>
>> I don't have a good solution though, as setting CPU_INTERRUPT_RESET
>> doesn't help (that isn't handled while we are halted) and
>> async_run_on_cpu()/run_on_cpu() doesn't reliably reset the CPU when we
>> want.
>>
>> I've ever tried pausing all CPUs before reseting the CPU and them
>> resuming them all but that doesn't seem to to work either.
>
> async_safe_run_on_cpu would be like async_run_on_cpu, except that it
> takes care of stopping all other CPUs while the function runs.
>
>> Is there
>> anything I'm missing? Is there no reliable way to reset a CPU?
>
> What do you mean by reliable? Executing no instruction after the one
> you were at?
The reset is called by a GPIO line, so I need the reset to be called
basically as quickly as the GPIO line changes. The async_ and
async_safe_ functions seem to not run quickly enough, even if I run a
process_work_queue() function afterwards.
Is there a way to kick the CPU to act on the async_*?
Thanks,
Alistair
>
> Paolo
>
Re: [Qemu-devel] MTTCG External Halt, Paolo Bonzini, 2018/01/31
- Re: [Qemu-devel] MTTCG External Halt, Alistair Francis, 2018/01/31
- Re: [Qemu-devel] MTTCG External Halt, Peter Maydell, 2018/01/31
- Re: [Qemu-devel] MTTCG External Halt, Alistair Francis, 2018/01/31
- Re: [Qemu-devel] MTTCG External Halt, Alistair Francis, 2018/01/31
- Re: [Qemu-devel] MTTCG External Halt, Peter Maydell, 2018/01/31
- Re: [Qemu-devel] MTTCG External Halt, Alistair Francis, 2018/01/31