Il 08/10/2013 19:08, Alex Bligh ha scritto:
>
> On 8 Oct 2013, at 17:56, Paolo Bonzini wrote:
>
>>> Arguably the patch could document why removing the check for deadline >
>>> INT32_MAX
>>> (the bug for bug compatibility) is safe, as I couldn't entirely convince
>>> myself it
>>> was, mostly be
On 8 Oct 2013, at 17:56, Paolo Bonzini wrote:
>> Arguably the patch could document why removing the check for deadline >
>> INT32_MAX
>> (the bug for bug compatibility) is safe, as I couldn't entirely convince
>> myself it
>> was, mostly because I couldn't see why it was doing it in the first p
Il 08/10/2013 18:54, Alex Bligh ha scritto:
>> > -
>> > -/* Maintain prior (possibly buggy) behaviour where if no deadline
>> > - * was set (as there is no QEMU_CLOCK_VIRTUAL timer) or it is more
>> > than
>> > - * INT32_MAX nanoseconds ahead, we still use INT32_MAX
>> > - * nanose
On 8 Oct 2013, at 09:47, Paolo Bonzini wrote:
> Computing the deadline of all vm_clocks is somewhat expensive and calls
> out to qemu-timer.c; two reasons not to do it in the seqlock's write-side
> critical section. This however opens the door for races in setting and
> reading vm_clock_warp_sta
Computing the deadline of all vm_clocks is somewhat expensive and calls
out to qemu-timer.c; two reasons not to do it in the seqlock's write-side
critical section. This however opens the door for races in setting and
reading vm_clock_warp_start.
To plug them, we need to cover the case where a new
