RE: [Xen-devel] [PATCH] Re: [Xen-ia64-devel] Help? Red Hat fails, Suse/Debian both work fine

[Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>]

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 <cananian@xxxxxxxxxxxxxxxxxxxx>
  *  Shared /dev/zero mmaping support, Feb 2000, Kanoj Sarcar <kanoj@sgi.
com>
  */
+#define ARCH_HAS_DEV_MEM
 
 #include <linux/config.h>
 #include <linux/mm.h>
 
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@xxxxxxxxxxxxxxxxxxx
>>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Tian, Kevin
>>Sent: 2006ト\xF3ヤツ3ネユ 20:08
>>To: Kouya SHIMURA; Magenheimer, Dan (HP Labs Fort Collins)
>>Cc: xen-devel; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>Subject: RE: [Xen-devel] [PATCH] Re: [Xen-ia64-devel] Help? Red Hat
>>fails,Suse/Debian both work fine
>>
>>>From: Kouya SHIMURA
>>>Sent: 2006ト\xF3ヤツ3ネユ 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 <kouya@xxxxxxxxxxxxxx>
>>>
>>>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@xxxxxxxxxxxxxxxxxxx
>>http://lists.xensource.com/xen-devel
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel