From mboxrd@z Thu Jan 1 00:00:00 1970 From: Akio Takebe Subject: RE: [PATCH] Re: [Xen-ia64-devel] Help? Red Hat fails, Suse/Debian both work fine Date: Mon, 06 Mar 2006 10:06:22 +0900 Message-ID: <3FC640BA2EDA26takebe_akio@jp.fujitsu.com> References: <571ACEFD467F7749BC50E0A98C17CDD8094E78C9@pdsmsx403> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <571ACEFD467F7749BC50E0A98C17CDD8094E78C9@pdsmsx403> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Tian, Kevin" , Kouya SHIMURA , "Magenheimer, Dan (HP Labs Fort Collins)" Cc: xen-devel , xen-ia64-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Hi, Kevin Already the problem has been fixed by Keir. FYI, I tried again with cset 9079, but I have the same error. Error: Device 769 (vbd) could not be connected. Hotplug scripts not working. the patch which I tried is the below. --- drivers/xen/Makefile.orig 2006-03-03 22:39:06.000000000 +0900 +++ drivers/xen/Makefile 2006-03-03 22:40:05.000000000 +0900 @@ -2,7 +2,7 @@ obj-y += util.o obj-y += core/ - +obj-y += char/ obj-y += console/ obj-y += evtchn/ #obj-y += balloon/ diff -r b4f1084177cc linux-2.6-xen-sparse/drivers/char/mem.c --- a/linux-2.6-xen-sparse/drivers/char/mem.c Wed Mar 1 15:06:24 2006 -0700 +++ b/linux-2.6-xen-sparse/drivers/char/mem.c Mon Mar 6 10:02:03 2006 +0900 @@ -7,6 +7,7 @@ * Jan-11-1998, C. Scott Ananian * Shared /dev/zero mmaping support, Feb 2000, Kanoj Sarcar */ +#define ARCH_HAS_DEV_MEM #include #include Best Regards, Akio Takebe >After thinking more, I still think the cause that drivers/xen/char/mem.c is >not compiled into xen0 kernel image (for xen/ia64 only). See >uncached_access() within that file which is simple and different as original >linux one: > >static inline int uncached_access(struct file *file) >{ > if (file->f_flags & O_SYNC) > return 1; > /* Xen sets correct MTRR type on non-RAM for us. */ > return 0; >} > >By this way, xenstore page of domU will be always presented as WB to >dom0, and then memory attribute will become correct. > >Akio told me that he seemed to make an incomplete experiment to include >xen style kmem. Could you confirm whether following quick change can >work for you: (Sorry for not patch style, due to no access to my box now:-) > >1. Modify drivers/xen/Makefile by adding: > obj-y += char/ > >2. Then modify drivers/char/mem.c by define ARCH_HAS_DEV_MEM at >the very start. (Just for quick experiment to ensure correct code included. >If it works, please move the definition to appropriate header file) > >Thanks, >Kevin >>-----Original Message----- >>From: xen-devel-bounces@lists.xensource.com >>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Tian, Kevin >>Sent: 2006$B%Hs%d%D(B3$B%M%f(B 20:08 >>To: Kouya SHIMURA; Magenheimer, Dan (HP Labs Fort Collins) >>Cc: xen-devel; xen-ia64-devel@lists.xensource.com >>Subject: RE: [Xen-devel] [PATCH] Re: [Xen-ia64-devel] Help? Red Hat >>fails,Suse/Debian both work fine >> >>>From: Kouya SHIMURA >>>Sent: 2006$B%Hs%d%D(B3$B%M%f(B 19:02 >>>Hi all >>> >>>Finally I found out the unstable problem about domU boot on ia64. >>>Please see the comment in patch. >>> >>>This patch is one solution. >>>Another solution is to ask the memory attributes to >>>hypervisor but it looks excessive modification. >>> >>>Signed-off-by Kouya SHIMURA >>> >>>Best Regards, >>>Kouya >> >>Hi, Kouya, >> >>Good finding for the cause, however several minor comments about your >>patch: >> - Be conservative when you want to modify common linux files, if >>without strong reasons. >> >> - Your change has potential issue. Your change actually makes all >>illegal addresses which is out of EFI memmap can get WB attribute, only >>for accommodating another special page (store page) out of domU's >>knowledge. I don't think it's right way to go. >> >> - See how x86 works. All special pages including store page, console >>page, start info, etc. are constructed within domU's memory, and domU >>is aware of that. For XEN/IA64, you may want to steal last several pages >>from configured memory of domU. There's an ia64 specific field named >>sys_pgnr (in xc_linux_build), which was targeted for this issue before >>however incomplete yet. Then you can pass to Xen and add one reserved >>EFI memmap entry to cover sys_pgnr pages with attribute WB at >>dom_fw_init. Since it's reserved, domU won't use it. However >>efi_mem_attributes can give ideal result you want. This workaround has >>no impact to xenlinux code, which may be quick solution. Of course, we >>may consider reconstruct more to make it cleaner in the future. ;-) >> >>Thanks, >>Kevin >> >> >>_______________________________________________ >>Xen-devel mailing list >>Xen-devel@lists.xensource.com >>http://lists.xensource.com/xen-devel > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel