[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, W
From: |
Paolo Bonzini |
Subject: |
Re: [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP) |
Date: |
Tue, 17 Dec 2019 15:39:30 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 |
On 17/12/19 15:18, Alex Bennée wrote:
>
> Paolo Bonzini <address@hidden> writes:
>
>> On 17/12/19 14:42, Alex Bennée wrote:
>>>> Why do you need to set exception_index to something other than -1 (using
>>>> cpu_loop_exit_noexc for example)?
>>> If there is no exception to process we won't exit the main loop which we
>>> need to do if we want to wait until there is data to read.
>>
>> Okay.
>>
>>>> Using ->stop here is a bit weird, since ->stop is usually related to
>>>> pause_all_vcpus.
>>>
>>> Arguably we could come up with a better API to cpu.c but this allows us
>>> to use cpu_resume(c->sleeping_cpu) when waking up rather than hand
>>> rolling our own wake-up mechanism.
>>
>> But we already have the right wake-up mechanism, which is
>> cpu->halted/cpu_has_work.
>
> cpu_has_work is a guest function though and semihosting_console is a
> common hw module. It can't peek into the guests internal state.
semihosting_console only needs to something like
cpu_interrupt(cpu->stopped_cpu, CPU_INTERRUPT_SEMIHOST). (By the way,
the stopped_cpu should probably be a list to mimic the condition
variable---for example a GList).
> This all
> comes back to cpu_thread_is_idle anyway in making our decision about if
> we do or do not sleep on the halt_cond.
>
>> That also makes it possible to just use
>> EXCP_HALTED instead of adding a new EXCP_BLOCKED.
>
> We can certainly use EXCP_HALTED but maybe come up with a common way of
> entering the state? There seems to be a combination of messing around
> with special interrupts and direct poking of cs->halted = 1 while
> setting the exception. Maybe this could finally clear up the #if
> defined(TARGET_I386) hacking in cpus.c?
If you're talking accel/tcg/cpu-exec.c, that's different; the issue
there is that x86 has a kind of warm reset pin that is not equivalent to
cpu_reset. Removing that would only entail adding a new member function
to CPUClass.
Paolo
- Re: [PATCH] Semihost SYS_READC implementation (v6), Alex Bennée, 2019/12/17
- Re: [PATCH] Semihost SYS_READC implementation (v6), Paolo Bonzini, 2019/12/17
- Re: [PATCH] Semihost SYS_READC implementation (v6), Alex Bennée, 2019/12/17
- Re: [PATCH] Semihost SYS_READC implementation (v6), Paolo Bonzini, 2019/12/17
- [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP), Alex Bennée, 2019/12/17
- Re: [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP), Paolo Bonzini, 2019/12/17
- Re: [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP), Alex Bennée, 2019/12/17
- Re: [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP), Paolo Bonzini, 2019/12/17
- Re: [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP), Alex Bennée, 2019/12/17
- Re: [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP),
Paolo Bonzini <=
- Re: [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP), Paolo Bonzini, 2019/12/17
- Re: [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP), Alex Bennée, 2019/12/18
- Re: [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP), Paolo Bonzini, 2019/12/18