[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] tcg: handle EXCP_ATOMIC exception properly

From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH] tcg: handle EXCP_ATOMIC exception properly
Date: Fri, 10 Feb 2017 12:33:24 +0000
User-agent: mu4e 0.9.19; emacs 25.2.1

Paolo Bonzini <address@hidden> writes:

> On 10/02/2017 13:13, Alex Bennée wrote:
>>> +        if (atomic_read(&other_cpu->running) &&
>>> !qemu_cpu_is_self(other_cpu)) {
>> The comment above reads:
>>   Must only be called from outside cpu_exec.
>> So we need to revise this comment. Is this really a limitation or was it
>> originally the design goal?
> If you want to call it within cpu_exec, you can always use
> cpu_exec_end/start around it.
> I think we should first of all get rid of the iothread lock within
> cpu_exec, and then look at this patch again.

What to do with the MTTCG series in the meantime?

I'm hesitant to hold up the whole series for a potentially messy
re-factor of the cpu loop code to push out the BQL which could take some
time, although of course I don't want to merge something that makes that

That said for TCG system emulation EXCP_ATOMIC is currently broken with
respect to debugging. However for the initial guests/host combination of
ARMv7/8 on x86_64 we don't need the fallback with pretty much 99% of
deployed hosts. How about the following:

  - drop Pranith's patch for the current MTTCG series
  - replace with an error/abort on EXCP_ATOMIC
  - proceed with merge as plan
  - tackle the BQL lock next (along with more MTTCG guest/targets enablement)


Any thoughts/opinions on this?

Alex Bennée

reply via email to

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