On 10/02/2017 15:37, Alex Bennée wrote:
>>> - drop Pranith's patch for the current MTTCG series
>>> - replace with an error/abort on EXCP_ATOMIC
>> Don't even replace it? :)
>
> I guess - the failure mode is only when we single step? Should we not
> try to emit a warning like we do for the m
Paolo Bonzini writes:
> On 10/02/2017 13:33, Alex Bennée wrote:
>> 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
>> deploy
On Fri, Feb 10, 2017 at 7:29 AM, Paolo Bonzini wrote:
>
>
> On 10/02/2017 13:18, Alex Bennée wrote:
> >> I think you can unlock/lock the iothread here, and also call
> >
> > The iothread is already unlocked by this point (see tcg_cpu_exec).
>
> Is this patch on top of the MTTCG branch? If not, c
On 10/02/2017 13:33, Alex Bennée wrote:
> 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 follo
Paolo Bonzini writes:
> On 10/02/2017 13:18, Alex Bennée wrote:
>>> I think you can unlock/lock the iothread here, and also call
>>
>> The iothread is already unlocked by this point (see tcg_cpu_exec).
>
> Is this patch on top of the MTTCG branch? If not, cpu_handle_exception
> runs with the io
Paolo Bonzini 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 limita
On 10/02/2017 13:18, Alex Bennée wrote:
>> I think you can unlock/lock the iothread here, and also call
>
> The iothread is already unlocked by this point (see tcg_cpu_exec).
Is this patch on top of the MTTCG branch? If not, cpu_handle_exception
runs with the iothread lock taken doesn't it?
>>
Paolo Bonzini writes:
> On 10/02/2017 02:45, Pranith Kumar wrote:
>> The current method of executing atomic code in a guest uses
>> cpu_exec_step_atomic() from the outermost loop. This causes an abort()
>> when single stepping over atomic code since debug exception longjmp
>> will point to the t
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 th
Pranith Kumar writes:
> The current method of executing atomic code in a guest uses
> cpu_exec_step_atomic() from the outermost loop. This causes an abort()
> when single stepping over atomic code since debug exception longjmp
> will point to the the setlongjmp in cpu_exec(). Another issue with
On 10/02/2017 02:45, Pranith Kumar wrote:
> The current method of executing atomic code in a guest uses
> cpu_exec_step_atomic() from the outermost loop. This causes an abort()
> when single stepping over atomic code since debug exception longjmp
> will point to the the setlongjmp in cpu_exec().
On Thu, Feb 9, 2017 at 8:45 PM, Pranith Kumar wrote:
>
> The current method of executing atomic code in a guest uses
> cpu_exec_step_atomic() from the outermost loop. This causes an abort()
> when single stepping over atomic code since debug exception longjmp
> will point to the the setlongjmp in
The current method of executing atomic code in a guest uses
cpu_exec_step_atomic() from the outermost loop. This causes an abort()
when single stepping over atomic code since debug exception longjmp
will point to the the setlongjmp in cpu_exec(). Another issue with
this mechanism is that the flags
13 matches
Mail list logo
