linux-kernel - Re: [PATCH RFC V5 00/11] Paravirtualized ticketlocks

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]

Message-ID: <4E986B2B.60803@goop.org>
Date:	Fri, 14 Oct 2011 10:02:35 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Jason Baron <jbaron@...hat.com>
CC:	Peter Zijlstra <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Nick Piggin <npiggin@...nel.dk>, Avi Kivity <avi@...hat.com>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	KVM <kvm@...r.kernel.org>, Andi Kleen <andi@...stfloor.org>,
	Xen Devel <xen-devel@...ts.xensource.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	konrad.wilk@...cle.com
Subject: Re: [PATCH RFC V5 00/11] Paravirtualized ticketlocks

On 10/14/2011 07:17 AM, Jason Baron wrote:
> On Thu, Oct 13, 2011 at 09:44:48AM -0700, Jeremy Fitzhardinge wrote:
>> pvops is basically a collection of ordinary _ops structures full of
>> function pointers, but it has a layer of patching to help optimise it. 
>> In the common case, this just replaces an indirect call with a direct
>> one, but in some special cases it can inline code.  This is used for
>> small, extremely performance-critical things like cli/sti, but it
>> awkward to use in general because you have to specify the inlined code
>> as a parameterless asm.
>>
> I haven't look at the pvops patching (probably should), but I was
> wondering if jump labels could be used for it? Or is there something
> that the pvops patching is doing that jump labels can't handle?

Jump labels are essentially binary: you can use path A or path B.  pvops
are multiway: there's no limit to the number of potential number of
paravirtualized hypervisor implementations.  At the moment we have 4:
native, Xen, KVM and lguest.

As I said, pvops patching is very general since it allows a particular
op site to be either patched with a direct call/jump to the target code,
or have code inserted inline at the site.  In fact, it probably wouldn't
take very much to allow it to implement jump labels.

And the pvops patching mechanism is certainly general to any *ops style
structure which is initialized once (or rarely) and could be optimised. 
LSM, perhaps?

>> Jump_labels is basically an efficient way of doing conditionals
>> predicated on rarely-changed booleans - so it's similar to pvops in that
>> it is effectively a very ordinary C construct optimised by dynamic code
>> patching.
>>
> Another thing is that it can be changed at run-time...Can pvops be
> adjusted at run-time as opposed to just boot-time?

No.  In general that wouldn't really make sense, because once you've
booted on one hypervisor you're stuck there (though hypothetically you
could consider migration between machines with different hypervisors). 
In some cases it might make sense though, such as switching on PV
ticketlocks if the host system becomes overcommitted, but leaving the
native ticketlocks enabled if not.

    J
--
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/