WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH] Re: [Xen-ia64-devel] Help? Red Hat fails, Suse/D

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Kouya SHIMURA" <kouya@xxxxxxxxxxxxxx>, "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
Subject: RE: [Xen-devel] [PATCH] Re: [Xen-ia64-devel] Help? Red Hat fails, Suse/Debian both work fine
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 3 Mar 2006 20:26:48 +0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 03 Mar 2006 12:27:31 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcY+sj2rLqDQ70ExQMCfh6IaTFtyGgABTHTwAAEUwBA=
Thread-topic: [Xen-devel] [PATCH] Re: [Xen-ia64-devel] Help? Red Hat fails, Suse/Debian both work fine
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年3月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年3月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