Gregory Haskins wrote:
> Out of curiosity, did you review my kick_process() version or the newer
> smp_call_function_single() based version of the patch?
>
>
The former.
>>
>>> @@ -1866,6 +1874,19 @@ static int kvm_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
>>>
>> struct kvm_run *kv
>>> On Sun, Apr 15, 2007 at 6:32 PM, in message <[EMAIL PROTECTED]>,
Gregory Haskins wrote:
> However, you do highlight a bug in this code that could cause the interrupt
> to be deferred indefinitely until a second interrupt came in if the processor
> happens to halt after this VMEXIT. I.e., s
>>> On Sat, Apr 14, 2007 at 10:30 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>>> It's really subtle.
>>>
>>> With respect to interrupts, VT^H^Hthe hardware provides an override over
>>> IF. If an interrupt happens while this override is ena
Gregory Haskins wrote:
>> It's really subtle.
>>
>> With respect to interrupts, VT^H^Hthe hardware provides an override over
>> IF. If an interrupt happens while this override is enabled, we exit
>> guest mode regardless of the state of IF. In effect interrupts are
>> enabled but _delivery_ is
>>> On Thu, Apr 12, 2007 at 10:14 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
>
> It's really subtle.
>
> With respect to interrupts, VT^H^Hthe hardware provides an override over
> IF. If an interrupt happens while this override is enabled, we exit
> guest mode r
Gregory Haskins wrote:
>
>> Ah, ok -- I misunderstood the whole thing. The way to avoid the race is
>> to disable interrupts before entering the guest. This way the IPI is
>> delayed until you enter guest mode:
>>
>> irq_disable();
>>
>> spin_lock();
>> vcpu- >guest_mode = 1;
>>
I have attached a new version of the patch which eliminates the condition
variable (if only by name, anyway ;)
>>> On Thu, Apr 12, 2007 at 8:49 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
> Actually, I am in favor of having well- defined synchronization
> pri
Gregory Haskins wrote:
>>>
>>>
>> If you want condition variables, activate your cryogenically- cooled suit
>> and post on it on lkml. This cannot be added to the kernel via kvm.
>>
>
> Hehe. I wasn't aware of the contention surrounding them but that does
> explain why they are n
>>> On Thu, Apr 12, 2007 at 4:02 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>> Hi All,
>> Attached are the first three patches in my queue. The first two you are
> likely familiar with at this point (though I have made some more of the
On Thu, Apr 12, 2007 at 11:02:25AM +0300, Avi Kivity wrote:
> If you want condition variables, activate your cryogenically-cooled suit
> and post on it on lkml. This cannot be added to the kernel via kvm.
Better just rip it out. The code would be a lot simpler with opencoded
waitqueue use, and
Gregory Haskins wrote:
> Hi All,
> Attached are the first three patches in my queue. The first two you are
> likely familiar with at this point (though I have made some more of the
> requested changes to 02-irqdevice.patch). The last item
> (03-preemptible-cpu.patch) adds an implementation t
11 matches
Mail list logo
