Help? Red Hat fails, Suse/Debian both work fine

Help? Red Hat fails, Suse/Debian both work fine

[Magenheimer, Dan (HP Labs Fort Collins)]

Hi all --

We are seeing a strange problem where a recent cset causes
Red Hat to fail domU boot on ia64 complaining of a hotplug
problem but doesn't cause any problem for Suse or Debian.
It is likely some subtle difference (or bug), perhaps in mmap?
Suggestions/advice from anyone more familiar with distro
differences (on ia64) would be appreciated.

Changeset is xen-unstable 8783 ("Use /dev/kmem to map dom0
xenstore page instead of abusing the foreign mapping interface.",
Feb 8, committed by Christian).  Backing out this changeset
or using the small patch below causes the problem to go away,
so we have a workaround, but a root cause would be nice
to know and fix.

Full thread of discussion can be found here:
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-02/msg00104
.html

Thanks,
Dan

> -----Original Message-----
> From: Akio Takebe [mailto:takebe_akio@jp.fujitsu.com] 
> Sent: Tuesday, February 28, 2006 2:47 AM
> To: Magenheimer, Dan (HP Labs Fort Collins); yo.fujita; 
> xen-ia64-devel@lists.xensource.com
> Cc: Akio Takebe
> Subject: RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
> 
> Hi, Dan
> 
> I'm still debuging, but it is very difficult...
> Much advice is welcome. :-)
> 
> Now I can boot domU by using the following patch.
> 
> diff -r 6c43118bdba8 tools/xenstore/xenstored_domain.c
> --- a/tools/xenstore/xenstored_domain.c Fri Feb 24 15:41:08 2006 -0700
> +++ b/tools/xenstore/xenstored_domain.c Tue Feb 28 18:20:16 2006 +0900
> @@ -467,6 +467,7 @@ static int dom0_init(void)
>         int rc, fd;
>         evtchn_port_t port; 
>         unsigned long kva; 
> +       unsigned long mfn; 
>         char str[20]; 
>         struct domain *dom0; 
>  
> @@ -500,9 +501,16 @@ static int dom0_init(void)
>         if (fd == -1)
>                 return -1;
>  
> -       dom0->interface = mmap(NULL, getpagesize(), 
> PROT_READ|PROT_WRITE,
> -                              MAP_SHARED, fd, kva);
> -       if (dom0->interface == MAP_FAILED)
> +       mfn=((0x0fffffffffffffff & kva) >>14);
> +/*
> +        dom0->interface = mmap(NULL, getpagesize(), 
> PROT_READ|PROT_WRITE,
> +                               MAP_SHARED, fd, kva);
> +*/
> +       dom0->interface = xc_map_foreign_range(
> +               *xc_handle, 0,
> +               getpagesize(), PROT_READ|PROT_WRITE, mfn);
> +       if (!dom0->interface) 
> +//     if (dom0->interface == MAP_FAILED)
>                 goto outfd;
>  
>         close(fd);
> 
> Best Regards,
> 
> Akio Takebe
> 
> >Hi Akio --
> >
> >Any more progress on this issue?  If you are stuck,
> >maybe we should post the problem to xen-devel to
> >see if we can get help from a Red Hat person (since
> >the problem doesn't occur on Suse or Debian).
> >
> >Thanks,
> >Dan 
> >
> >> -----Original Message-----
> >> From: Akio Takebe [mailto:takebe_akio@jp.fujitsu.com] 
> >> Sent: Thursday, February 23, 2006 8:45 PM
> >> To: Magenheimer, Dan (HP Labs Fort Collins); yo.fujita; 
> >> xen-ia64-devel@lists.xensource.com
> >> Cc: Akio Takebe
> >> Subject: RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
> >> 
> >> Hi, Dan and Alex
> >> 
> >> I think this issue is only on ia64.
> >> I seem that kmem_map@drivers/char/mem.c is used on ia64, 
> >> but mem_map@drivers/xen/char/mem.c is used on x86.
> >> So I think pfn or kva aren't set correctly.
> >> We tried to boot domU with revesing cset xen-ia64-ustable.8790 
> >> and it was good work.
> >> 
> >> I'm still debugging it. :-<
> >> 
> >> Best Regards,
> >> 
> >> Akio Takebe
> >> 
> >> >Confirmed cset xen-unstable 8783 fails while 8782 succeeds.
> >> >
> >> >Perhaps there's something different about mmap on RH
> >> >vs Suse and Debian?  Perhaps only on ia64?
> >> >
> >> 
> >> 
> >> 
> 
> 
> 

Re: Help? Red Hat fails, Suse/Debian both work fine

[Keir Fraser]

On 28 Feb 2006, at 21:45, Magenheimer, Dan (HP Labs Fort Collins) wrote:

> We are seeing a strange problem where a recent cset causes
> Red Hat to fail domU boot on ia64 complaining of a hotplug
> problem but doesn't cause any problem for Suse or Debian.
> It is likely some subtle difference (or bug), perhaps in mmap?
> Suggestions/advice from anyone more familiar with distro
> differences (on ia64) would be appreciated.
>
> Changeset is xen-unstable 8783 ("Use /dev/kmem to map dom0
> xenstore page instead of abusing the foreign mapping interface.",
> Feb 8, committed by Christian).  Backing out this changeset
> or using the small patch below causes the problem to go away,
> so we have a workaround, but a root cause would be nice
> to know and fix.

Not very many apps use /dev/kmem, and xenstored only uses it once, to 
map domain0's xenbus page. Can't you just trace the hell out of it and 
find out exactly what MFN is mapping and why it (presumably) is 
different from the one allocated by the domain0 kernel for the purpose 
(the kernel virtual address of which is exported to xenstored via 
/proc)?

We weren't delighted to end up using /dev/kmem for this purpose, but I 
don't think our use is an abuse of the interface (I think we're using 
/dev/kmem mmap() 'within spec' :-).

  -- Keir

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

