Dong, Eddie wrote:
> Avi:
>
> apic->lock is used in many place to avoid race condition with apic
> timer call back
> function which may run on different pCPU. This patch migrate the
> apic timer to
> same CPU with the one VP runs on, thus the lock is no longer
> necessary.
>
> thx,eddie
Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi Kivity wrote:
>>
>> For this situation, even without preemption, the problem is still
>> there. But maybe you are refering the old code, the latest code is
>> already preemption free since the apic_timer_fn didn't change any
>> APIC state. It only incr
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>>> Just noticed it is changed to mutex, but seems same here :-)
>>> If the process is switched to other task, it is OK since it won't
>>> access local APIC. Current VP access to APIC will take the mutex
>>> first (see below). Or you are talking other cor
Avi Kivity wrote:
>>
>> Just noticed it is changed to mutex, but seems same here :-)
>> If the process is switched to other task, it is OK since it won't
>> access local APIC. Current VP access to APIC will take the mutex
>> first (see below). Or you are talking other corner case?
>>
>>
>
> api
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> Dong, Eddie wrote:
>>
What about preemption:
- vcpu executes lapic code in qemu process context
>>> Don't understand. LAPIC is in kernel, how can qemu access?
>>> If you mean qemu is calling APIC KVM syscall, then
Avi Kivity wrote:
> Dong, Eddie wrote:
>>> What about preemption:
>>>
>>> - vcpu executes lapic code in qemu process context
>>>
>>
>> Don't understand. LAPIC is in kernel, how can qemu access?
>> If you mean qemu is calling APIC KVM syscall, then it already
>> disabled preemption & take kvm->lo
Avi Kivity wrote:
>
> Do we really take kvm->lock for local accesses? That's a significant
> problem, much more than the timer.
Actually, we must take the lock during emulation. But maybe we can
change it to a reader/writer lock, and certainly we can drop it during
lapic access.
---
Dong, Eddie wrote:
>> What about preemption:
>>
>> - vcpu executes lapic code in qemu process context
>>
>
> Don't understand. LAPIC is in kernel, how can qemu access?
> If you mean qemu is calling APIC KVM syscall, then it already
> disabled preemption & take kvm->lock.
>
>
>
I meant qemu
> What about preemption:
>
> - vcpu executes lapic code in qemu process context
Don't understand. LAPIC is in kernel, how can qemu access?
If you mean qemu is calling APIC KVM syscall, then it already
disabled preemption & take kvm->lock.
> - process is preempted
> - timer fires, touches lapic
Dong, Eddie wrote:
> Avi:
>
> apic->lock is used in many place to avoid race condition with apic
> timer call back
> function which may run on different pCPU. This patch migrate the
> apic timer to
> same CPU with the one VP runs on, thus the lock is no longer
> necessary.
>
> thx,eddie
On Fri, 2007-08-24 at 22:24 +0800, Dong, Eddie wrote:
> [EMAIL PROTECTED] wrote:
> > Gregory Haskins wrote:
> >> On Fri, 2007-08-24 at 21:08 +0800, Dong, Eddie wrote:
> >>> Avi:
> >>>
> >>> apic->lock is used in many place to avoid race condition with
> >>> apic timer call back function wh
[EMAIL PROTECTED] wrote:
> Gregory Haskins wrote:
>> On Fri, 2007-08-24 at 21:08 +0800, Dong, Eddie wrote:
>>> Avi:
>>>
>>> apic->lock is used in many place to avoid race condition with
>>> apic timer call back function which may run on different pCPU.
>>> This patch migrate the apic t
Gregory Haskins wrote:
> On Fri, 2007-08-24 at 21:08 +0800, Dong, Eddie wrote:
>> Avi:
>>
>> apic->lock is used in many place to avoid race condition with
>> apic timer call back function which may run on different pCPU.
>> This patch migrate the apic timer to same CPU with the one VP
On Fri, 2007-08-24 at 21:08 +0800, Dong, Eddie wrote:
> Avi:
>
> apic->lock is used in many place to avoid race condition with apic
> timer call back
> function which may run on different pCPU. This patch migrate the
> apic timer to
> same CPU with the one VP runs on, thus the lock is
14 matches
Mail list logo
