Мож для особо нетерпеливых доступен CVS разработчиков ? А то тут занимаюсь устаревшим el5-028.027. Ситуация такая. Как dom0 ядро -- претензий нет. Запускаются и domU, и VE. А вот если пытаюсь его использовать в rPath вместо родного domU-ядра, то 1) заметно медленнее грузится 2) не выскакивает логин. То есть загрузка сервисов прошла и все. Хотя удаленно можно подключиться по ssh. Поэтому создавать внутри domU VE я еще не пробовал. Хочется понять -- где проблема. И интересно узнать о прогрессе el5-028.034 относительно Xen.
текущий snapshot 034 патча может быть скачан отсюда: http://download.openvz.org/~dev/patch-028stab034-core этот патч на ядро EL5-8.1.4. не тестировался мной еще вообще (иммейте это ввиду). сейчас я собираю 034 ядро и отдаю на тестинг. С CVS вопрос пока не решен, т.к. помимо чисто технических деталей - есть и полу-политические, например, как быть с security fix'ами у которых есть embargo date?
Ядро собралось, но запускаться отказывается. Как dom0 (без PAE), так и domU. Вот что говорит domU: Freeing SMP alternatives: 16k freed Page beancounter hash is 16384 entries. Brought up 1 CPUs checking if image is initramfs... it is Freeing initrd memory: 3122k freed list_add corruption. prev->next should be c068bd6c, but was c0ad987c ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! invalid opcode: 0000 [#1] SMP last sysfs file: Modules linked in: CPU: 0, VCPU: 0.0 EIP: 0061:[<c04d5e14>] Not tainted VLI EFLAGS: 00010046 (2.6.18-fan_rh5_openvz_xen-028.034 #1) EIP is at __list_add+0x3c/0x58 eax: 00000048 ebx: c068bd6c ecx: c0ac5e44 edx: c0ac5e44 esi: c0ad926c edi: c0ad8c5c ebp: c0ad8660 esp: c0ac5e40 ds: 007b es: 007b ss: e021 Process swapper (pid: 1, veid: 0, ti=c0ac4000 task=c0ad9890 task.ti=c0ac4000) Stack: c0646b70 c068bd6c c0ad987c 00000000 c0adee08 c0ade8c8 c041bcf9 00000004 00000004 c0ac5ee0 00000000 00800711 c0ac5ee0 c0ae04a4 fffffff5 00800711 c041bfd1 00000000 00000000 00000000 c0ae04a4 00000000 00000000 c068d080 Call Trace: [<c041bcf9>] copy_process+0xc66/0xe77 [<c041bfd1>] do_fork_pid+0x6e/0x16b [<c04543c4>] buffered_rmqueue+0x105/0x122 [<c0430d2b>] kthread+0x0/0x9f [<c041c0f2>] do_fork+0x13/0x17 [<c0402c72>] kernel_thread+0xa3/0xad [<c0430d2b>] kthread+0x0/0x9f [<c0402bc4>] kernel_thread_helper+0x0/0xb [<c0430ddf>] keventd_create_kthread+0x15/0x4f [<c0430e95>] kthread_create+0x7c/0xba [<c0430dca>] keventd_create_kthread+0x0/0x4f [<c042dbde>] worker_thread+0x0/0x138 [<c042dea2>] create_workqueue_thread+0x79/0x90 [<c042dbde>] worker_thread+0x0/0x138 [<c042df5b>] __create_workqueue+0xa2/0xe9 [<c0402067>] init+0x0/0x141 [<c042e218>] init_workqueues+0x1b/0x33 [<c070e9b9>] do_basic_setup+0xf/0x23 init+0x51/0x14 Кстати, я пробовал собрать el5-028.027 без openvz, ибо не выдавался логин в domU (но sshd в domU работал). Так без openvz ядро в domU тоже не грузилось и говорило про invalid opcode 000 Этого я не понимаю... Собрать что ль чистое EL5-8.1.4
Собрал чистое ядро EL5-8.1.4 Оно нормально загрузилось как dom0-ядро. Как domU-ядро в том образе centos5, что я скачал из интернет, ведет себя так же, как и rh5_openvz_028.027. То есть проблема в security для console (при входе под непривелегированным пользователем ругается на отсутствие полномочий для /dev/null). Надо будет попробовать собрать rh5_openvz-028.027 с конфигом от ядра rPath (или просто убрать для начала selinux из конфига) Создавать domU под Virt-Manager (даже находясь в Scientific Linux 5) я не научился -- все попытки у меня заканчиваются ошибками Мож кто подскажет, у кого это получилось (под RHEL5-подобным дистром), какие URL надо подставлять при вопросе о дистрибутиве и KS? PS: да, после чтения документации по XEN от RH, понял, что при NFS-доступе к дистру, можно подставлять путь к ISO, вместо смонтированного содержимого ISO. Сейчас еще буду пробовать в SL5 самому создать domU.
Создать свой domU из Virt-Manager на этот раз получилось. В предыдущие разы я пытался указать URL из интернет. На этот раз я сделал доступным у себя по FTP содержимое установочного диска CentOS5 и немного уменьшил размер максимальной памяти для domU (212МБ, всего у меня 512). 256Мб для domU не удается выделить, так как существует ограничение на минимальную память для dom0 (248?), плюс около 48Мб отъедает сам Xen-монитор. PS: при указании завышенного RAM для domU (которое нельзя выделить), выдается сообщение о невозможности создать виртуальную машину
первая часть фиксится убиранием всех init_v0_process() из init_ve_system(). теперь проблема с самими VE. Я вам выдам полный патчик через какое-то время когда буду готов ставить ядро на билд.
patch 1: --- ./kernel/ve/veowner.c.ve2505 2007-06-07 12:43:15.000000000 +0400 +++ ./kernel/ve/veowner.c 2007-06-08 12:21:09.000000000 +0400 @@ -237,20 +237,6 @@ void init_ve_system(void) ve = get_ve0(); - /* Don't forget about idle tasks */ - write_lock_irqsave(&tasklist_lock, flags); - for (i = 0; i < NR_CPUS; i++) { - tsk = idle_task(i); - if (tsk == NULL) - continue; - - prepare_ve0_process(tsk); - } - do_each_thread_all(p, tsk) { - prepare_ve0_process(tsk); - } while_each_thread_all(p, tsk); - write_unlock_irqrestore(&tasklist_lock, flags); - init_entry = child_reaper; ve->init_entry = init_entry; /* if ve_move_task to VE0 (e.g. in cpt code) * patch2: --- a/net/sunrpc/sched.c +++ b/net/sunrpc/sched.c @@ -996,12 +996,12 @@ fail: void rpc_run_child(struct rpc_task *task, struct rpc_task *child, rpc_action func) { - rpc_set_active(task); + rpc_set_active(child); spin_lock_bh(&childq.lock); /* N.B. Is it possible for the child to have already finished? */ __rpc_sleep_on(&childq, task, func, NULL); - rpc_make_runnable(task); + rpc_make_runnable(child); spin_unlock_bh(&childq.lock); }
fixed patch-028stab034-core uploaded to the same URL
С исправленным патчем domU-ядро работает. А вот dom0-ядро лично у меня перегружается на попытке определить тип монитора через DDC ddcxinfo-knoppix -monitor Сейчас выкину это из загрузочных скриптов и попробую снова загрузиться
ok. чуть-чуть продвинулись. Не помню, мне Женя что-то говорил что у него и родной RHEL5 в Dom0 не работает...
Нет, родной работает. И полученный 028.034 dom0 работает. Только падает на ddcxinfo-knoppix. Без ddcxinfo-knoppix вроде все нормально. 028.027 -- не падает. С добавленными патчами openvz до 028.033 -- не падает. Похоже проблема с добавленными патчами, специфичными для rhel5. Может что-то для работы с большой памятью или обработкой bios-вызовов (ddcxinfo - он пытается пользовать vesa-вызова, как я понимаю) Как бы узнать список патчей от команды openvz, которые специфичны для ядра rhel5 (отсутствуют в чистом openvz)
Найдите два отличия... Вот возникли вопросы по поводу обсуждаемого rhel5-028.034. Первый: arch/i386/kernel/process.c (строка 322). Куда делись строки extern void kernel_thread_helper(void); EXPORT_SYMBOL(kernel_thread_helper); +__asm__(".section .text\n" + ".align 4\n" + ".global kernel_thread_helper\n" + "kernel_thread_helper:\n\t" + "movl %edx,%eax\n\t" + "pushl %edx\n\t" + "call *%ebx\n\t" + "pushl %eax\n\t" + "call do_exit\n" + ".previous"); В нормальном openvz в этом файле они присутствуют, и в данном варианте в файле process-xen.c тоже присутствуют (только строчка .global там есть?) Может это несущественно, но следующий patch тоже отсутствует diff -urN linux-2.6.18-openvzelx-028.030-orig/arch/i386/kernel/traps-xen.c linux-2.6.18-openvzelx-028.030/arch/i386/kernel/t --- linux-2.6.18-openvzelx-028.030-orig/arch/i386/kernel/traps-xen.c 2007-04-24 18:19:31.000000000 +0400 +++ linux-2.6.18-openvzelx-028.030/arch/i386/kernel/traps-xen.c 2007-04-24 18:20:05.000000000 +0400 @@ -748,6 +748,14 @@ static DEFINE_SPINLOCK(nmi_print_lock); +#ifdef CONFIG_SMP +int __attribute__((weak)) +smp_nmi_call_function(smp_nmi_function func, void *info, int wait) +{ + return 0; +} +#endif + void die_nmi (struct pt_regs *regs, const char *msg) { if (notify_die(DIE_NMIWATCHDOG, msg, regs, 0, 2, SIGINT) == По сравнению с traps.c еще отсутствует строчка void __attribute__((weak)) smp_show_regs(struct pt_regs *regs, void *info) {} перед этим Указанные патчи для файлов *-xen.c делались по аналогии с патчами openvz для файлов *.c. То есть если openvz вносит изменение в файл, для которого существует xen-аналог (дубль), то логично изменять также и этот дубль. PS: Указанные несоответствия обнаружились при попытке наложить на rhel5-028.027 patch 027to034 из GIT (хотелось найти различие между таким ядром и тем, что получается при наложении обсуждаемого патча) Рекомендуемое дополнение к 028.034: http://89.19.167.91/fantoo/patch-028stab034-core.ver02.addon Однако с проблемой ddcxinfo-knoppix это не помогло. Буду искать отличия 028.027+027to034 от 028.034
разница между 028.027+027to034 и обсуждаемым 028.034 получилась довольно большой -- 200 КЬайт. http://89.19.167.91/fantoo/028.034-git.patch Что бросилось в глаза: diff -urN linux-2.6.18-028.034.git/net/sunrpc/clnt.c linux-2.6.18-028.034/net/sunrpc/clnt.c --- linux-2.6.18-028.034.git/net/sunrpc/clnt.c 2007-06-11 03:57:23.000000000 +0400 +++ linux-2.6.18-028.034/net/sunrpc/clnt.c 2007-06-11 07:26:47.000000000 +0400 @@ -299,9 +299,7 @@ new->cl_autobind = 0; new->cl_oneshot = 0; new->cl_dead = 0; - new->cl_broken = 0; - if (!IS_ERR(new->cl_dentry)) - dget(new->cl_dentry); + new->cl_broken = 0; rpc_init_rtt(&new->cl_rtt_default, clnt->cl_xprt->timeout.to_initval); if (new->cl_auth) atomic_inc(&new->cl_auth->au_count); Это отсутствие в rhel5-варианте проверки на !IS_ERR Дальше не изучал. Относительно проблемы -- это наличие в rhel5-варианте изменений для arch/i386/kernel/vm86.c Именно эти изменения могли привести к перезагрузке dom0 по ddcxinfo-knoppix
Просьба: проанализировать изменения в файле arch/i386/kernel/vm86.c на предмет правильности работы в dom0. Ибо откат этих изменений позволил нормально отработать программе ddcxinfo-knoppix -monitor Ну и учесть рекомендуемый патч плюс замечание по net/sunrpc/clnt.c (отсутствует if (!IS_ERR(new->cl_dentry)))
С вот таким патчем для arch/i386/kernel/vm86.c тоже все работает (отличие -- добавили #else для случая CONFIG_X86_NO_TSS=y и старые команды для этого случая) --- arch/i386/kernel/vm86.c.old 2007-06-12 06:05:00.000000000 +0400 +++ arch/i386/kernel/vm86.c 2007-06-12 06:11:17.000000000 +0400 @@ -125,11 +125,15 @@ } #ifndef CONFIG_X86_NO_TSS - tss = &per_cpu(init_tss, get_cpu()); + tss = __get_cpu_tss(get_cpu()); #endif current->thread.esp0 = current->thread.saved_esp0; current->thread.sysenter_cs = __KERNEL_CS; +#ifndef CONFIG_X86_NO_TSS + load_virtual_esp0(tss, current); +#else load_esp0(tss, &current->thread); +#endif current->thread.saved_esp0 = 0; #ifndef CONFIG_X86_NO_TSS put_cpu(); @@ -305,14 +309,17 @@ savesegment(gs, tsk->thread.saved_gs); #ifndef CONFIG_X86_NO_TSS - tss = &per_cpu(init_tss, get_cpu()); + tss = __get_cpu_tss(get_cpu()); #endif tsk->thread.esp0 = (unsigned long) &info->VM86_TSS_ESP0; if (cpu_has_sep) tsk->thread.sysenter_cs = 0; - load_esp0(tss, &tsk->thread); + #ifndef CONFIG_X86_NO_TSS + load_virtual_esp0(tss, tsk); put_cpu(); +#else + load_esp0(tss, &tsk->thread); #endif tsk->thread.screen_bitmap = info->screen_bitmap;
Только что-то я не понимаю... Грузим в domU родное rhel5 ядро. Имеем SELinux и никакой ругани о установлении 4Gb segment limit. Берем тот же config и собираем rhel5_openvz_028.034. Никакого SELinux и ругань о 4Gb выравнивании почти для всех программ. С SELinux понятно -- если VE, то никаких SELinux. А вот ругань про выравнивание почти для всех программ -- понять причину не удалось. Похоже это из-за патча для очень большой памяти. Очень неприятный и надоедливый эффект. Или vm86.c менялся именно из-за этой ругани? Тогда изменили очень неправильно (без учета NO_TSS варианта). Так как тогда должен выглядеть vm86.c, чтоб и ddcxinfo-knoppix работал, и не было ругани Xen в domU для
kernel_thread_helper есть в arch/i386/kernel/entry.S: ENTRY(kernel_thread_helper) pushl $0 # fake return address for unwinder CFI_STARTPROC movl %edx,%eax push %edx CFI_ADJUST_CFA_OFFSET 4 call *%ebx push %eax CFI_ADJUST_CFA_OFFSET 4 call do_exit CFI_ENDPROC ENDPROC(kernel_thread_helper) в этом смысле разницы я не вижу, в i386 он в entry.S, в i386-xen в process-xen.c smp_nmi_call_function мы не стали бэкпортить так как это debug, который в xen нафиг не нужен (и не скорее всего в xen не работает, т.к. NMI IPI - он вряд ли умеет обрабатывать). меньше изменений - легче жить.
ouch... точно! я правда не понял к какой версии это патч, т.к. замена: #ifndef CONFIG_X86_NO_TSS - tss = &per_cpu(init_tss, get_cpu()); + tss = __get_cpu_tss(get_cpu()); #endif и в 034 и 035 уже есть. в результате я закоммитил в 036 вот такой патч: --- ./arch/i386/kernel/vm86.c.ve2555 2007-06-08 19:38:56.000000000 +0400 +++ ./arch/i386/kernel/vm86.c 2007-06-13 12:26:23.000000000 +0400 @@ -129,9 +129,7 @@ struct pt_regs * fastcall save_v86_state #endif current->thread.esp0 = current->thread.saved_esp0; current->thread.sysenter_cs = __KERNEL_CS; -#ifndef CONFIG_X86_NO_TSS load_virtual_esp0(tss, current); -#endif current->thread.saved_esp0 = 0; #ifndef CONFIG_X86_NO_TSS put_cpu(); @@ -313,8 +311,8 @@ static void do_sys_vm86(struct kernel_vm if (cpu_has_sep) tsk->thread.sysenter_cs = 0; -#ifndef CONFIG_X86_NO_TSS load_virtual_esp0(tss, tsk); +#ifndef CONFIG_X86_NO_TSS put_cpu(); #endif NOTE: load_virtal_esp0 и load_esp0 это одно и тоже в случае ядра Xen, так что #else не нужны. Огромное спасибо!
seyko2 wrote on Tue, 12 June 2007 18:55 Только что-то я не понимаю... Грузим в domU родное rhel5 ядро. Имеем SELinux и никакой ругани о установлении 4Gb segment limit. Берем тот же config и собираем rhel5_openvz_028.034. Никакого SELinux и ругань о 4Gb выравнивании почти для всех программ. можно поконкретнее что за ругань? какое сообщение? Quote: С SELinux понятно -- если VE, то никаких SELinux. А вот ругань про выравнивание почти для всех программ -- понять причину не удалось. Похоже это из-за патча для очень большой памяти. Очень неприятный и надоедливый эффект. давай-те его чинить Quote: Или vm86.c менялся именно из-за этой ругани? Тогда изменили очень неправильно (без учета NO_TSS варианта). Так как тогда должен выглядеть vm86.c, чтоб и ddcxinfo-knoppix работал, и не было ругани Xen в domU для нет, vm86.c менялся не из-за ругани, а в соответствие с 4gb split'ом. Когда эта фича включена, то TSS, GDT, LDT и прочее начинает управляться иным образом, поэтому и патч такой гигантский.
cl_dentry проверяется позже, так что проблемы нет.
Осталось только пропатчить include/asm/march-xen/asm/processor.h на предмет указанных define. Ибо хавается он, а не include/asm/processor.h diff -u include/asm/mach-xen/asm/processor.h.orig include/asm/mach-xen/asm/processor.h --- include/asm/mach-xen/asm/processor.h.orig 2007-06-14 00:15:55.000000000 +0400 +++ include/asm/mach-xen/asm/processor.h 2007-06-14 00:16:07.000000000 +0400 @@ -569,6 +569,32 @@ */ extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags); +#ifdef CONFIG_X86_HIGH_ENTRY +#define virtual_esp0(task) \ + ((unsigned long)((task)->thread_info->virtual_stack + ((task)->thread.esp0 - (unsigned long)(task)->thread_info->real_stack))) +#define load_virtual_esp0(tss, task) \ + do { \ + tss->esp0 = virtual_esp0(task); \ + if (likely(cpu_has_sep) && unlikely(tss->ss1 != (task)->thread.sysenter_cs)) { \ + tss->ss1 = (task)->thread.sysenter_cs; \ + wrmsr(MSR_IA32_SYSENTER_CS, \ + (task)->thread.sysenter_cs, 0); \ + } \ + } while (0) + +#else + +#define virtual_esp0(task) ((task)->thread.esp0) +#define load_virtual_esp0(tss, task) load_esp0(tss, &(task)->thread) + +#endif + +#ifndef CONFIG_XEN +#define __get_cpu_tss(cpu) (init_tss + (cpu)) +#else +#define __get_cpu_tss(cpu) (&per_cpu(init_tss, cpu)) +#endif + extern unsigned long thread_saved_pc(struct task_struct *tsk); void show_trace(struct task_struct *task, struct pt_regs *regs, unsigned long *stack); И что конкретно делать для остальных файлов в этом каталоге? openvz пропатчил кучу файлов в include/asm, аналоги которых есть в include/asm/mach-xen/asm desc.h fixmap.h highmem.h kmap_types.h mmu.h mmu_context.h page.h pgtable.h processor.h system.h tlbflush.h Попытка пропатчить эти файлы по аналогии -- провалилась. Ибо тогда вылезает куча проблем с компиляцией. Получается, что для XEN-архитектуры BIG-mem patch применился лишь частично и работать не будет. Можно поиметь этот BIG-mem patch в отдельном виде? Да, а ругается в domU файл arch/i386/kernel/fixup.c Собрал сам на всякий случай ядро rhel5 (для проверки особенностей сборки). Оно, как и оригинальное ядро от RH, не ругается...
seyko2 wrote on Thu, 14 June 2007 00:28 Осталось только пропатчить include/asm/march-xen/asm/processor.h на предмет указанных define. Ибо хавается он, а не include/asm/processor.h блин, облажался... %( все время забываю что они накопировали код :/ Quote: diff -u include/asm/mach-xen/asm/processor.h.orig include/asm/mach-xen/asm/processor.h --- include/asm/mach-xen/asm/processor.h.orig 2007-06-14 00:15:55.000000000 +0400 +++ include/asm/mach-xen/asm/processor.h 2007-06-14 00:16:07.000000000 +0400 @@ -569,6 +569,32 @@ */ extern int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags); +#ifdef CONFIG_X86_HIGH_ENTRY +#define virtual_esp0(task) \ + ((unsigned long)((task)->thread_info->virtual_stack + ((task)->thread.esp0 - (unsigned long)(task)->thread_info->real_stack))) +#define load_virtual_esp0(tss, task) \ + do { \ + tss->esp0 = virtual_esp0(task); \ + if (likely(cpu_has_sep) && unlikely(tss->ss1 != (task)->thread.sysenter_cs)) { \ + tss->ss1 = (task)->thread.sysenter_cs; \ + wrmsr(MSR_IA32_SYSENTER_CS, \ + (task)->thread.sysenter_cs, 0); \ + } \ + } while (0) + +#else + +#define virtual_esp0(task) ((task)->thread.esp0) +#define load_virtual_esp0(tss, task) load_esp0(tss, &(task)->thread) + +#endif + +#ifndef CONFIG_XEN +#define __get_cpu_tss(cpu) (init_tss + (cpu)) +#else +#define __get_cpu_tss(cpu) (&per_cpu(init_tss, cpu)) +#endif + extern unsigned long thread_saved_pc(struct task_struct *tsk); void show_trace(struct task_struct *task, struct pt_regs *regs, unsigned long *stack); А как Вам такой вариант: --- ./arch/i386/Kconfig.ve9992 2007-06-08 19:39:07.000000000 +0400 +++ ./arch/i386/Kconfig 2007-06-14 14:58:27.000000000 +0400 @@ -223,6 +223,7 @@ source "arch/i386/Kconfig.cpu" config X86_4G bool "4 GB kernel-space and 4 GB user-space virtual memory support" + depends on !X86_XEN help This option is only useful for systems that have more than 1 GB of RAM. --- ./include/asm-i386/mach-xen/asm/processor.h.ve9992 2007-06-08 19:39:07.000000000 +0400 +++ ./include/asm-i386/mach-xen/asm/processor.h 2007-06-14 15:04:30.000000000 +0400 @@ -535,6 +535,9 @@ static inline void __load_esp0(struct ts HYPERVISOR_stack_switch(__KERNEL_DS, (thread)->esp0) #endif +#define load_virtual_esp0(tss, task) load_esp0(tss, &(task)->thread) +#define __get_cpu_tss(cpu) (&per_cpu(init_tss, cpu)) + #define start_thread(regs, new_eip, new_esp) do { \ __asm__("movl %0,%%fs ; movl %0,%%gs": :"r" (0)); \ set_fs(USER_DS); \ Quote: И что конкретно делать для остальных файлов в этом каталоге? openvz пропатчил кучу файлов в include/asm, аналоги которых есть в include/asm/mach-xen/asm desc.h fixmap.h highmem.h kmap_types.h mmu.h mmu_context.h page.h pgtable.h processor.h system.h tlbflush.h Попытка пропатчить эти файлы по аналогии -- провалилась. Ибо тогда вылезает куча проблем с компиляцией. Получается, что для XEN-архитектуры BIG-mem patch применился лишь частично и работать не будет. мое IMHO: ничего не делать. в Xen'е нафиг не нужен 4/4GB split, и боюсь он там просто напросто и работать-то не будет без серьезных усилий, потому как вещь это сильно завязанная на архитектуру, а Xen как раз меняет по сути архитектурный код. А самое главное в этой фичи особого смысла нет для Xen'а - она нужна чтобы запускать как можно больше VE на i386. Quote: Можно поиметь этот BIG-mem patch в отдельном виде? Да, конечно. http://download.openvz.org/~dev/patches-035-ovz/ все патчи начинающиеся на diff-arch-4g Quote: Да, а ругается в domU файл arch/i386/kernel/fixup.c Собрал сам на всякий случай ядро rhel5 (для проверки особенностей сборки). Оно, как и оригинальное ядро от RH, не ругается... Вопрос: а оно ругается если не стартовать VE? На какие процессы хотя бы жалуется? Насколь я понимаю из описания оно должно жаловаться на glibc у которой TLS support собран как-то по старому. Наверняка, в каких-то VE как раз это и происходит. На хосте по идее все должно быть пучком.
За патчи спасибо! Про ругань: запускаем только domU (centos5) с нашим ядром и почти на все процессы идут сообщения о 4gb seg fixup (по 4 тысячи на процесс). Тот же centos5 с родным ядром (собранным из исходников по той же технологии) не ругается. VE в domU пока даже не пахнет (не пытаемся пока запускать). Ругань -- обеспечивает Xen-монитор (xen/arch/x86/x86_32/seg_fixup.c) по запросу domU-ядра, когда он выполняет фиксацию размеров сегментов (он вызывает как call-back функцию из arch/i386/kernel/fixup.c). В openvz-ядре с размером сегментов что-то не так (с прописыванием их размеров), ибо меняется только ядро (родное или openvz). glibc здесь не меняется и не виновата в выдаче сообщений. Можно конечно подавить выдачу предупреждений (в Xen-мониторе не вызывать callback-функцию), но это как-то не кузяво. PS: по имеющемуся опыту эксплуатации rhel5-openvz-ядро -- наиболее стабильное 2.6.18-ядро под Xen. Пытался несколько раз работать под Xen-3.1-ядром (с openvz и без) и все как-то неудачно -- ядро часто через некоторое время начинало тормозить и глюкавить.
вероятно опять-таки виноват 4GB split, но я пока не понимаю как... :/
Кстати, буду премного благодерн если Вы найдете время и силы как-нибудь посмотреть на эту wiki страничку: https://wiki.openvz.org/How_to_use_OpenVZ_as_a_XEN_guest_OS_ %28for_x86_platform%29 Предупреждаю сразу, она совсем не кузява :/, т.к. писал человек не очень опытный. Поэтому буду очень благодарен за помощь в ее доведении до ума.
Вот как выглядят сообщения EXT3-fs: mounted filesystem with ordered data mode. 4gb seg fixup, process init (pid 1), cs:ip 73:00a2c760 4gb seg fixup, process init (pid 1), cs:ip 73:00a2c760 4gb seg fixup, process init (pid 1), cs:ip 73:00aa1b69 4gb seg fixup, process init (pid 1), cs:ip 73:00a2fd5c 4gb seg fixup, process init (pid 1), cs:ip 73:00a2fd6a 4gb seg fixup, process init (pid 1), cs:ip 73:00a2fd5c 4gb seg fixup, process init (pid 1), cs:ip 73:00a2fd6a 4gb seg fixup, process init (pid 1), cs:ip 73:009eab7b 4gb seg fixup, process init (pid 1), cs:ip 73:009eab64 4gb seg fixup, process init (pid 1), cs:ip 73:00a358b5 printk: 109680 messages suppressed. 4gb seg fixup, process hwclock (pid 276), cs:ip 73:0052c480 4gb seg fixup, process hwclock (pid 276), cs:ip 73:490ce6f6 4gb seg fixup, process hwclock (pid 276), cs:ip 73:005b00c8 printk: 567140 messages suppressed. 4gb seg fixup, process S14nfslock (pid 2477), cs:ip 73:0090a85e printk: 705301 messages suppressed. 4gb seg fixup, process modprobe (pid 2671), cs:ip 73:00bd7811 printk: 555473 messages suppressed. 4gb seg fixup, process S90xfs (pid 2823), cs:ip 73:0071185e А вот openvz-ядро без 4-gb-патчей: EXT3-fs: mounted filesystem with ordered data mode. 4gb seg fixup, process init (pid 1), cs:ip 73:00cbf760 4gb seg fixup, process init (pid 1), cs:ip 73:00d34b69 4gb seg fixup, process init (pid 1), cs:ip 73:00cc2d5c 4gb seg fixup, process init (pid 1), cs:ip 73:00cc2d6a 4gb seg fixup, process init (pid 1), cs:ip 73:00cc2d5c 4gb seg fixup, process init (pid 1), cs:ip 73:00cc2d5c 4gb seg fixup, process init (pid 1), cs:ip 73:00cc2d6a 4gb seg fixup, process init (pid 1), cs:ip 73:00c7db7b 4gb seg fixup, process init (pid 1), cs:ip 73:00c7db64 4gb seg fixup, process init (pid 1), cs:ip 73:00cc88b5 printk: 109695 messages suppressed. 4gb seg fixup, process hwclock (pid 276), cs:ip 73:00506480 4gb seg fixup, process hwclock (pid 276), cs:ip 73:490ce6f6 4gb seg fixup, process hwclock (pid 276), cs:ip 73:0058a0c8 Сообщения хоть и со смещением, но в тех же местах. Получается, что 4-gb-патч не виноват
А вообще это сообщение выдается при выполнеии инструкции в пользовательской программе, которая обращается к памяти данных с использованием GS: и прерывается по защите памяти, если смещение велико и попадает в область памяти, занимаемой Xen-монитором (реальный 4Gb сегмент). Ками-то образом программы получают от openvz-ядра сегмент для данных, который не урезан с учетом Xen.
Про Wiki-страничку... Странно... xen-3.1.0 использует 2.6.18 ядро, а не 2.6.16 Вдобавок лучше все же описать установку стандартного xen-монитора и ядра dom0 из дистрибутива, а не с сайта xensource (хотя последнее описание для меня было достаточно полезно). Все же RHEL5 долго вылизывала именно свою версию dom0. В описании пунктов меню для grub лучше опустить указание root(hd0,1). Это плохая практика (ухудшает переносимость на другие диски). Все прекрасно грузится и без этой строчки. Про tls лучше опустить -- в RHEL5 с этим все в ажуре. Или указать конкретно, что совет -- для дистров с glibc-2.3 Какой openvz-xen мы устанавливаем? dom0? domU? Надо бы четче указать. Quote: OpenVZ XenLinux kernel is able to work also in Dom0. It can be tested just by updating /etc/grub.conf on the hardware node. But in this case it will be impossible to start DomUs. It is a known bug and it is related not to OpenVZ, but to RHEL5 kernel. Странно... А у меня openvz в dom0 работает, запускает domU и VE. Вот в domU оно ругается на 4gb seg fixup. Но работает. Другие ядра для domU (родные) работают и не ругаются. Так какой-же xen использовали при написании Wiki? 3.1? И при использовании xen-3.1 openvz-028.34 в domU не вызывает ругани про 4gb seg? Очень интересно. Сейчас проверю... PS: да, а машина то у нас при написании Wiki была обычная x86-32 или x86-64? А то ругань то только в x86-32 происходит.
С xen-3.1 тоже ругается. Вполне возможно это из-за того, что у меня в конфигурации памяти выбрано 4Gb, а не 64Gb (то бишь не PAE) и не default. Но ядро от RHEL5 в той же конфигурации в domU не ругается... Допускаю, что xen-3.1 для PAE как-то оптимизировали и он уже не ругается на 4Gb seg fixup при использовании в domU openvz-xen-028.034 Это верно? PS: сейчас собираю ядро с default для памяти (то бишь < 1Gb). По идее в этом случае ругаться на 4gb fixup тоже не должно.
0x73 это селектор __USER_CS #define __USER_CS (GDT_ENTRY_DEFAULT_USER_CS * 8 + 3) давайте тогда сделаем objdump -dr /sbin/init и hwclock и посмотрим что за инструкция по указанным IP адресам. Хмм... 4GB split был первым кандидатом... а я правильно понимаю, что на 027 ядре этого не было? не вижу ни одного патча из этого списка что могли бы повлиять: diff list-028stab027 list-028stab037 3c3,13 < # Based on 2.6.18-8.1.1.el5 kernel --- > # Based on 2.6.18-8.1.4.el5 kernel > > # -------------------------------------------- > # 4gb split > diff-arch-4gb-20070409-2 > diff-arch-4gb-cr4-20070410 # to LKML > diff-arch-x86-ioremap-guard-page-fix-20070419 > diff-arch-4gb-ldt-irqs-20070515 > diff-arch-4gb-xen-20070523 > diff-arch-4gb-xen-cleanup-20070528 > diff-arch-4gb-xen-b-20070613 23a34 > namespaces-utsname-xen.patch 46a58 > io-accounting-menuconfig.patch 71a84 > diff-ms-cpufreq-centrino-20070426 78a92,94 > diff-ms-cfq-allow-merge-b-20070424 > diff-ms-cfq-allow-merge-c-20070507 > diff-ms-cfq-rm-redundant-find-next-req-20070509 91a108,110 > diff-ms-ext3-iread-brelse-20070601 > diff-ms-ext3-orhpan-list-corruption-20070531 > diff-ms-ext3-orhpan-list-corruption-b-20070603 93a113,147 > diff-ms-lockdep-neighbour-table-class-20070409 > diff-ms-bridge-unaligned-access-20070411 # send to LKML > diff-ms-stopmachine-msleep-20070411 # send to LKML > diff-ms-elf-retval-20070420 # send to LKML > diff-ms-loop-dont-complete-lo-bh-done-20070418 > # diff-ms-fib-netlink-lookup-recursion-20070425 > # diff-ms-fib-netlink-lookup-recursion-b-20070425 > # `- linux-2.6-net-fix-user-oops-able-bug-in-fib-netlink.patch > diff-ms-slab-numa-bind-20070514 > diff-ms-futex-locking-bug-20070510 > diff-ms-futex-oops-20070510 > diff-ms-nfs-rm-warn-20070515 > diff-ms-sparc64-compilation-20070523 > diff-ms-powerpc-compilation-20070523 > diff-ms-nfs-odirect-20070529 > diff-ms-nfs-umount-refcnt-leak-20070530 > diff-ms-nfs-schedlock-20070530 > diff-ms-nfs-launder-20070530 > diff-ms-seqfile-seek-20070601 > diff-ms-ia64-nat-ptrace-20070604 > diff-ms-net-ipv6-privacy-msg-20070605 > diff-ms-entropy-fix-a-20070530 # CVE-2007-2453 > diff-ms-entropy-fix-b-20070530 # CVE-2007-2453 > diff-ms-security-cpuset-20070605 # CVE-2007-2875 > diff-ms-security-sctp-20070604 # CVE-2007-2876 >> > diff-ms-fuse-nlookup-20070521 > diff-ms-fuse-spurious-bug-20070521 > diff-ms-fuse-dentry-parent-20070521 > diff-ms-fuse-oops-in-lookup-20070521 > diff-ms-fuse-bug-control-fs-20070521 > diff-ms-fuse-validate-rootmode-20070521 > diff-ms-fuse-mknod-of-regular-file-20070521 > > # diff-ms-fatal-signal-20070413 108c162 < diff-bug-macro-tune-20060310 # Send to LKML --- > diff-bug-macro-tune-20060310-2 # Send to LKML 134a189 > diff-sysrq-debug-b-20070511 159a215 > diff-rh-mmap-return-addr-b-20070608 170a227 > diff-ms-vfs-get-host-20070515 174c231,232 < diff-ms-nmi-wdog-timeout-20070328 --- > # diff-ms-nmi-wdog-timeout-20070328 > # `- linux-2.6-nmi-change-watchdog-timeout-to-30-seconds.patch 178,179c236,237 < diff-ms-net-bridge-via-eth-20070311 < diff-rh-utrace-update-20070320 --- > # diff-rh-utrace-update-20070320 > # `- linux-2.6-utrace-exploit-and-unkillable-cpu-fixes.patch 180a239,240 > diff-rh-dlm-misc-device-fix-20070412 > diff-ms-bridge-nf-ebt-among-20070607 189d248 < # diff-ve-sysctl-allow-kthreads-20061018 224c283 < diff-ubc-kmem-20060830-3 --- > diff-ubc-kmem-20060830-4 349a409,425 > diff-ubc-refcount-leak-dupmm-20070409 > diff-ubc-vmguar-enough-null-mm-20070406 > diff-ubc-page-uncharge-bug-first-20070406 > diff-ubc-percpu-sign-expansion-20070410 > diff-ubc-dcache-uncharge-root-20070413 > diff-ubc-put-beancounters-in-fork-20070416 > diff-ubc-io-release-debug-20070416 > diff-ubc-unusedprivvm-in-zeromap-20070424 > diff-ubc-off-20070424 > diff-ubc-dentry-acentry-20070510 > diff-ubc-dentry-free_block-20070510 > diff-ubc-dentry-free_alien-20070510 > diff-ubc-dentry-free_alien-b-20070521 > diff-ubc-cleanup-20070517 > diff-ubc-proc-rework-b-20070515 > diff-ubc-proc-rework-c-20070604 > diff-ubc-unix-exports-20070604 379a456,464 > diff-ubc-ioprio-clean-active-ub-20070411 > diff-ubc-ioprio-oops-on-virt-off-20070423 > diff-ubc-ioprio-force-disp-off-20070424 > diff-ubc-ioprio-range-prio-20070623 > diff-ubc-ioprio-slice-scaling-20070623 > diff-ubc-ioprio-on-dispatch-check-20070523 > > diff-ubc-ioacct-context-handle-20070413 > diff-ubc-top-beancounter-20070515 427a513 > diff-ve-meminfo-b-20070330 506a593 > diff-ve-futex-vpid-fix-20070413 520c607 < diff-ve-sysctl-allow-kthreads-20061018 --- > diff-ve-sysctl-allow-kthreads-20061018-2 573a661 > diff-ve-tun-persist-20070424 602a691,708 > diff-ve-kconfig-security-deps-20070411 > diff-ve-netlink-veprintk-20070426 > diff-ve-xen-netback-20070426 > diff-ve-pid-nr-fix-20070503 > diff-ve-showmem-locking-20070414 > diff-ve-init-signals-20070514 > diff-ve-proc-hash-pid-dentries-20070516 > diff-ve-cap-bset-20070504 > diff-ve-net-arp-set-perms-20070625 > diff-ve-cpustats-20070528 > diff-ve-setattr-proc-20070524 > diff-ve-setattr-proc-kmsg-20070524 > diff-ve-setattr-proc-b-20070604 > diff-ve-syslog-20070601 > diff-ve-reparent-threaded-init-20070604 > diff-ve-vpsdumpable-early-20070604 > diff-ve-oom-adjust-20070604 > diff-ve-prepare-ve0-tasks-20070608 626a733,736 > diff-ve-venet-stoprace-20070412 > diff-ve-net-veth-addr-macro-20070514 > diff-ve-net-veth-multicast-20070604 > diff-ve-net-veth-filtering-b-20070605 640a751,756 > diff-ve-nfs-hostcache-20070510 > diff-ve-nfs-stop-20070502 > diff-ve-nfs-stop-b-20070502 > diff-ve-nfs-abortset-20070504 > diff-ve-nfs-tcpabort-20070522 > diff-ve-nfs-abortcorrupt-20070523 665a782,784 > diff-ve-nf-ipt6-aliasing-20070515 > diff-ve-ip-nat-aliasing-20070605 > diff-ve-ip-nat-aliasing-b-20070607 680a800,804 > # bridges over ETH > diff-ms-net-bridge-via-eth-20070311 > diff-ve-net-bridge-via-phys-dev2-20070514 > diff-ms-net-bridge-via-eth-c-20070613 > 717a842,849 > diff-vzdq-sleep-under-inode-lock-20070412 > diff-vzdq-ugbad-20070428 > diff-vzdq-ppc32-comp-20070518 > diff-vzdq-putsuper-20070518 > diff-vzdq-aquota-group-len-20070521 > diff-vzdq-atomic-in-buildmntlist-20070521 > diff-vzdq-for-gfs-20070521 > diff-vzdq-restore-symlinks-under-sem-20070524 723c855 < diff-cpt-exports-4 --- > diff-cpt-exports-5 770a903 > diff-cpt-inotify-core-b-20070529 842a976 > diff-cpt-kill-external-processes-b-20070515 852a987 > diff-cpt-ubc-adjust-on-restore-c-20070601 863a999,1000 > diff-cpt-4gbsplit-ldt-20070410 > diff-cpt-off-lockdep-on-sockets-20070413 868a1006,1035 > diff-cpt-make-zombie-20070413 > diff-cpt-make-zombie-b-20070420 > diff-cpt-zombie-threads-20070416 > diff-cpt-robust-list-20070413 > diff-cpt-active-callback-eagain-20070423 > diff-cpt-restore-netlink-socket-20070419 > diff-cpt-suspend-cleanup-20070510 > diff-cpt-prevent-vm-changes-20070510 > diff-cpt-features-known-mask-20070514 > diff-cpt-futex-eintr-20070510 > diff-cpt-cap-bset-20070504 > diff-cpt-xen-ldt-20070523 > diff-cpt-wait-fix-20070518 > diff-cpt-wait-fix-b-20070518 > diff-cpt-wait-fix-c-20070601 > diff-cpt-mm-deadlock-20070523 > diff-cpt-restore-lastpid-20070604 > diff-cpt-pids-leak-20070525 > diff-cpt-rst-file-error-msg-20070601 > diff-cpt-namespace-deadlock-20070604 > diff-cpt-ia64-nat-20070604 > diff-cpt-improve-align-20070604 > diff-cpt-compilation-warning-20070604 > diff-cpt-ia64-unaligned-suppress-20070604 > diff-cpt-check-iptables-modules-20070604 > diff-cpt-restore-deleted-files-20070502 > diff-cpt-deleted-ref-20070502 > diff-cpt-deleted-ref-b-20070613 > diff-cpt-restore-packet-socket-20070606 > 870a1038,1040 > # Required for VZ only: > diff-cpt-aux-task-list-20070604 > 890a1061 > diff-fairsched-ppc-syscalls-fix3-20070525 910c1081 < diff-fairsched-get-normal-vemask-20061220 --- > diff-fairsched-get-normal-vemask-20061220-2 922a1094 > diff-fairsched-find-idle-vcpu-20070403 925a1098,1099 > diff-fairsched-best-vcpu-20070413 > diff-fairsched-best-vcpu-b-20070423 928a1103,1111 > diff-fairsched-unused-rq-20070424 > diff-fairsched-dyn-vcpu-timeslice-20070518 > diff-fairsched-vcpuoff-comp-20070426 > diff-fairsched-rename-vcpu-info-20070517 > diff-fairsched-x8664-show-regs-20070528 > diff-fairsched-boot-cpu-20070530 > diff-fairsched-preempt-20070529 > diff-fairsched-iowait-fix-20070624 > diff-fairsched-tickduration-20070528 931a1115,1122 > > diff-ms-dcache-fix-quadratic-shrink > diff-ubc-move-might-sleep-20070517 > > # Xen fixes here and there... > diff-ve-xen-blktapmain-20070514 > diff-xen-subarch-changes-20070528 > diff-ms-net-settimeout-20070525 [/code]
я так понимаю в GS загружают что-то из LDT. В LDT есть только два вида selector'ов: default и юзер. юзер селекторы создаются через write_ldt(). никаких подпорок в arch/i386/kernel/ldt-xen.c :: write_ldt() на эту тему я не вижу... более того, судя по всему hypervisor сам этим управляет... default_ldt[] находится в traps-xen.c и не менялся: struct desc_struct default_ldt[] = { { 0, 0 }, { 0, 0 }, { 0, 0 }, { 0, 0 }, { 0, 0 } }; так что пока я в замешательстве... какой хоть номер в этом месте у GS?
боюсь что на Ваш вопрос про оптимизацию ответить не в состоянии ;/ я в Xen вообще толком не копался еще
Похоже, причина проблемы найдена. Она в том, что для openvz-варианта порушена работа VDSO. Проблемный патч openvz -- diff-cpt-vsyscall-disable. Вот его кусок: --- ./fs/exec.c.ve254 2006-08-29 10:47:09.000000000 +0400 +++ ./fs/exec.c 2006-08-29 10:47:09.000000000 +0400 @@ -66,6 +66,8 @@ int suid_dumpable = 0; EXPORT_SYMBOL(suid_dumpable); /* The maximal length of core_pattern is also specified in sysctl.c */ +int sysctl_at_vsyscall; + static struct linux_binfmt *formats; static DEFINE_RWLOCK(binfmt_lock); --- ./include/asm-i386/elf.h.ve254 2006-08-29 10:47:08.000000000 +0400 +++ ./include/asm-i386/elf.h 2006-08-29 10:47:54.000000000 +0400 @@ -162,7 +162,7 @@ extern int arch_setup_additional_pages(s extern unsigned int vdso_enabled; #define ARCH_DLINFO \ -do if (vdso_enabled) { \ +do if (vdso_enabled && sysctl_at_vsyscall) { \ NEW_AUX_ENT(AT_SYSINFO, VDSO_ENTRY); \ NEW_AUX_ENT(AT_SYSINFO_EHDR, VDSO_COMPAT_BASE); \ } while (0) Можно заметить, что sysctl_at_vsyscal не инициализируется и соответственно равен 0. Поэтому ARCH_DLINFO не работает даже если vdso_enabled равно 1. Хотелось бы узнать, что замышлялось под sysctl_at_vsyscall... Устанавливать sysctl_at_vsyscall еще не пробовал, но то, что vdso не работает -- проверено. Конкретно билиотеки из /lib/i686/nonsegng переписаны в /lib и сообщения о 4gb seg fixup пропали. При рабочем vdso линкер сам берет библы из /lib/i686/nonsegneg PS: теперь я понимаю, почему в Wiki openvz-xen не работала в dom0 Потому что базовой системой была RHEL5. А у меня -- gentoo, собранный весь под Xen: CFLAGS="$CFLAGS -mno-tls-direct-seg-refs" У меня -- не ругалась. А в случае Wiki должна была ругаться по-страшному и в dom0.
При замене проблемного кода на #define ARCH_DLINFO \ do { \ NEW_AUX_ENT(AT_SYSINFO, VDSO_ENTRY); \ NEW_AUX_ENT(AT_SYSINFO_EHDR, VDSO_COMPAT_BASE); \ } while (0) проблема исчезла (решена). Ранее собирал с #define ARCH_DLINFO \ do if (vdso_enabled) { \ NEW_AUX_ENT(AT_SYSINFO, VDSO_ENTRY); \ NEW_AUX_ENT(AT_SYSINFO_EHDR, VDSO_COMPAT_BASE); \ } while (0) (это более правильный вариант для x86-32), но почему-то этот вариант не сработал. Возможно -- виноват какой-то глюк и сейчас повторно собираю с этим вариантом PS: да, и второй вариант правильно работает (вероятно в первый раз промахнулся и собрал что-то другое).
ok. будем думать. надо еще разобраться в очередной раз с CPT vs. vsyscall на i386...
Этому 4g seg fix конца нет.... Собрал ядро с правильным include/asm/elf.h Нормально, без ругани запустил с этим ядром в domU centos5a. Читая Wiki, делаю в domU VE 134 на основе fedora-core-5-i386-minimal и запускаю. Так на тебе, опять ругань про 4g seg fix Каким образом в domU VE перестает действовать ARCH_DLINFO ? Может вообще убрать vdso_enabled? А то получается, что в VE этот vdso_enabled равен 0 PS: в dom0 этот самый 134 VE -- не ругается. А в domU -- ругается. Пересборка ядра (выкинул вообще if vdso_enabled) не помогла -- все равно ругается в domu-ve. Замена glibc в 134 domu-ve, конечно, помогает (пишем из /lib/i686/nonsegneg в /lib). Но запустить сеть в domu-ve мне не удалось. То есть виртуальный venet сконфигурирован, сам себя пингует, а domu -- не видит. Возможно из-за того, что в centos что-то мешает этому. Я не спец по centos. Но iptables я останавливал. Возможно, в domU надо настроить sysctl (забыл про это). PPS: возможно что-то сглючило, но rhel5-openvz-028.035 (без xen) не загрузился. До этого я собирал 028.034 и вроде все грузилось... Ой, мамочка, точно не грузится (во второй раз пересобрал полностью). Зависает (что-то там внутри себя наверно делает) после вывода сообщения "Loading initramfs...." Неужели из-за diff --git a/kernel/ve/vecalls.c b/kernel/ve/vecalls.c index d1b55a8..5ade018 100644 --- a/kernel/ve/vecalls.c +++ b/kernel/ve/vecalls.c @@ -1193,7 +1193,7 @@ static int do_ve_iptables(struct ve_struct *ve, __u64 init_mask, init_mask &= ~VE_IP_IPTABLES6; init_mask &= ~VE_IP_FILTER6; init_mask &= ~VE_IP_MANGLE6; - init_mask &= ~VE_IP_IPTABLE_NAT; + init_mask &= ~VE_IP_IPTABLE_NAT_MOD; if ((init_mask & VE_IP_IPTABLES) == VE_IP_IPTABLES) init_mask |= VE_IP_IPTABLES6; if ((init_mask & VE_IP_FILTER) == VE_IP_FILTER) Проверил, не грузится 028.034 тоже. Очень вероятно, что из-за vm86.patch (теперь он подходит для xen, а без Xen не работает). Буду пока собирать rhel5-openvz (без Xen) без этого патча.
sysctl_at_vsyscall ввели еще в 2.6.8.1 ядре для отключения vsyscall страницы. Потом в мейнстримном ядре была добавлена своя переменная для этого vdso_enabled, а этот патч забыли выкинуть. Так он и тянется до сих пор. Надо будет его откатить, т.к. сейчас он уже не нужен.
Если откатите, то будут проблемы (у меня зависало на этапе запуска initramfs). То есть при включенном vdso_enable на обычном rhel5-openvz-ядре (028.034 и выше, не Xen, ниже не проверял) возможны проблемы. Самое интересное, что при сборке для Xen проблем нет и все почти работает. Не работает vdso только в VE под domU. В самом domU и в VE под dom0 -- работает. Про работу vdso в dom0 ничего сказать не могу, так как еще не пробовал эти ядра запускать на RHEL5-дистре (пока для dom0 использую Gentoo) PS: в принципе, не так уж сложно ручками заменить либы в /lib на нужные (для исключения проблем при неработающем vdso)