[Xen-ia64-devel] Re: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
Le Mercredi 01 Mars 2006 02:30, Xu, Anthony a écrit : It is likely some subtle difference (or bug), perhaps in mmap? Hi all, yesterday I got the same bug as Akio. Today it is working again. I have just reinstalled tools+xen+kernel. Akio, could you try to reinstall xen+tools+kernel using a clean repository ? (make clean may be not enough). It seems *really* strange that only a few of us got the bug because it seems to be related only to Xen+Xenstore+Linux. Therefore it should not depend on the distribution. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Why is cpl read as 0 in para-virtualization ?
Subject: [Xen-ia64-devel] Why is cpl read as 0 in para-virtualization ? while I was modifying xen_early_setup, I tried to replace dcr kludge using cpl. Unfortunatly, it doesn't work since cpl is read as 0 (see vcpu.c). So my question is simple: why ? I think some places in Linux/ia64 determine whether code is running in kernel or user mode by checking psr.cpl. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Why is cpl read as 0 in para-virtualization ?
Le Mercredi 01 Mars 2006 16:44, Magenheimer, Dan (HP Labs Fort Collins) a écrit : Subject: [Xen-ia64-devel] Why is cpl read as 0 in para-virtualization ? while I was modifying xen_early_setup, I tried to replace dcr kludge using cpl. Unfortunatly, it doesn't work since cpl is read as 0 (see vcpu.c). So my question is simple: why ? I think some places in Linux/ia64 determine whether code is running in kernel or user mode by checking psr.cpl. Correct. One place is user_mode() is ptrace.h. Currently it is true if cpl != 0. I have made a simple test: I have changed the code to cpl == 3, and cpl reads as 2. Linux is booting (dom0+domU). Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: Please pull xen-ia64-unstable
Hi Keir -- Please pull http://xenbits.xensource.com/ext/xen-ia64-unstable.hg Includes catchup with various xen-unstable changes through 9023, various bug fixes and cleanups, some preparatory work for moving domain0 from p==m to VP, and default to SMP host. Thanks, Dan ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
Hi, Tristan Thank you. I'll try to reinstall soon. If reinstall is a root cause, it is mean some tools are not overwrite when we run make install-tools. Best Regards, Akio Takebe Le Mercredi 01 Mars 2006 02:30, Xu, Anthony a ィヲcrit : It is likely some subtle difference (or bug), perhaps in mmap? Hi all, yesterday I got the same bug as Akio. Today it is working again. I have just reinstalled tools+xen+kernel. Akio, could you try to reinstall xen+tools+kernel using a clean repository ? (make clean may be not enough). It seems *really* strange that only a few of us got the bug because it seems to be related only to Xen+Xenstore+Linux. Therefore it should not depend on the distribution. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] Help? Red Hat fails, Suse/Debian both work fine
From: Akio Takebe Sent: 2006年3月2日 8:44 Thank you for your advice. I checked retun value of mmap(), and it is not NULL. I'll check vcpu_translate(). Sorry for not clear, we need to check if the return address of mmap is in region0, Current vcpu_translate may not handle all scenarios when fault address is in region 0. Thanks, Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Why is cpl read as 0 in para-virtualization ?
From: Magenheimer, Dan (HP Labs Fort Collins) Sent: 2006年3月2日 1:01 I think some places in Linux/ia64 determine whether code is running in kernel or user mode by checking psr.cpl. Correct. One place is user_mode() is ptrace.h. Currently it is true if cpl != 0. I have made a simple test: I have changed the code to cpl == 3, and cpl reads as 2. Linux is booting (dom0+domU). IIRC, there was at least one place in assembly code which checked psr.cpl==0 (maybe mca code?) but this was a longtime ago (possibly 2.4.x) so the code may be gone. Yes, MCA recover assembly code has that check. Also alt dtlb miss handler has similar check to prevent user space speculation from polluting the TLB. Temporarily hacking one macro doesn't solve anything. You need to capture every places (rare or not) to eliminate all knowledges based on 4 ring levels. However, I didn't see necessity by far. Thanks, Kevin There is Itanium architecture work going on to establish a mechanism for determining whether an OS is running native or as a (paravirtualized or fully-virtualized) guest. I don't know the status of this but am pretty sure it was checking a currently reserved bit, possibly in cr.dcr. Dan ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] XEN: Avoid double reclaim dom0 image and dom0 initrd
VMM doesn't need to reclaim dom0 image and dom0 initrd by using init_domheap_pages, because they have been reclaimed by below code: in function start_kernel of xensetup.c efi_memmap_walk(filter_rsvd_memory, init_boot_pages); Reclaiming again may cause xen hang at very beginning. BTW, dom0 initrd is for dom0 not for xen, it will be copied into dom0 memory space, so VMM doesn't need to reserve memory for dom0 initrd. Commenting below definition makes dom0 initrd reclaimable. -#define CONFIG_BLK_DEV_INITRD // needed to reserve memory for domain0 +//#define CONFIG_BLK_DEV_INITRD // needed to reserve memory for domain0 Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, -Anthony avoid_double_mem_reclaim.patch Description: avoid_double_mem_reclaim.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel