qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] when does a target frontend need to use gen_io_start()/


From: Peter Maydell
Subject: Re: [Qemu-devel] when does a target frontend need to use gen_io_start()/gen_io_end() ?
Date: Wed, 13 May 2015 10:41:27 +0100

On 13 May 2015 at 09:42, Paolo Bonzini <address@hidden> wrote:
>
>
> On 12/05/2015 21:41, Peter Maydell wrote:
>>> > It's any instruction that can cause an icount read, typically through
>>> > QEMU_CLOCK_VIRTUAL or cpu_get_ticks().
>> Also anything that can cause a CPU interrupt, since tcg_handle_interrupt()
>> will call cpu_abort() if the CPU gets an interrupt while it's not
>> in a 'can do IO' state.
>>
>> Anything else?
>>
>> [How are -icount and multi-threaded TCG going to interact? Do we
>> just say "you get one or the other but not both" ?]
>
> For -icount and SMP, yes.  I even posted a patch to that end once.

I don't see why -icount and SMP need to be mutually exclusive.
If we're round-robining between the SMP CPUs then they should
all stay deterministic, I would have thought?

> You can get -icount and multi-threaded TCG (which for UP is simply TCG
> with execution out of the BQL) together I think.  For example you could
> handle cpu->icount_decr.u16.low == 0 like cpu->halted, hanging the CPU
> thread until QEMU_CLOCK_VIRTUAL timers have been processed.  The I/O
> thread would have to kick the CPU after processing QEMU_CLOCK_VIRTUAL
> timers---not hard to do.

Multithreaded TCG for a UP guest isn't very interesting though...

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]