[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
harder.
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)
Richard/Peter,
Any thoughts/opinions on this?
--
Alex Bennée