Am 14.07.2015 um 22:32 schrieb Zavadovsky Yan:
> On Tue, Jul 14, 2015 at 11:29 PM, Stefan Weil wrote:
>
>> I'll send a pull request for this patch after the release of QEMU 2.4.
>>
> Ok. Thanks.
>
Thank you for this patch. It is now in my patch queue
On Tue, Jul 14, 2015 at 11:29 PM, Stefan Weil s...@weilnetz.de wrote:
I'll send a pull request for this patch after the release of QEMU 2.4.
Ok. Thanks.
Am 14.07.2015 um 21:44 schrieb Zavadovsky Yan:
On Wed, Jul 1, 2015 at 9:00 PM, Stefan Weil s...@weilnetz.de
mailto:s...@weilnetz.de wrote:
Fabien, you suggested extensive tests. Do you think that
patch v2 is fine, or are you still waiting for test results?
On Mon, Jul 6, 2015 at 12:29
On Wed, Jul 1, 2015 at 9:00 PM, Stefan Weil s...@weilnetz.de wrote:
Fabien, you suggested extensive tests. Do you think that
patch v2 is fine, or are you still waiting for test results?
On Mon, Jul 6, 2015 at 12:29 PM, Fabien Chouteau chout...@adacore.com
wrote:
That's good for me.
On 07/02/2015 09:09 PM, Zavadovsky Yan wrote:
I tested this patch on my 4-cores cpu.
Debug and release builds both.
Win32 and Win64 binaries both. (I used old Fedora 17-18 with SJLJ mingw-w64
to crossbuild for Win64.)
With default Qemu BIOS and with myself-builded OVMF(also debug and
On 07/01/2015 08:00 PM, Stefan Weil wrote:
Am 01.07.2015 um 18:49 schrieb Paolo Bonzini:
On 01/07/2015 17:48, Zavadovsky Yan wrote:
Ping.
Stefan, are you merging this?
Paolo
I can do so, but as the current code seems to fix the problems
with multi-processor systems, too (even if it is
I tested this patch on my 4-cores cpu.
Debug and release builds both.
Win32 and Win64 binaries both. (I used old Fedora 17-18 with SJLJ mingw-w64
to crossbuild for Win64.)
With default Qemu BIOS and with myself-builded OVMF(also debug and
release) from EDK2.
Also I did some synthetic tests with
Am 01.07.2015 um 18:49 schrieb Paolo Bonzini:
On 01/07/2015 17:48, Zavadovsky Yan wrote:
Ping.
Stefan, are you merging this?
Paolo
I can do so, but as the current code seems to fix the problems
with multi-processor systems, too (even if it is unclear why),
it does not look urgent.
Fabien,
Ping.
Patchwork: http://patchwork.ozlabs.org/patch/488073/
v1 discussion:
http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg05791.html
and patchworks: http://patchwork.ozlabs.org/patch/487438/
http://patchwork.ozlabs.org/patch/487566/
On Wed, Jun 24, 2015 at 3:25 PM, Zavadovsky Yan
On 01/07/2015 17:48, Zavadovsky Yan wrote:
Ping.
Stefan, are you merging this?
Paolo
Patchwork: http://patchwork.ozlabs.org/patch/488073/
v1
discussion:
http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg05791.html
and patchworks: http://patchwork.ozlabs.org/patch/487438/
sorry for being partly off-topic, but the last time I checked the windows
builds, there was a problem on win64, applications using timers (like Cortex-M
SysTick) failed.
the tests were performed both with my fork and with Stefan's official version,
with the same results.
I saw there were
On 25/06/15 15:17, Zavadovsky Yan wrote:
On Thu, Jun 25, 2015 at 12:11 PM, Olga Krishtal okrish...@parallels.com
wrote:
On 24/06/15 15:25, Zavadovsky Yan wrote:
Calling SuspendThread() is not enough to suspend Win32 thread.
We need to call GetThreadContext() after SuspendThread()
to make
On Fri, Jun 26, 2015 at 1:28 PM, Olga Krishtal okrish...@parallels.com
wrote:
On 25/06/15 15:17, Zavadovsky Yan wrote:
On Thu, Jun 25, 2015 at 12:11 PM, Olga Krishtal okrish...@parallels.com
okrish...@parallels.com
wrote:
On 24/06/15 15:25, Zavadovsky Yan wrote:
Calling
On Thu, Jun 25, 2015 at 12:11 PM, Olga Krishtal okrish...@parallels.com
wrote:
On 24/06/15 15:25, Zavadovsky Yan wrote:
Calling SuspendThread() is not enough to suspend Win32 thread.
We need to call GetThreadContext() after SuspendThread()
to make sure that OS have really suspended target
On 24/06/15 15:25, Zavadovsky Yan wrote:
Calling SuspendThread() is not enough to suspend Win32 thread.
We need to call GetThreadContext() after SuspendThread()
to make sure that OS have really suspended target thread.
But GetThreadContext() needs for THREAD_GET_CONTEXT
access right on thread
Calling SuspendThread() is not enough to suspend Win32 thread.
We need to call GetThreadContext() after SuspendThread()
to make sure that OS have really suspended target thread.
But GetThreadContext() needs for THREAD_GET_CONTEXT
access right on thread object.
More info about this technique can be
16 matches
Mail list logo