On 08/21/12 10:23, Stefan Hajnoczi wrote:
On Tue, Aug 21, 2012 at 8:21 AM, Jan Kiszka wrote:
On 2012-08-19 11:42, Avi Kivity wrote:
On 08/17/2012 06:04 PM, Jan Kiszka wrote:
Can anyone imagine that such a barrier may actually be required? If it
is currently possible that env->stop is evaluate
On Tue, Aug 21, 2012 at 8:21 AM, Jan Kiszka wrote:
> On 2012-08-19 11:42, Avi Kivity wrote:
>> On 08/17/2012 06:04 PM, Jan Kiszka wrote:
>>>
> Can anyone imagine that such a barrier may actually be required? If it
> is currently possible that env->stop is evaluated before we called into
>>
On 2012-08-19 11:42, Avi Kivity wrote:
> On 08/17/2012 06:04 PM, Jan Kiszka wrote:
>>
Can anyone imagine that such a barrier may actually be required? If it
is currently possible that env->stop is evaluated before we called into
sigtimedwait in qemu_kvm_eat_signals, then we could a
On 08/17/2012 06:04 PM, Jan Kiszka wrote:
>
>>> Can anyone imagine that such a barrier may actually be required? If it
>>> is currently possible that env->stop is evaluated before we called into
>>> sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the
>>> signal without properly p
On 2012-08-17 16:41, Jan Kiszka wrote:
> On 2012-08-17 16:36, Jan Kiszka wrote:
>> On 2012-08-17 15:11, Jan Kiszka wrote:
>>> On 2012-08-06 17:11, Stefan Hajnoczi wrote:
On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
> i debugged my initial problem further and found out that the pro
On 2012-08-17 16:36, Jan Kiszka wrote:
> On 2012-08-17 15:11, Jan Kiszka wrote:
>> On 2012-08-06 17:11, Stefan Hajnoczi wrote:
>>> On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
i debugged my initial problem further and found out that the problem
happens
to be that
the m
On 2012-08-17 15:11, Jan Kiszka wrote:
> On 2012-08-06 17:11, Stefan Hajnoczi wrote:
>> On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
>>> i debugged my initial problem further and found out that the problem happens
>>> to be that
>>> the main thread is stuck in pause_all_vcpus() on reset or
On 2012-08-06 17:11, Stefan Hajnoczi wrote:
> On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
>> i debugged my initial problem further and found out that the problem happens
>> to be that
>> the main thread is stuck in pause_all_vcpus() on reset or quit commands in
>> the monitor
>> if one cp
On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
> i debugged my initial problem further and found out that the problem happens
> to be that
> the main thread is stuck in pause_all_vcpus() on reset or quit commands in
> the monitor
> if one cpu is stuck in the do-while loop kvm_cpu_exec. If I
On 02.07.2012 09:05, Jan Kiszka wrote:
On 2012-07-01 21:18, Peter Lieven wrote:
Am 01.07.2012 um 10:19 schrieb Avi Kivity:
On 06/28/2012 10:27 PM, Peter Lieven wrote:
Am 28.06.2012 um 18:32 schrieb Avi Kivity:
On 06/28/2012 07:29 PM, Peter Lieven wrote:
Yes. A signal is sent, and KVM retur
On 2012-07-01 21:18, Peter Lieven wrote:
>
> Am 01.07.2012 um 10:19 schrieb Avi Kivity:
>
>> On 06/28/2012 10:27 PM, Peter Lieven wrote:
>>>
>>> Am 28.06.2012 um 18:32 schrieb Avi Kivity:
>>>
On 06/28/2012 07:29 PM, Peter Lieven wrote:
>> Yes. A signal is sent, and KVM returns from the g
Am 01.07.2012 um 10:19 schrieb Avi Kivity:
> On 06/28/2012 10:27 PM, Peter Lieven wrote:
>>
>> Am 28.06.2012 um 18:32 schrieb Avi Kivity:
>>
>>> On 06/28/2012 07:29 PM, Peter Lieven wrote:
> Yes. A signal is sent, and KVM returns from the guest to userspace on
> pending signals.
>>>
>>
On 06/28/2012 10:27 PM, Peter Lieven wrote:
>
> Am 28.06.2012 um 18:32 schrieb Avi Kivity:
>
>> On 06/28/2012 07:29 PM, Peter Lieven wrote:
Yes. A signal is sent, and KVM returns from the guest to userspace on
pending signals.
>>
>>> is there a description available how this process exa
Am 28.06.2012 um 18:32 schrieb Avi Kivity:
> On 06/28/2012 07:29 PM, Peter Lieven wrote:
>>> Yes. A signal is sent, and KVM returns from the guest to userspace on
>>> pending signals.
>
>> is there a description available how this process exactly works?
>
> The kernel part is in vcpu_enter_gues
On 06/28/2012 07:29 PM, Peter Lieven wrote:
>> Yes. A signal is sent, and KVM returns from the guest to userspace on
>> pending signals.
> is there a description available how this process exactly works?
The kernel part is in vcpu_enter_guest(), see the check for
signal_pending(). But this hasn'
On 28.06.2012 17:22, Jan Kiszka wrote:
On 2012-06-28 17:02, Peter Lieven wrote:
On 28.06.2012 15:25, Jan Kiszka wrote:
On 2012-06-28 15:05, Peter Lieven wrote:
Hi,
i debugged my initial problem further and found out that the problem
happens to be that
the main thread is stuck in pause_all_vcp
On 2012-06-28 17:02, Peter Lieven wrote:
> On 28.06.2012 15:25, Jan Kiszka wrote:
>> On 2012-06-28 15:05, Peter Lieven wrote:
>>> Hi,
>>>
>>> i debugged my initial problem further and found out that the problem
>>> happens to be that
>>> the main thread is stuck in pause_all_vcpus() on reset or qui
On 28.06.2012 15:25, Jan Kiszka wrote:
On 2012-06-28 15:05, Peter Lieven wrote:
Hi,
i debugged my initial problem further and found out that the problem
happens to be that
the main thread is stuck in pause_all_vcpus() on reset or quit commands
in the monitor
if one cpu is stuck in the do-while
On 2012-06-28 15:05, Peter Lieven wrote:
> Hi,
>
> i debugged my initial problem further and found out that the problem
> happens to be that
> the main thread is stuck in pause_all_vcpus() on reset or quit commands
> in the monitor
> if one cpu is stuck in the do-while loop kvm_cpu_exec. If I modi
Hi,
i debugged my initial problem further and found out that the problem
happens to be that
the main thread is stuck in pause_all_vcpus() on reset or quit commands
in the monitor
if one cpu is stuck in the do-while loop kvm_cpu_exec. If I modify the
condition from while (ret == 0)
to while ((
20 matches
Mail list logo
