[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <85acc922-2b76-3e52-1f77-c200949b0532@arm.com>
Date: Mon, 31 Jul 2017 14:42:25 +0100
From: Marc Zyngier <marc.zyngier@....com>
To: "Longpeng(Mike)" <longpeng2@...wei.com>, pbonzini@...hat.com,
rkrcmar@...hat.com
Cc: agraf@...e.com, borntraeger@...ibm.com, cohuck@...hat.com,
christoffer.dall@...aro.org, james.hogan@...tec.com,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
weidong.huang@...wei.com, arei.gonglei@...wei.com,
wangxinxin.wang@...wei.com, longpeng.mike@...il.com
Subject: Re: [RFC] KVM: optimize the kvm_vcpu_on_spin
On 29/07/17 07:22, Longpeng(Mike) wrote:
> We had disscuss the idea here:
> https://www.spinics.net/lists/kvm/msg140593.html
>
> I think it's also suitable for other architectures.
>
> If the vcpu(me) exit due to request a usermode spinlock, then
> the spinlock-holder may be preempted in usermode or kernmode.
> But if the vcpu(me) is in kernmode, then the holder must be
> preempted in kernmode, so we should choose a vcpu in kernmode
> as the most eligible candidate.
That seems to preclude any form of locking between userspace and kernel
(which probably wouldn't be Linux). Are you sure that this form of
construct is not used anywhere? I have the feeling this patch could
break this scenario...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists