Paolo Bonzini <pbonz...@redhat.com> writes:
> On 17/12/19 15:18, Alex Bennée wrote: >> >> Paolo Bonzini <pbonz...@redhat.com> 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). As an exception is being delivered we just end up re-executing the EXCP_SEMIHOST. I still don't see why using cpu_interrupt is an improvement seeing as it is secondary to exception processing. > (By the way, > the stopped_cpu should probably be a list to mimic the condition > variable---for example a GSList). ok > >> 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 -- Alex Bennée
