>Avi Kivity wrote:
>> Gregory Haskins wrote:
>>> Hi Avi,
>>> You make good points. I will convert to a nest lock design and
>>> resubmit. Should I use two mutexes, or a mutex and spinlock?
>>>
>>> Also, do you have any suggestions on the signum I should use to IPI
>>> the running guest? Shoul
Gregory Haskins wrote:
>> Note that as long as the apic code is in userspace, the sending side is
>> also in userspace, so all the IPI related stuff doesn't touch the kernel.
>>
>
>
> I see. So really the entire approach I took (against the kernel code) is
> wrong, and I should focus on the
>>> On Mon, Mar 19, 2007 at 10:03 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Avi Kivity wrote:
>> Gregory Haskins wrote:
>>> Hi Avi,
>>> You make good points. I will convert to a nest lock design and
>>> resubmit. Should I use two mutexes, or a mutex and spin
Avi Kivity wrote:
> Gregory Haskins wrote:
>> Hi Avi,
>> You make good points. I will convert to a nest lock design and
>> resubmit. Should I use two mutexes, or a mutex and spinlock?
>>
>> Also, do you have any suggestions on the signum I should use to IPI
>> the running guest? Should I us
Gregory Haskins wrote:
> Hi Avi,
> You make good points. I will convert to a nest lock design and resubmit.
> Should I use two mutexes, or a mutex and spinlock?
>
> Also, do you have any suggestions on the signum I should use to IPI the
> running guest? Should I use one of the normal signal
Hi Avi,
You make good points. I will convert to a nest lock design and resubmit.
Should I use two mutexes, or a mutex and spinlock?
Also, do you have any suggestions on the signum I should use to IPI the running
guest? Should I use one of the normal signals (SIGUSR) or should I start a
bl
Gregory Haskins wrote:
>> Whoa there. kvm can't just add new locking constructs to the kernel.
>>
>
> With all due respect, why not? ;) Of course it can. We arent really adding
> anything exposed to the kernel outside of KVM or even adding a new one from
> scratch. Its simply deri
>>> On Fri, Mar 16, 2007 at 3:03 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>> This patch adds baseline support for interrupt preemption. This lets one
> context (virtual SMP vcpu, PV driver, etc) preempt another vcpu which is
> currently
Gregory Haskins wrote:
> This patch adds baseline support for interrupt preemption. This lets one
> context (virtual SMP vcpu, PV driver, etc) preempt another vcpu which is
> currently in guest context when an interrupt is posted. The patch consists
> of the following:
>
> 1) Re-worked the vcp
This patch adds baseline support for interrupt preemption. This lets one
context (virtual SMP vcpu, PV driver, etc) preempt another vcpu which is
currently in guest context when an interrupt is posted. The patch consists of
the following:
1) Re-worked the vcpu mutex with a new "MPL" construct
10 matches
Mail list logo
