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-next>] [day] [month] [year] [list]

Date:	Sun, 17 May 2009 21:46:15 +0200
From:	devzero@....de
To:	david@...g.hm
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: Where do we stand with the Xen patches?

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

so what?

print a huge warning on boot that running dom0 for xen may affect performance and that 
you should better run a normal kernel instead if you don`t use xen , and you`re done.

or is maintaining two different kernel packages a problem?

if so, instead of using IFDEF`s, can`t the critical path`s being generously circumvented 
by default, (if, else...), needing some dom0 kernel bootparam to be activated (i.e. use
the kernel as dom0 kernel) ?

or is this too short-sighted view of the things ?

regards
roland




______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

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