On Mon, 7 Sept 2026 at 22:42, Paolo Bonzini <[email protected]> wrote: > > On 9/2/26 20:02, Philippe Mathieu-Daudé wrote: > >>> On the other hand, if we do have the BQL in exec_halt > >>> then why is the x86 implementation explicitly taking > >>> the BQL when it calls apic_poll_irq()? > > > > Trying harder, my understanding is apic_poll_irq() only requires > > the BQL for the apic_update_irq() call, not apic_sync_vapic(). > > > > So maybe only apic_sync_vapic() belongs to process_async_events(), > > leaving apic_update_irq() to transition_halt_to_exec(). > > > > Paolo does that sound like going in the good direction? > Unfortunately not, because apic_update_irq() is needed to call > cpu_interrupt() and break out of halt. > > By the way... cpu_has_work_after_processing_async_events() is a bit > long, what about simply cpu_poll_while_halted()? > > Answering Peter's question above, the way in which the code is protected > against the BQL is basically two-fold: 1) kicking the CPU out of > whatever it's doing, for example in tcg_handle_interrupt, 2) changing > what other conditions affect cpu_has_work() only in the vCPU thread, > e.g. with run_on_cpu.
Ah, so it is called without the BQL held? That's quite unusual for CPU methods, so we should clearly document that. I bet also that most targets don't expect it. Picking one at random, the sparc has_work function calls e.g. cpu_interrupts_enabled() which does not look like a function that is expecting to be called without the BQL. Is it OK for a has_work function to just take the BQL across what it's doing if it doesn't want to be bothered with trying to make the handling truly thread safe without a lock? That seems to me like it would be a lot simpler and more reliable. -- PMM
