linux-kernel - Re: [PATCH RFC 0/2] kvm: Improving directed yield in PLE handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Jul 2012 10:41:56 +0530
From:	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
To:	Avi Kivity <avi@...hat.com>
CC:	Christian Borntraeger <borntraeger@...ibm.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Ingo Molnar <mingo@...hat.com>, Rik van Riel <riel@...hat.com>,
	S390 <linux-s390@...r.kernel.org>,
	Carsten Otte <cotte@...ibm.com>, KVM <kvm@...r.kernel.org>,
	chegu vinod <chegu_vinod@...com>,
	"Andrew M. Theurer" <habanero@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>, X86 <x86@...nel.org>,
	Gleb Natapov <gleb@...hat.com>, linux390@...ibm.com,
	Srivatsa Vaddagiri <srivatsa.vaddagiri@...il.com>,
	Joerg Roedel <joerg.roedel@....com>,
	Christian Ehrhardt <ehrhardt@...ux.vnet.ibm.com>,
	Alexander Graf <agraf@...e.de>,
	Paul Mackerras <paulus@...ba.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [PATCH RFC 0/2] kvm: Improving directed yield in PLE handler

On 07/11/2012 05:09 PM, Avi Kivity wrote:
> On 07/11/2012 02:18 PM, Christian Borntraeger wrote:
>> On 11/07/12 13:04, Avi Kivity wrote:
>>> On 07/11/2012 01:17 PM, Christian Borntraeger wrote:
>>>> On 11/07/12 11:06, Avi Kivity wrote:
>>>> [...]
>>>>>> Almost all s390 kernels use diag9c (directed yield to a given guest cpu) for spinlocks, though.
>>>>>
>>>>> Perhaps x86 should copy this.
>>>>
>>>> See arch/s390/lib/spinlock.c
>>>> The basic idea is using several heuristics:
>>>> - loop for a given amount of loops
>>>> - check if the lock holder is currently scheduled by the hypervisor
>>>>    (smp_vcpu_scheduled, which uses the sigp sense running instruction)
>>>>    Dont know if such thing is available for x86. It must be a lot cheaper
>>>>    than a guest exit to be useful
>>>
>>> We could make it available via shared memory, updated using preempt
>>> notifiers.  Of course piling on more pv makes this less attractive.
>>>
>>>> - if lock holder is not running and we looped for a while do a directed
>>>>    yield to that cpu.
>>>>
>>>>>
>>>>>> So there is no win here, but there are other cases were diag44 is used, e.g. cpu_relax.
>>>>>> I have to double check with others, if these cases are critical, but for now, it seems
>>>>>> that your dummy implementation  for s390 is just fine. After all it is a no-op until
>>>>>> we implement something.
>>>>>
>>>>> Does the data structure make sense for you?  If so we can move it to
>>>>> common code (and manage it in kvm_vcpu_on_spin()).  We can guard it with
>>>>> CONFIG_KVM_HAVE_CPU_RELAX_INTERCEPT or something, so other archs don't
>>>>> have to pay anything.
>>>>
>>>> Ignoring the name,
>>>
>>> What name would you suggest?
>>
>> maybe vcpu_no_progress instead of pause_loop_exited
>
> Ah, I thouht you objected to the CONFIG var.  Maybe call it
> cpu_relax_intercepted since that's the linuxy name for the instruction.
>

Ok, just to be on same page. 'll have :
1. cpu_relax_intercepted instead of  pause_loop_exited.

2. CONFIG_KVM_HAVE_CPU_RELAX_INTERCEPT which is unconditionally
selected for x86 and s390

3. make request mechanism to clear cpu_relax_intercepted.

('ll do same thing for s390 also but have not seen s390 code using 
request mechanism, so not sure if it ok.. otherwise we have to clear 
unconditionally for s390 before guest enter and for x86 we have to move 
make_request back to vmx/svm).
will post V3 with these changes.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/