[Kouya SHIMURA]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 312 bytes --]

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@jp.fujitsu.com>

Best Regards,
Kouya


[-- Attachment #2: devkmem.patch --]
[-- Type: text/plain, Size: 1097 bytes --]

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 22:06:24 2006
+++ b/linux-2.6-xen-sparse/drivers/char/mem.c	Fri Mar  3 19:48:40 2006
@@ -72,10 +72,25 @@
 	   Hopefully a full PAT implementation will fix that soon. */	   
 	return 0;
 #elif defined(CONFIG_IA64)
+	u64 attr = efi_mem_attributes(addr);
+
+	/*
+	 * Physical address is out of EFI memmap.  Perhaps Xen
+	 * hypervisor passed this address to guest domain via
+	 * hypercall and the guest domain freed it and reuse it.
+	 *
+	 * In this case, this function shouldn't return TRUE.
+	 * Because some atomic instructions (cmpxchg, xchg) don't work on
+	 * 'UC'(Uncacheable) memory attribute page or virutal aliasing
+	 * problem might be occured.
+	 */
+	if (attr == 0)
+		return 0;
+	    
 	/*
 	 * On ia64, we ignore O_SYNC because we cannot tolerate memory attribute aliases.
 	 */
-	return !(efi_mem_attributes(addr) & EFI_MEMORY_WB);
+	return !(attr & EFI_MEMORY_WB);
 #else
 	/*
 	 * Accessing memory above the top the kernel knows about or through a file pointer

[-- Attachment #3: message body text --]
[-- Type: text/plain, Size: 4319 bytes --]


Magenheimer, Dan (HP Labs Fort Collins) writes:
 > Hi all --
 > 
 > We are seeing a strange problem where a recent cset causes
 > Red Hat to fail domU boot on ia64 complaining of a hotplug
 > problem but doesn't cause any problem for Suse or Debian.
 > It is likely some subtle difference (or bug), perhaps in mmap?
 > Suggestions/advice from anyone more familiar with distro
 > differences (on ia64) would be appreciated.
 > 
 > Changeset is xen-unstable 8783 ("Use /dev/kmem to map dom0
 > xenstore page instead of abusing the foreign mapping interface.",
 > Feb 8, committed by Christian).  Backing out this changeset
 > or using the small patch below causes the problem to go away,
 > so we have a workaround, but a root cause would be nice
 > to know and fix.
 > 
 > Full thread of discussion can be found here:
 > http://lists.xensource.com/archives/html/xen-ia64-devel/2006-02/msg00104
 > .html
 > 
 > Thanks,
 > Dan
 > 
 > > -----Original Message-----
 > > From: Akio Takebe [mailto:takebe_akio@jp.fujitsu.com] 
 > > Sent: Tuesday, February 28, 2006 2:47 AM
 > > To: Magenheimer, Dan (HP Labs Fort Collins); yo.fujita; 
 > > xen-ia64-devel@lists.xensource.com
 > > Cc: Akio Takebe
 > > Subject: RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
 > > 
 > > Hi, Dan
 > > 
 > > I'm still debuging, but it is very difficult...
 > > Much advice is welcome. :-)
 > > 
 > > Now I can boot domU by using the following patch.
 > > 
 > > diff -r 6c43118bdba8 tools/xenstore/xenstored_domain.c
 > > --- a/tools/xenstore/xenstored_domain.c Fri Feb 24 15:41:08 2006 -0700
 > > +++ b/tools/xenstore/xenstored_domain.c Tue Feb 28 18:20:16 2006 +0900
 > > @@ -467,6 +467,7 @@ static int dom0_init(void)
 > >         int rc, fd;
 > >         evtchn_port_t port; 
 > >         unsigned long kva; 
 > > +       unsigned long mfn; 
 > >         char str[20]; 
 > >         struct domain *dom0; 
 > >  
 > > @@ -500,9 +501,16 @@ static int dom0_init(void)
 > >         if (fd == -1)
 > >                 return -1;
 > >  
 > > -       dom0->interface = mmap(NULL, getpagesize(), 
 > > PROT_READ|PROT_WRITE,
 > > -                              MAP_SHARED, fd, kva);
 > > -       if (dom0->interface == MAP_FAILED)
 > > +       mfn=((0x0fffffffffffffff & kva) >>14);
 > > +/*
 > > +        dom0->interface = mmap(NULL, getpagesize(), 
 > > PROT_READ|PROT_WRITE,
 > > +                               MAP_SHARED, fd, kva);
 > > +*/
 > > +       dom0->interface = xc_map_foreign_range(
 > > +               *xc_handle, 0,
 > > +               getpagesize(), PROT_READ|PROT_WRITE, mfn);
 > > +       if (!dom0->interface) 
 > > +//     if (dom0->interface == MAP_FAILED)
 > >                 goto outfd;
 > >  
 > >         close(fd);
 > > 
 > > Best Regards,
 > > 
 > > Akio Takebe
 > > 
 > > >Hi Akio --
 > > >
 > > >Any more progress on this issue?  If you are stuck,
 > > >maybe we should post the problem to xen-devel to
 > > >see if we can get help from a Red Hat person (since
 > > >the problem doesn't occur on Suse or Debian).
 > > >
 > > >Thanks,
 > > >Dan 
 > > >
 > > >> -----Original Message-----
 > > >> From: Akio Takebe [mailto:takebe_akio@jp.fujitsu.com] 
 > > >> Sent: Thursday, February 23, 2006 8:45 PM
 > > >> To: Magenheimer, Dan (HP Labs Fort Collins); yo.fujita; 
 > > >> xen-ia64-devel@lists.xensource.com
 > > >> Cc: Akio Takebe
 > > >> Subject: RE: [Xen-ia64-devel] Weekly benchmark results [2/3rd week]
 > > >> 
 > > >> Hi, Dan and Alex
 > > >> 
 > > >> I think this issue is only on ia64.
 > > >> I seem that kmem_map@drivers/char/mem.c is used on ia64, 
 > > >> but mem_map@drivers/xen/char/mem.c is used on x86.
 > > >> So I think pfn or kva aren't set correctly.
 > > >> We tried to boot domU with revesing cset xen-ia64-ustable.8790 
 > > >> and it was good work.
 > > >> 
 > > >> I'm still debugging it. :-<
 > > >> 
 > > >> Best Regards,
 > > >> 
 > > >> Akio Takebe
 > > >> 
 > > >> >Confirmed cset xen-unstable 8783 fails while 8782 succeeds.
 > > >> >
 > > >> >Perhaps there's something different about mmap on RH
 > > >> >vs Suse and Debian?  Perhaps only on ia64?
 > > >> >
 > > >> 
 > > >> 
 > > >> 
 > > 
 > > 
 > > 
 > 
 > _______________________________________________
 > Xen-ia64-devel mailing list
 > Xen-ia64-devel@lists.xensource.com
 > http://lists.xensource.com/xen-ia64-devel

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

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

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

[Tian, Kevin]

>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@jp.fujitsu.com>
>
>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

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

[Tian, Kevin]

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年3月3日 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年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@jp.fujitsu.com>
>>
>>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

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

[Keir Fraser]

On 3 Mar 2006, at 11:02, Kouya SHIMURA wrote:

> 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.

Sounds like you guys are going to iterate on working out the best 
patch, but I guess I have to eat my hat as this is kind of a memory 
ordering / attribute issue. :-)

  -- Keir

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

[Keir Fraser]

On 3 Mar 2006, at 11:02, Kouya SHIMURA wrote:

> 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.

Another update on this: apparently /dev/kmem is not really supported 
well by some vendors so we'll be changing the mmap method for this page 
(again) by supporting mmap() on the xsd_kva file itself. That may well 
fix your problem by a different means.

  -- Keir

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

[Kouya SHIMURA]

Hi Keir,

Sorry for my ugly patch.

Keir Fraser writes:
 > Another update on this: apparently /dev/kmem is not really supported 
 > well by some vendors so we'll be changing the mmap method for this page 
 > (again) by supporting mmap() on the xsd_kva file itself. That may well 
 > fix your problem by a different means.

That would be fine.

Thanks,
Kouya

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

[Akio Takebe]

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@alumni.princeton.edu>
  *  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@lists.xensource.com
>>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Tian, Kevin
>>Sent: 2006ト\xF3\x14ヤツ3ネユ 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ト\xF3\x14ヤツ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@jp.fujitsu.com>
>>>
>>>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

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

[Kouya SHIMURA]

FYI, after more investigation, the problem is related whether to use
initrd or not. On ia64, the memory area for initrd is not defined in
dom0's EFI memmap. Dom0 frees this area and reuses it with illegal
memory attribute. That is a reason why RedHat fails but Suse/Debian
works.

Thanks,
Kouya

Kouya SHIMURA writes:
 > Hi Keir,
 > 
 > Sorry for my ugly patch.
 > 
 > Keir Fraser writes:
 >  > Another update on this: apparently /dev/kmem is not really supported 
 >  > well by some vendors so we'll be changing the mmap method for this page 
 >  > (again) by supporting mmap() on the xsd_kva file itself. That may well 
 >  > fix your problem by a different means.
 > 
 > That would be fine.
 > 
 > Thanks,
 > Kouya
 > 
 > 
 > _______________________________________________
 > Xen-ia64-devel mailing list
 > Xen-ia64-devel@lists.xensource.com
 > http://lists.xensource.com/xen-ia64-devel

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

[Alex Williamson]

On Mon, 2006-03-06 at 11:29 +0900, Kouya SHIMURA wrote:
> FYI, after more investigation, the problem is related whether to use
> initrd or not. On ia64, the memory area for initrd is not defined in
> dom0's EFI memmap. Dom0 frees this area and reuses it with illegal
> memory attribute. That is a reason why RedHat fails but Suse/Debian
> works.

   Nice work Kouya.  I can confirm that on my end, RedHat was the only
distribution that required me to use an initrd.  Thanks,

	Alex