On Fri, 7 Dec 2018 at 16:00, Peter Maydell wrote:
>
> We use cpu_stop_current() to ensure the current CPU has stopped
> from places like qemu_system_reset_request(). Unfortunately its
> current implementation has a race. It calls qemu_cpu_stop(),
> which sets cpu->stopped to true even though the C
On Fri, Dec 07, 2018 at 15:59:11 +, Peter Maydell wrote:
> We use cpu_stop_current() to ensure the current CPU has stopped
> from places like qemu_system_reset_request(). Unfortunately its
> current implementation has a race. It calls qemu_cpu_stop(),
> which sets cpu->stopped to true even thou
Hi again,
On 12/7/18 4:59 PM, Peter Maydell wrote:
> We use cpu_stop_current() to ensure the current CPU has stopped
> from places like qemu_system_reset_request(). Unfortunately its
> current implementation has a race. It calls qemu_cpu_stop(),
> which sets cpu->stopped to true even though the CP
Le 12/10/18 à 3:39 PM, Peter Maydell a écrit :
On Mon, 10 Dec 2018 at 14:30, KONRAD Frederic
wrote:
Hi Peter,
Thanks for that patch!
I'm seeing the same kind of issue when I run 8 qemu in parallel but it doesn't
seem to be fixed by this patch. Is it supposed to fix the issue when we are
d
On Mon, 10 Dec 2018 at 14:30, KONRAD Frederic
wrote:
>
> Hi Peter,
>
> Thanks for that patch!
>
> I'm seeing the same kind of issue when I run 8 qemu in parallel but it doesn't
> seem to be fixed by this patch. Is it supposed to fix the issue when we are
> doing a reset_request through a MMIO devi
Hi Peter,
Thanks for that patch!
I'm seeing the same kind of issue when I run 8 qemu in parallel but it doesn't
seem to be fixed by this patch. Is it supposed to fix the issue when we are
doing a reset_request through a MMIO device?
It happens (rarely) with this kind of guest code:
exit:
wri
On Mon, 10 Dec 2018 at 12:15, Alex Bennée wrote:
> Peter Maydell writes:
> > though I might actually have meant pause_all_vcpus().
> > (For pause_all_vcpus() I think the correct thing is to
> > fix the hw/i386/kvmvapic.c code to work in some other way,
> > and then assert that pause_all_vcpus() i
Peter Maydell writes:
> On Mon, 10 Dec 2018 at 11:06, Alex Bennée wrote:
>>
>>
>> Peter Maydell writes:
>> > We discussed this a little while back:
>> > https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg00154.html
>> > and Jaap reported a bug which I suspect of being the same thing:
>>
On Mon, 10 Dec 2018 at 11:06, Alex Bennée wrote:
>
>
> Peter Maydell writes:
> > We discussed this a little while back:
> > https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg00154.html
> > and Jaap reported a bug which I suspect of being the same thing:
> > https://lists.gnu.org/archive/ht
Peter Maydell writes:
> We use cpu_stop_current() to ensure the current CPU has stopped
> from places like qemu_system_reset_request(). Unfortunately its
> current implementation has a race. It calls qemu_cpu_stop(),
> which sets cpu->stopped to true even though the CPU hasn't
> actually stoppe
Hello all,
On 12/7/18 4:59 PM, Peter Maydell wrote:
> Jaap: could you test whether this patch fixes the issue you
> were seeing, please?
My test is going very well. With the patch applied, I have no longer been able
to freeze/hang the VM. Currently at 7024 reboots and counting over
runtime 1 da
Hi all,
On 12/7/18 4:59 PM, Peter Maydell wrote:
> Jaap: could you test whether this patch fixes the issue you
> were seeing, please?
I have applied the patch and started my test tool against it. It will need some
time as I have also seen cases where it only failed after 600 reboots.
My testtool
We use cpu_stop_current() to ensure the current CPU has stopped
from places like qemu_system_reset_request(). Unfortunately its
current implementation has a race. It calls qemu_cpu_stop(),
which sets cpu->stopped to true even though the CPU hasn't
actually stopped yet. The main thread will look at
13 matches
Mail list logo
