linux-kernel - Re: Where do we stand with the Xen patches?

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: <alpine.DEB.1.10.0905171223250.26653@asgard>
Date:	Sun, 17 May 2009 12:25:38 -0700 (PDT)
From:	david@...g.hm
To:	devzero@....de
cc:	Jeremy Fitzhardinge <jeremy@...p.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: Where do we stand with the Xen patches?

On Sun, 17 May 2009, devzero@....de wrote:

>>> Aside from some whitespace issues around some Impact: lines, I
>>> don't know of any outstanding problems.  (I just pushed an updates
>>> to these branches to fix those, and fold a change to address
>>> Jesse's comment.)
>>>
>>> Please tell me if you have any further issues which prevents you
>>> from pulling these changes.  Otherwise I'd appreciate it if you
>>> pulled them soon, as we're already on -rc5, and I have more
>>> changes I'd like to prep for the next merge window.
>>
>> As in the past, my main worry is performance overhead of paravirt in
>> general.
>>
>> The patches that dont affect any native kernel fast path are
>> probably OK (but still pending final review).
>>
>> Regarding patches that do change the fastpath i'll do a round of
>> measurements of CONFIG_PARAVIRT against !CONFIG_PARAVIRT kernels,
>> and make up my mind based on that.
>>
>> You could accelerate this by sending some "perf stat" hard numbers
>> to give us an idea about where we stand today.
>>
>> 	Ingo
>
> maybe this is iust a stupid comment (please forgive, i?m no advanced kernel
> hacker), but can?t the code inserted by the patches and which changes the
> fastpath just #IFDEF`ed at the critical offsets ?  (as building a dom0 kernel is
> just another build target, isn`t it ?)

no, if dom0 is going to be widely deployed, it will be because the distros 
turn on dom0 support by default. as a result any penalties due to xen 
support will be felt by all users of those distros (even if they don't use 
xen)

David Lang
--
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/