[Xen-ia64-devel] RE: [Fedora-xen] fedora-xen-ia64 first pass
Hi, Aron We have tried to boot xen with your tip, but found the configuration for domain0 opens dom0_VP mode, however, the dom0_VP option of xen was closed by default. Maybe this is the main reason why xen dies at booting xen0. Correct? If they don't match, it is impossible to boot up. Due to not familiar with rpmbuild scripts, so we have to modify it manually to try. Thanks -Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aron Griffis Sent: 2006年5月21日 3:35 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: [Fedora-xen] fedora-xen-ia64 first pass Hello, I've made a first pass at modifying the Fedora Rawhide xen and kernel rpms to support ia64. There is still a lot of work to do before this would be suitable for inclusion in Fedora, but hopefully this represents a proof-of-concept that can be improved to that point. If you'd like to browse or contribute, the bits are available as mercurial repositories at: http://free.linux.hp.com/~agriffis/ There are 5 repositories presently: fedora-xen-rpm Tracks xen.src.rpm from rawhide. fedora-xen-ia64 Pulls from fedora-xen-rpm, contains (trivial) modifications for ia64 fedora-kernel-rpm Tracks kernel.src.rpm from rawhide. fedora-kernel-ia64 Pulls from fedora-kernel-rpm, contains modifications for ia64 xen-ia64-unstable-2.6.17Forward port of xen-ia64-unstable sparse tree from 2.6.16.13 to 2.6.17, generates linux-2.6-xen.patch for fedora-kernel-ia64 Here is my non-comprehensive list of notes/issues for fedora-kernel-ia64: 1. Upstream xen is presently based on 2.6.16.13. Fedora kernel is (or was yesterday) based on 2.6.17-rc4-git5. To port xen forward, the most maintainable method seems to be to do the port in the context of a xen-ia64-unstable mercurial clone (xen-ia64-unstable-2.6.17 above). Using this method makes it relatively easy to: (a) port forward to a new kernel at any time using the sparse-merge script (b) pull new changes from upstream xen and avoid most manual merging (c) extract a patch at any time that represents the forward-port of xen to a new kernel (d) generate a patch at any time that adds xen support to the fedora kernel (linux-2.6-xen.patch generated with make mkpatches) The only caveat here is that I probably didn't do the forward port perfectly. In particular I know I bungled the TPM stuff because there are lots of changes going into kernel.org and xen simultaneously. Additionally I didn't pay a lot of attention to other architectures for the moment. Hopefully 2.6.17 will pop any day now, then xen upstream will move to it, and we won't have to carry the forward port in the Fedora patch. If by some chance this doesn't happen, then my forward porting work will need to be revisited. 2. This first pass was created using the xen-ia64-unstable repo instead of the xen-unstable repo. This is because xen-unstable is broken recently on ia64. When the two have been resynced upstream, and xen-unstable works on ia64, we should move this prototype to using xen-unstable (which is what the current Fedora Xen patch is based on). 3. The bare metal config is built for Generic. The xen0 and xenU configs are built for DIG-Compliant. It seems that the kernel won't build for Generic with CONFIG_XEN enabled. Using DIG-compliant for the xen kernels is probably okay for now, but it would be good to get Generic building. 4. After applying patch700 (linux-2.6-xen.patch), the spec file executes xen-mkbuildtree-pre if it exists for the architecture. In effect, this is applying an ia64-specific patch, even though it looks more generic in the spec. The special modifications being made by xen-mkbuildtree-pre need to be folded into linux-2.6-xen.patch to prevent architecture-specific maintenance headaches in the stack of Fedora kernel patches. 5. My forward port broke the exec-shield patch application. Juan has this resolved in his version, but that's based on an older xen-unstable changeset. I commented out patch810-812 for the moment. 6. The xen patch is missing some function prototypes. (I believe this is a problem in xen upstream not something introduced by my port.) The Fedora kernel build normally turns on -Werror-implicit-function-declaration in patch1018 (linux-2.6-debug-Wundef.patch). I commented out this patch for the moment. 7. The hypervisor doesn't build on ia64 with debug=y verbose=y crash_debug=y. For the moment it builds with default flags on ia64 instead. 8.
To disable serial port for ia64 dom0 (RE: [Xen-ia64-devel] [PATCH 0/6] Add full evtchn mechanism forxen/ia64)
Serial can be disabled by a simple change: diff -r 2e5d4e459c1c buildconfigs/linux-defconfig_xen_ia64 --- a/buildconfigs/linux-defconfig_xen_ia64 Sun May 21 07:31:02 2006 -0600 +++ b/buildconfigs/linux-defconfig_xen_ia64 Mon May 22 15:06:00 2006 +0800 @@ -98,6 +98,7 @@ CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_XEN_BACKEND=y CONFIG_XEN_BLKDEV_BACKEND=y +CONFIG_XEN_DISABLE_SERIAL=y CONFIG_XEN_SYSFS=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_DMA_IS_DMA32=y @@ -1544,4 +1545,3 @@ CONFIG_CRYPTO_DES=y # XEN # # CONFIG_XEN_UNPRIVILEGED_GUEST is not set -# CONFIG_XEN_DISABLE_SERIAL is not set But I'm not sure why I have to set option to be 'yes' explicitly: config XEN_DISABLE_SERIAL bool Disable serial port drivers default y So after making oldconfig, this option should be enabled automatically. Does I misunderstand the logic behind? :-( Thanks, Kevin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tian, Kevin Sent: 2006年5月22日 14:53 To: Isaku Yamahata Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [PATCH 0/6] Add full evtchn mechanism forxen/ia64 From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年5月22日 13:43 On Mon, May 22, 2006 at 12:53:11PM +0800, Tian, Kevin wrote: Why is serial required to be disabled in dom0? What's policy to choose which serial to be disabled, if there're multiple serial ports with different type? In fact I'm not sure about the policy. Since xenLinux/x86 defines CONFIG_XEN_DISABLE_SERIAL=y, I thought it was the xen's policy. However I'm not sure whether it's right. It seemed that you used serial port from dom0, I wanted to confirm it. It is bad that xen and dom0 accesse to the same UART. This is only what I'm sure about. Yes, that's bad which may be the reason why xen/x86 disables serial directly. Ideally that should also apply to xen/ia64 since that option is common in drivers/xen. So I'm not sure why that option doesn't work for ia64. Alex should know more about this area, and it may simply come from a mis-configuration case... Thanks, Kevin ___ 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] kernel build performance data with dom0_VP mode open
Hi all, I have done kernel build with dom0_vp mode open to compare with it close. The specific data as following: Environment : Memory:768M Platform : tiger4 Cpu : Montecito C1 stepping Compile cmdline : time make /dev/null 21 Configuration file : @arch/ia64/config/tiger_defconfig time Real user sys Cset 10027 (with dom0_vp open): 14m48.377s 13m43.960s 0m51.670s Cset 10022 (with dom0_vp closed): 14m5.752s 13m13.200s 0m39.260s Native : 13m55.572s 13m4.366s 0m35.205s Performance : Cset 10022: dom0/native =98.7% Cset 10027:dom0/native=94.1% From the result, we can see when dom0_vp mode open, the performance of KB has 4.6% degradation. Thanks Zhang Jingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: split smpboot.c and create cpuhotplug.c
Hi,
this patch creates a new file: cpuhotplug.c. The content is the xenbus
handler part of smpboot.c. The purpose is to be able to share this part with
other architectures.
Tested by compiling on i386.
Tristan.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 3aa29135597a5c85464dfb85b69217aeae6465fd
# Parent 14717dedba028c7e98bff1f67c6e9e25b42b5661
Xenbus vcpu hotplug control moved to cpuhotplug.c
So that this code can be easily shared with other architecture.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 14717dedba02 -r 3aa29135597a linux-2.6-xen-sparse/drivers/xen/core/Makefile
--- a/linux-2.6-xen-sparse/drivers/xen/core/Makefile Sun May 21 20:15:58 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/core/Makefile Mon May 22 09:53:42 2006 +0200
@@ -7,5 +7,6 @@ obj-$(CONFIG_PROC_FS) += xen_proc.o
obj-$(CONFIG_PROC_FS) += xen_proc.o
obj-$(CONFIG_NET) += skbuff.o
obj-$(CONFIG_SMP) += smpboot.o
+obj-$(CONFIG_HOTPLUG_CPU) += cpuhotplug.o
obj-$(CONFIG_SYSFS) += hypervisor_sysfs.o
obj-$(CONFIG_XEN_SYSFS) += xen_sysfs.o
diff -r 14717dedba02 -r 3aa29135597a linux-2.6-xen-sparse/drivers/xen/core/smpboot.c
--- a/linux-2.6-xen-sparse/drivers/xen/core/smpboot.c Sun May 21 20:15:58 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/core/smpboot.c Mon May 22 09:53:42 2006 +0200
@@ -83,7 +83,7 @@ unsigned int maxcpus = NR_CPUS;
* Set of CPUs that remote admin software will allow us to bring online.
* Notified to us via xenbus.
*/
-static cpumask_t xenbus_allowed_cpumask;
+cpumask_t xenbus_allowed_cpumask;
/* Set of CPUs that local admin will allow us to bring online. */
static cpumask_t local_allowed_cpumask = CPU_MASK_ALL;
@@ -342,6 +342,7 @@ static int local_cpu_hotplug_request(voi
}
#ifdef CONFIG_HOTPLUG_CPU
+extern void vcpu_hotplug(unsigned int cpu);
/*
* Initialize cpu_present_map late to skip SMP boot code in init/main.c.
@@ -354,46 +355,6 @@ static int __init initialize_cpu_present
return 0;
}
core_initcall(initialize_cpu_present_map);
-
-static void vcpu_hotplug(unsigned int cpu)
-{
- int err;
- char dir[32], state[32];
-
- if ((cpu = NR_CPUS) || !cpu_possible(cpu))
- return;
-
- sprintf(dir, cpu/%d, cpu);
- err = xenbus_scanf(XBT_NULL, dir, availability, %s, state);
- if (err != 1) {
- printk(KERN_ERR XENBUS: Unable to read cpu state\n);
- return;
- }
-
- if (strcmp(state, online) == 0) {
- cpu_set(cpu, xenbus_allowed_cpumask);
- (void)cpu_up(cpu);
- } else if (strcmp(state, offline) == 0) {
- cpu_clear(cpu, xenbus_allowed_cpumask);
- (void)cpu_down(cpu);
- } else {
- printk(KERN_ERR XENBUS: unknown state(%s) on CPU%d\n,
- state, cpu);
- }
-}
-
-static void handle_vcpu_hotplug_event(
- struct xenbus_watch *watch, const char **vec, unsigned int len)
-{
- int cpu;
- char *cpustr;
- const char *node = vec[XS_WATCH_PATH];
-
- if ((cpustr = strstr(node, cpu/)) != NULL) {
- sscanf(cpustr, cpu/%d, cpu);
- vcpu_hotplug(cpu);
- }
-}
static int smpboot_cpu_notify(struct notifier_block *notifier,
unsigned long action, void *hcpu)
@@ -411,41 +372,17 @@ static int smpboot_cpu_notify(struct not
return NOTIFY_OK;
}
-static int setup_cpu_watcher(struct notifier_block *notifier,
- unsigned long event, void *data)
-{
- int i;
-
- static struct xenbus_watch cpu_watch = {
- .node = cpu,
- .callback = handle_vcpu_hotplug_event,
- .flags = XBWF_new_thread };
- (void)register_xenbus_watch(cpu_watch);
-
- if (!(xen_start_info-flags SIF_INITDOMAIN)) {
- for_each_cpu(i)
- vcpu_hotplug(i);
- printk(KERN_INFO Brought up %ld CPUs\n,
- (long)num_online_cpus());
- }
-
- return NOTIFY_DONE;
-}
-
-static int __init setup_vcpu_hotplug_event(void)
+static int __init setup_vcpu_hotplug_notifier(void)
{
static struct notifier_block hotplug_cpu = {
.notifier_call = smpboot_cpu_notify };
- static struct notifier_block xsn_cpu = {
- .notifier_call = setup_cpu_watcher };
register_cpu_notifier(hotplug_cpu);
- register_xenstore_notifier(xsn_cpu);
-
- return 0;
-}
-
-arch_initcall(setup_vcpu_hotplug_event);
+
+ return 0;
+}
+
+arch_initcall(setup_vcpu_hotplug_notifier);
int smp_suspend(void)
{
diff -r 14717dedba02 -r 3aa29135597a linux-2.6-xen-sparse/drivers/xen/core/cpuhotplug.c
--- /dev/null Thu Jan 1 00:00:00 1970 +
+++ b/linux-2.6-xen-sparse/drivers/xen/core/cpuhotplug.c Mon May 22 09:53:42 2006 +0200
@@ -0,0 +1,93 @@
+#include linux/module.h
+#include linux/config.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/smp_lock.h
+#include linux/notifier.h
+#include linux/cpu.h
+#include linux/percpu.h
+#include xen/evtchn.h
+#include xen/interface/vcpu.h
+#include xen/xenbus.h
+#include asm/hypervisor.h
+
+#ifdef CONFIG_HOTPLUG_CPU
+extern cpumask_t xenbus_allowed_cpumask;
+
+void vcpu_hotplug(unsigned int cpu)
+{
+ int err;
+ char dir[32], state[32];
+
+ if ((cpu = NR_CPUS) || !cpu_possible(cpu))
+ return;
+
+ sprintf(dir, cpu/%d, cpu);
+ err = xenbus_scanf(XBT_NULL,
Re: [Xen-ia64-devel] fedora-xen-ia64 first pass
Hi, Aron Which distro do you use on your rpmbuild system? Fedora5-ia64? or RHEL4? Cannot we completely make fedora-xen-ia64 yet? I had the following error. Did I have mistakes? + rm -rf /var/tmp/xen-3.0.2-4-root/usr/share/doc/xen-3.0.2 + /bin/mkdir -p /var/tmp/xen-3.0.2-4-root/usr/share/doc/xen-3.0.2 + cp -pr COPYING README /var/tmp/xen-3.0.2-4-root/usr/share/doc/xen-3.0.2 + cp -pr docs/pdf/ /var/tmp/xen-3.0.2-4-root/usr/share/doc/xen-3.0.2 + cp -pr docs/misc/ /var/tmp/xen-3.0.2-4-root/usr/share/doc/xen-3.0.2 + exit 0 warning: File listed twice: /usr/lib/xen warning: File listed twice: /usr/lib/xen/boot Provides: _pyext2.so()(64bit) acm.so()(64bit) config(xen) = 3.0.2-4 libxenctrl.so.3.0()(64bit) libxenguest.so.3.0()(64bit) libxenstore.so()(64bit) xc.so()(64bit) xs.so()(64bit) Requires(interp): /bin/sh /bin/sh Requires(rpmlib): rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 Requires(post): /bin/sh Requires(preun): /bin/sh Requires: /bin/bash /bin/sh /usr/bin/env /usr/bin/python bridge-utils config(xen) = 3.0.2-4 libSDL-1.2.so.0()(64bit) libc.so.6.1()(64bit) libc.so.6.1(GLIBC_2.2)(64bit) libc.so.6. 1(GLIBC_2.3)(64bit) libc.so.6.1(GLIBC_2.3.4)(64bit) libc.so.6.1(GLIBC_2.4)(64bit) libext2fs.so.2()(64bit) libjpeg.so.62()(64bit) libm.so.6.1()(64bit) libncurses.so.5()(64bit) lib nsl.so.1()(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) libutil.so.1()(64bit) libutil.so.1(GLIBC_2.0)(64bit) libvirt-pyth on libxenctrl.so.3.0()(64bit) libxenguest.so.3.0()(64bit) libxenstore.so()(64bit) libz.so.1()(64bit) python(abi) = 2.4 python-abi = 2.4 udev = 059 Processing files: xen-debuginfo-3.0.2-4 Provides: _pyext2.so.debug()(64bit) acm.so.debug()(64bit) libxenctrl.so.3.0.0.debug()(64bit) libxenguest.so.3.0.0.debug()(64bit) xc.so.debug()(64bit) xs.so.debug()(64bit) Requires(rpmlib): rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/xen-3.0.2-4-root warning: Could not canonicalize hostname: tiger72 error: Could not open /root/fedora/fedora-xen-ia64/SRPMS/xen-3.0.2-4.src.rpm: No such file or directory So I do the following step. Is this step the same as yours? 1. make rpm of kernel (as-is Anil's step) hg clone http://free.linux.hp.com/~agriffis/fedora-kernel-ia64 cd fedora-kernel-ia64 mkdir -p BUILD RPMS/ia64 source bashrc-snippet # might want this in your ~/.bashrc cd SPECS rpmbuild -ba kernel-2.6.spec 2. make xen # rpmbuild -bp xen.spec # cd ../BUILD/xen-unstable.hg/ # make xen # make tools # make install-tools # cp xen/xen.gz /boot/efi/efi/redhat/ Best Regards, Akio Takebe Hello, I've made a first pass at modifying the Fedora Rawhide xen and kernel rpms to support ia64. There is still a lot of work to do before this would be suitable for inclusion in Fedora, but hopefully this represents a proof-of-concept that can be improved to that point. If you'd like to browse or contribute, the bits are available as mercurial repositories at: http://free.linux.hp.com/~agriffis/ There are 5 repositories presently: fedora-xen-rpm Tracks xen.src.rpm from rawhide. fedora-xen-ia64 Pulls from fedora-xen-rpm, contains (trivial) modifications for ia64 fedora-kernel-rpm Tracks kernel.src.rpm from rawhide. fedora-kernel-ia64 Pulls from fedora-kernel-rpm, contains modifications for ia64 xen-ia64-unstable-2.6.17Forward port of xen-ia64-unstable sparse tree from 2.6.16.13 to 2.6.17, generates linux-2.6-xen.patch for fedora-kernel-ia64 Here is my non-comprehensive list of notes/issues for fedora-kernel-ia64: 1. Upstream xen is presently based on 2.6.16.13. Fedora kernel is (or was yesterday) based on 2.6.17-rc4-git5. To port xen forward, the most maintainable method seems to be to do the port in the context of a xen-ia64-unstable mercurial clone (xen-ia64-unstable-2.6.17 above). Using this method makes it relatively easy to: (a) port forward to a new kernel at any time using the sparse-merge script (b) pull new changes from upstream xen and avoid most manual merging (c) extract a patch at any time that represents the forward-port of xen to a new kernel (d) generate a patch at any time that adds xen support to the fedora kernel (linux-2.6-xen.patch generated with make mkpatches) The only caveat here is that I probably didn't do the forward port perfectly. In particular I know I bungled the TPM stuff because there are lots of changes going into kernel.org and xen simultaneously. Additionally I didn't pay a lot of attention to other architectures for the moment. Hopefully 2.6.17 will pop
[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains
From: Charles Coffing Sent: 2006年5月20日 3:59 On Thu, May 18, 2006 at 10:23 PM, in message [EMAIL PROTECTED] orp.intel.com, Jiang, Yunhong [EMAIL PROTECTED] wrote: Hi, Charles Just one suggestion, for xen- hvm- auto- balloon.diff, how about change xc.domain_setmaxmem(self.domid, m) to xc.domain_setmaxmem(self.domid, self.info['memory'] * 1024) Ideally, yes, I would agree. But later, in qemu, another increase_reservation() is called. If I make the suggested change, I suspect that qemu will fail to get its memory. Or is this upper limit not checked when increase_reservation() is called from dom0? BTW, could you please explain why following change is required: +given amount, also in KiB. This is normally just mem, but if HVM is +supported, keep a little extra free. +if 'hvm' in xc.xeninfo()['xen_caps']: +mem_kb += 4*1024; +return mem_kb Why do you need to reserve extra memory even for domU as long as the platform supports hvm feature? P.S I'll send a patch to reverse this change for ia64, since balloon doesn't work for xen/ia64 yet and thus we have to allocate all memory at creation time. Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains
On 22 May 2006, at 09:51, Tian, Kevin wrote: Why do you need to reserve extra memory even for domU as long as the platform supports hvm feature? P.S I'll send a patch to reverse this change for ia64, since balloon doesn't work for xen/ia64 yet and thus we have to allocate all memory at creation time. It would be nice to avoid needing that kludge at all even on x86. It isn't entirely clear to me why it's needed. If it's causing problems for ia64 I'm inclined to remove it unless there is a concrete reason for keeping it. -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Disable auto-balloon on ia64
From: Alex Williamson Sent: 2006年5月22日 6:30 On Sun, 2006-05-21 at 15:07 -0600, Alex Williamson wrote: diff -r 4dcb93547710 tools/python/xen/xend/image.py --- a/tools/python/xen/xend/image.py Sun May 21 09:55:15 2006 +0100 +++ b/tools/python/xen/xend/image.py Sun May 21 14:25:19 2006 -0600 @@ -146,7 +146,7 @@ class ImageHandler: @return The memory required, in KiB, by the domain to store the given amount, also in KiB. This is normally just mem, but if HVM is supported, keep a little extra free. -if 'hvm' in xc.xeninfo()['xen_caps']: +if 'hvm' in xc.xeninfo()['xen_caps'] and os.uname()[4] != 'ia64': mem_kb += 4*1024; return mem_kb Looks like this is just a partial solution, VTi guests are still broken with only this change. Instead, we probably need to look at cset 10040. I suspect we don't yet have the ballooning support and need to do the allocation up front. Thanks, Alex We just need to reverse the whole change for ia64, since both domU and domVTI are insert a hole by this auto-balloon patch. Due to missing balloon support on xen/ia64 as you said, both domU and domVTI failed due to this change. Patch attached. Thanks, Kevin fix-auto-balloon.patch Description: fix-auto-balloon.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains
From: Keir Fraser [mailto:[EMAIL PROTECTED] Sent: 2006年5月22日 17:06 On 22 May 2006, at 09:51, Tian, Kevin wrote: Why do you need to reserve extra memory even for domU as long as the platform supports hvm feature? P.S I'll send a patch to reverse this change for ia64, since balloon doesn't work for xen/ia64 yet and thus we have to allocate all memory at creation time. It would be nice to avoid needing that kludge at all even on x86. It isn't entirely clear to me why it's needed. If it's causing problems for ia64 I'm inclined to remove it unless there is a concrete reason for keeping it. -- Keir Yes, that breaks xen/ia64 for both domU and domVTI. Though I sent out a workaround just now, it's better if you can reverse it directly. Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Re: [PATCH] Disable auto-balloon on ia64
On 22 May 2006, at 10:37, Keir Fraser wrote: We just need to reverse the whole change for ia64, since both domU and domVTI are insert a hole by this auto-balloon patch. Due to missing balloon support on xen/ia64 as you said, both domU and domVTI failed due to this change. The first patch that you work around seems okay to me. That is, it seems correct that we make initial reservation exclude 'getDomainMemory headroom'. Shouldn't ia64 reserve extra memory as it needs it, as x86 does, rather than up front? The second bit of your workaround, which applies to getDomainMemory: I'll wait and see if Charles has anything to say, but otherwise I'll remove the code that adds the extra slack entirely. Thinking about it, that slack might have been added to give enough space for shadow page tables for live migration. Also, it shouldn't give you any problems if you weren't allocating headroom up front -- if you can fix ia64 to allocate the extra memory as needed then you shouldn't need either of your workarounds? -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Installing XEN/ia64 on Debian
Hello! :) I`m yet trying to install xen on my Debian Sarge 3.1/ia64! So, I`m trying to install using the ./install.sh but I think that it isn`t possible on the unstable version, am I correct? debian-ia64:~/xen-ia64-unstable.hg# ./install.sh ERROR: Could not find a valid distribution directory. If this is a source-only release, try 'make dist'. The xen works on my pentium, on my xeon, but I don`t know how to install it on my Itanium2 (hp workstation zx2000) Thanks! 2006/5/15, Al Stone [EMAIL PROTECTED]: On Fri, 2006-04-28 at 11:43 -0300, Rodrigo Lord wrote: I tryied to install XEN using this method, but when in the step make world, happens the error below: hyperprivop.S:69:2: warning: #warning FIXME: ptc.ga instruction requires spinlock for SMP hyperprivop.S: Assembler messages: hyperprivop.S:2089: Error: unknown pseudo-op: `.serialize.data' hyperprivop.S :2096: Warning: Use of 'st8' violates RAW dependency 'DTC' (data) hyperprivop.S:2096: Warning: Only the first path encountering the conflict is reportedThis looks like a pretty old version of binutils (and hence gas). This does not occur on Debian sid; if you're on testing or evensarge, you'll need to upgrade to much newer versions of gas (akathe assembler, aka binutils).--Ciao,al-- Al StoneAlter Ego:Open Source and Linux RD Debian DeveloperHewlett-Packard Company http://www.debian.orgE-mail: [EMAIL PROTECTED][EMAIL PROTECTED]-- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH] Disable auto-balloon on ia64
From: Keir Fraser [mailto:[EMAIL PROTECTED] Sent: 2006年5月22日 17:37 On 22 May 2006, at 10:06, Tian, Kevin wrote: We just need to reverse the whole change for ia64, since both domU and domVTI are insert a hole by this auto-balloon patch. Due to missing balloon support on xen/ia64 as you said, both domU and domVTI failed due to this change. The first patch that you work around seems okay to me. That is, it seems correct that we make initial reservation exclude 'getDomainMemory headroom'. Shouldn't ia64 reserve extra memory as it needs it, as x86 does, rather than up front? I have to admit that currently xen/ia64 hasn't enough sanity check about reserving extra memory, which should be changed once balloon feature is added. Then same policy whatever is applicable can be added to ia64. Now ia64 dom0 has been changed to vp model (p!=m) by Isaku, and thus balloon can be foreseeable soon. In currently stage, we can just ensure ia64 working by ensuring all max_pages frames are allocated without empty holes. The second bit of your workaround, which applies to getDomainMemory: I'll wait and see if Charles has anything to say, but otherwise I'll remove the code that adds the extra slack entirely. -- Keir Yes, let's see whether Charles has other good reason for that change. :-) Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] Re: [PATCH] Disable auto-balloon on ia64
From: Keir Fraser [mailto:[EMAIL PROTECTED] Sent: 2006年5月22日 17:51 To: Keir Fraser We just need to reverse the whole change for ia64, since both domU and domVTI are insert a hole by this auto-balloon patch. Due to missing balloon support on xen/ia64 as you said, both domU and domVTI failed due to this change. The first patch that you work around seems okay to me. That is, it seems correct that we make initial reservation exclude 'getDomainMemory headroom'. Shouldn't ia64 reserve extra memory as it needs it, as x86 does, rather than up front? The second bit of your workaround, which applies to getDomainMemory: I'll wait and see if Charles has anything to say, but otherwise I'll remove the code that adds the extra slack entirely. Thinking about it, that slack might have been added to give enough space for shadow page tables for live migration. Also, it shouldn't give you any problems if you weren't allocating headroom up front -- if you can fix ia64 to allocate the extra memory as needed then you shouldn't need either of your workarounds? -- Keir OK, the question by far is that ia64 describes the memory hierarchy presented to domain by d-max_pages. Before balloon is ready, we at least need to ensure all frames covered by d-max_pages allocated for target domain. Then there're two alternatives: - Keep the first piece of change on increase_reservation, which ensures all pages including extra spaces allocated immediately. - Pass the extra memory size to xen at arch_set_info_guest, and then change xen/ia64 to only tell domain maximum pfns as d-max_pages-extra_size Both need to be changed again later if balloon is ready. So I prefer to option I which is simpler and can help Alex to do sync quickly. How do you think? Thanks, Kevin ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH 0/6] Add full evtchn mechanism forxen/ia64
On Mon, 2006-05-22 at 14:53 +0800, Tian, Kevin wrote: From: Isaku Yamahata [mailto:[EMAIL PROTECTED] It is bad that xen and dom0 accesse to the same UART. This is only what I'm sure about. Yes, that's bad which may be the reason why xen/x86 disables serial directly. Ideally that should also apply to xen/ia64 since that option is common in drivers/xen. So I'm not sure why that option doesn't work for ia64. Alex should know more about this area, and it may simply come from a mis-configuration case... Configuring the serial console is far more painful than it should be right now on xen/ia64. This is due to the fact that xen and xenlinux both claim the same physical UART. On xen/x86, the physical UARTs are hidden from xenlinux using the config option such that only xen talks to the physical hardware and ttyS0 on xenlinux is actually xencons. Xen/ia64 leaves the serial driver in place, which allows xenlinux to claim the physical UART. We therefore have to disable input in xencons and play games with assigning xencons to ttyS values outside of what the serial driver typically claims. While not ideal, I think we should take the xen/x86 approach and disable serial access from dom0. At some point maybe we can add support to hide only the physical UART used by xen and allow dom0 to access any others that might be available. Such a feature would need to be aware of both I/O port and MMIO UARTs and handle UARTs described in ACPI namespace. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: To disable serial port for ia64 dom0 (RE: [Xen-ia64-devel] [PATCH 0/6] Add full evtchn mechanism forxen/ia64)
On Mon, 2006-05-22 at 15:22 +0800, Tian, Kevin wrote: But I'm not sure why I have to set option to be 'yes' explicitly: config XEN_DISABLE_SERIAL bool Disable serial port drivers default y So after making oldconfig, this option should be enabled automatically. Does I misunderstand the logic behind? :-( The is not set is logically equivalent to =n, so it's disabled because of our default config in buildconfigs. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-devel] Re: [PATCH] Disable auto-balloon on ia64
On Mon, 2006-05-22 at 21:33 +0800, Tian, Kevin wrote: OK, the question by far is that ia64 describes the memory hierarchy presented to domain by d-max_pages. Before balloon is ready, we at least need to ensure all frames covered by d-max_pages allocated for target domain. Then there're two alternatives: - Keep the first piece of change on increase_reservation, which ensures all pages including extra spaces allocated immediately. - Pass the extra memory size to xen at arch_set_info_guest, and then change xen/ia64 to only tell domain maximum pfns as d-max_pages-extra_size Both need to be changed again later if balloon is ready. So I prefer to option I which is simpler and can help Alex to do sync quickly. How do you think? I agree, I think we can get by with only the ia64 changes in the increase_reservation call. The other option seems more fragile. Keir, would you include the first chunk of Kevin's patch as a temporary solution until we have better ballooning support on xen/ia64 (should be soon)? Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH 0/6] Add full evtchn mechanism forxen/ia64
On Mon, 2006-05-22 at 16:26 +0200, Tristan Gingold wrote: Le Lundi 22 Mai 2006 16:12, Alex Williamson a écrit : Such a feature would need to be aware of both I/O port and MMIO UARTs and handle UARTs described in ACPI namespace. Thanks, Modifying ACPI to hide an UART seems to be very hard... Yes, very hard might even be an understatement ;^) Just an idea: if UART is used by Xen, it should reverse the interrupt line (unless shared...) In this case, Linux shouldn't be allowed to register an handler for this IRQ and should fail to use the UART. Right ? Good thought, I'd have to look at the serial driver to see what it would do in that case. It might end up switching to polling mode and still try to use the UART. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH 0/6] Add full evtchn mechanism forxen/ia64
While not ideal, I think we should take the xen/x86 approach and disable serial access from dom0. At some point maybe we can add support to hide only the physical UART used by xen and allow dom0 to access any others that might be available. Such a feature would need to be aware of both I/O port and MMIO UARTs and handle UARTs described in ACPI namespace. Thanks, Please try to turn off the dom0 console dynamically rather than via config option. It would be a shame to lose transparent paravirtualization just to turn off the console. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains
On 22 May 2006, at 15:51, Charles Coffing wrote: HVM domains need some extra memory free for the shadow page tables, otherwise they may crash the entire machine while they are running, or the HVM domain itself may crash (exact behavior depends on whether you have Yunhong's patch to change BUGs to domain_crash). This slack space is calculated into the memory size for HVM domains, but what happens if you then start a PV domain afterwards? Only the minimally required memory is freed up, then the PV domain takes it all, leaving the HVM domain with no slack == crash. Where does the slack from the previous HVM guest startup go? Are you saying that dom0 only frees up PV-guest-size minus existing-slack? -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: Overcommitting memory (was: Disable auto-balloon on ia64)
On 22 May 2006, at 16:12, Charles Coffing wrote: In shadow32.c, I see a FIXME comment that refers to shadow flush. Even if such things are done, can you put an upper limit on the runtime memory overhead for an HVM domain? Yes, it ought to be a space/time tradeoff. The shadow pagetables should be regarded merely as a cache. However, the current shadow mode's memory handling sucks. -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Fedora-xen] fedora-xen-ia64 first pass
Zhang, Xiantao wrote: [Mon May 22 2006, 02:48:37AM EDT] We have tried to boot xen with your tip, but found the configuration for domain0 opens dom0_VP mode, however, the dom0_VP option of xen was closed by default. Maybe this is the main reason why xen dies at booting xen0. Correct? If they don't match, it is impossible to boot up. Due to not familiar with rpmbuild scripts, so we have to modify it manually to try. Thanks, this was indeed the problem. Fixing this allows the boot to go further before it hits a panic. fedora-kernel-ia64 cset 16 contains this fix. Regards, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] fedora-xen-ia64 first pass
Akio Takebe wrote: [Mon May 22 2006, 04:09:43AM EDT] Which distro do you use on your rpmbuild system? Fedora5-ia64? or RHEL4? Fedora Rawhide, ISO images available from ftp://oss.sgi.com/projects/fedora/download/weekly/ Cannot we completely make fedora-xen-ia64 yet? I had the following error. Did I have mistakes? [..snip..] error: Could not open /root/fedora/fedora-xen-ia64/SRPMS/xen-3.0.2-4.src.rpm: No such file or directory This was the problem. The SRPMS directory does not exist. I updated bashrc-snippet to create this automatically, see fedora-kernel-ia64 cset 16. So I do the following step. Is this step the same as yours? 1. make rpm of kernel (as-is Anil's step) hg clone http://free.linux.hp.com/~agriffis/fedora-kernel-ia64 cd fedora-kernel-ia64 mkdir -p BUILD RPMS/ia64 source bashrc-snippet # might want this in your ~/.bashrc cd SPECS rpmbuild -ba kernel-2.6.spec 2. make xen # rpmbuild -bp xen.spec # cd ../BUILD/xen-unstable.hg/ # make xen # make tools # make install-tools # cp xen/xen.gz /boot/efi/efi/redhat/ Following full build of rpms, you should install the packages instead of installing manually. (I understand you installed manually here because the packages did not build completely... sorry!) However there are some dependencies needed from extras yet. While we are waiting for extras to be built in its entirety, I will supply a yum repository in a follow-up message. Regards, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: fedora-xen-ia64 first pass
Let's consolidate this thread to the fedora-xen mailing list rather than continuing to cross-post as I did initially. We can post patches and requests back to the other lists as help is needed from those communities. Regards, Aron ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains
On 22 May 2006, at 16:15, Charles Coffing wrote: Where does the slack from the previous HVM guest startup go? Are you saying that dom0 only frees up PV- guest- size minus existing- slack? Correct. Unless, of course, the HVM domain has eaten up some of the slack in the mean-time, in which case dom0 frees up PV-guest-size minus remaining-slack. The auto-ballooning logic is shagged then. xend should keep track of memory requirements (inc. max overheads) of every domain, then ensure dom0 memory usage is no greater than total memory minus sum of all other domains' memory requirements. How hard can that be? (Too hard for original author I guess ;-) ). Anyway, I'm going to back out the 4MB slack hack. Auto-ballooning can never be stable in its current form (consider a guest that temporarily balloons down from 128MB to 64MB, then another (HVM) guest starts, then it tries to balloon back to 128MB -- it'll fail, and the HVM guest will lose any headroom it required). -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] PATCH: split smpboot.c and create cpuhotplug.c
On 22 May 2006, at 08:57, Tristan Gingold wrote: this patch creates a new file: cpuhotplug.c. The content is the xenbus handler part of smpboot.c. The purpose is to be able to share this part with other architectures. Tested by compiling on i386. This raises the obvious question: why don't you use the rest of our smpboot.c to implement SMP bringup? It's all generic except the bit that sets up VCPU initial context. -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains
On 22 May 2006, at 16:38, Keir Fraser wrote: Unless, of course, the HVM domain has eaten up some of the slack in the mean-time, in which case dom0 frees up PV-guest-size minus remaining-slack. The auto-ballooning logic is shagged then. xend should keep track of memory requirements (inc. max overheads) of every domain, then ensure dom0 memory usage is no greater than total memory minus sum of all other domains' memory requirements. How hard can that be? (Too hard for original author I guess ;-) ). Anyway, I'm going to back out the 4MB slack hack. Auto-ballooning can never be stable in its current form (consider a guest that temporarily balloons down from 128MB to 64MB, then another (HVM) guest starts, then it tries to balloon back to 128MB -- it'll fail, and the HVM guest will lose any headroom it required). Actually, since there is an argument for keeping it for live migration, I'll keep it for the time being. But it does sound like auto-ballooning needs some more thought. I'll apply a suitable patch for ia64 shortly -- Keir ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] please pull xen-ia64-unstable.hg
Hi Keir, Thanks for helping us to get ia64 working again in xen-unstable.hg. To further improve the status of xen/ia64, please pull: http://xenbits.xensource.com/ext/xen-ia64-unstable.hg The tree is currently sync'd up to cset 10068 of the xen-unstable.hg tree. This finally switches us over to a virtual physical dom0 memory model and enables vif networking! Thanks to the whole xen/ia64 team, and especially to Isaku Yamahata for helping us reach this milestone. Thanks, Alex -- Alex Williamson HP Linux Open Source Lab ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] add SATA support in x86_64 and fix error handling in xm create
This patch changes two files: First, the x86_64 build config file, turning on SATA support. Second, tools/python/xen/xm/create.py. In the tools/python/xen/xm directory, main.py has good error messages that let the user know what failed; the other 'sub-command' classes don't always have such good messages which can lead to some inexplicable failures by the user-space tools. Standard practice is to except each error by type and react accordingly but in case the programmer does not anticipate a type of exception, standard practice is to put in a catch-all exception handler that excepts an 'Exception' object. Often in this case, the system will print out the exception and exit. If a sub-command excepts an 'Exception' object and the error is not specific to that sub-command, it should pass the exception up for main to handle. Especially in light of the fact that there is already a broad collection of good error messages in main, I believe that this will lead to better code re-use in the form of a one-stop-shop for error messages. In this patch I've changed only one of the general case exception handlers in one of the sub-commands (xm create) as a test-balloon to see if the xen community will accept future patches of this type. Singed-off-by: Daniel Miles [EMAIL PROTECTED] diff -r 7cbc1fc8dbea buildconfigs/linux-defconfig_xen_x86_64 --- a/buildconfigs/linux-defconfig_xen_x86_64 Tue May 16 18:54:41 2006 +++ b/buildconfigs/linux-defconfig_xen_x86_64 Mon May 22 17:23:31 2006 @@ -934,8 +934,8 @@ # # Please see Documentation/ide.txt for help/info on IDE drives # -# CONFIG_BLK_DEV_IDE_SATA is not set -# CONFIG_BLK_DEV_HD_IDE is not set +CONFIG_BLK_DEV_IDE_SATA=y +CONFIG_BLK_DEV_HD_IDE=y CONFIG_BLK_DEV_IDEDISK=m CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDECS is not set diff -r 7cbc1fc8dbea tools/python/xen/xm/create.py --- a/tools/python/xen/xm/create.py Tue May 16 18:54:41 2006 +++ b/tools/python/xen/xm/create.py Mon May 22 17:23:31 2006 @@ -903,10 +903,15 @@ else: err(%s % ex.faultString) except Exception, ex: +#main.py has good error messages that let the user know what failed. +#unless the error is a create.py specific thing, it should be handled +#at main. The purpose of this general-case 'Exception' handler is to +#clean up create.py specific processes/data but since create.py does +#not know what to do with the error, it should pass it up. import signal if vncpid: os.kill(vncpid, signal.SIGKILL) -err(str(ex)) +raise ex dom = sxp.child_value(dominfo, 'name') signature.asc Description: This is a digitally signed message part ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] add SATA support in x86_64 and fix error handling in xm create
Hi Dan, Daniel Miles wrote: [Mon May 22 2006, 07:47:16PM EDT] -# CONFIG_BLK_DEV_IDE_SATA is not set -# CONFIG_BLK_DEV_HD_IDE is not set +CONFIG_BLK_DEV_IDE_SATA=y +CONFIG_BLK_DEV_HD_IDE=y Are you sure this is what you want? BLK_DEV_IDE_SATA is deprecated in favor of libsata. (Search for SCSI_SATA in menuconfig to see what I'm referring to.) +#main.py has good error messages that let the user know what failed. +#unless the error is a create.py specific thing, it should be handled +#at main. The purpose of this general-case 'Exception' handler is to +#clean up create.py specific processes/data but since create.py does +#not know what to do with the error, it should pass it up. Style request: could you put a space between the comment marker (#) and the comment? Aron pgpIWEnb5imKt.pgp Description: PGP signature ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] fedora-xen-ia64 first pass
Hi, Aron
Thank you for your help.
I can make RPMS/ia64/xen-3.0.2-4.ia64.rpm.
fedora-xen-ia64/RPMS/ia64/xen-3.0.2-4.ia64.rpm includes all tools of xen.
(don't includes xen(hypervisor) and domain's kernel)
But I cannot make fedora-kernel-ia64 yet.
===
gcc -Wp,-MD,arch/ia64/kernel/.irq_lsapic.o.d -nostdinc -isystem
/usr/lib/gcc/ia64-redhat-linux/4.1.0/include -D__KERNEL__ -Iinclude -include
include/linux/autoconf.h -DHAVE_W
ORKING_TEXT_ALIGN -DHAVE_MODEL_SMALL_ATTRIBUTE -DHAVE_SERIALIZE_DIRECTIVE
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Os -fomit-frame-poin
ter -g -pipe -ffixed-r13 -mfixed-range=f12-f15,f32-f127 -falign-functions=32
-frename-registers -fno-optimize-sibling-calls -Wdeclaration-after-statement
-Wno-pointer-sign -mc
onstant-gp -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(irq_lsapic)
-DKBUILD_MODNAME=KBUILD_STR(irq_lsapic) -c -o
arch/ia64/kernel/.tmp_irq_lsapic.o arch/ia64/kernel/ir
q_lsapic.c
mm/page_alloc.c: In function 'alloc_node_mem_map':
mm/page_alloc.c:2143: error: 'MAX_ORDER_NR_PAGES' undeclared (first use in this
function)
mm/page_alloc.c:2143: error: (Each undeclared identifier is reported only once
mm/page_alloc.c:2143: error: for each function it appears in.)
make[1]: *** [mm/page_alloc.o] Error 1
make: *** [mm] Error 2
make: *** Waiting for unfinished jobs
===
This error is caused by SOURCES/linux-2.6-xen-ia64-10022.patch
MAX_ORDER_NR_PAGES is not defined.
What does this patch mean?
===
@@ -2124,14 +2127,22 @@ static void __init alloc_node_mem_map(st
#ifdef CONFIG_FLAT_NODE_MEM_MAP
/* ia64 gets its own node_mem_map, before this, without bootmem */
if (!pgdat-node_mem_map) {
- unsigned long size;
+ unsigned long size, start, end;
struct page *map;
- size = (pgdat-node_spanned_pages + 1) * sizeof(struct page);
+ /*
+* The zone's endpoints aren't required to be MAX_ORDER
+* aligned but the node_mem_map endpoints must be in order
+* for the buddy allocator to function correctly.
+*/
+ start = pgdat-node_start_pfn ~(MAX_ORDER_NR_PAGES - 1);
+ end = pgdat-node_start_pfn + pgdat-node_spanned_pages;
+ end = ALIGN(end, MAX_ORDER_NR_PAGES);
+ size = (end - start) * sizeof(struct page);
map = alloc_remap(pgdat-node_id, size);
if (!map)
map = alloc_bootmem_node(pgdat, size);
- pgdat-node_mem_map = map;
+ pgdat-node_mem_map = map + (pgdat-node_start_pfn - start);
}
#ifdef CONFIG_FLATMEM
/*
===
I'm not clear about directory construction.
What do each directory mean?
I want to know the following directory's meaning.
# ls -F fedora-kernel-ia64/BUILD/kernel-2.6.16/
Config.mk extract.pub kernel.pub kernel.sec linux-2.6.16.ia64/
pubring.gpg random_seed secring.gpg vanilla/ xen/ xen-10022/
Are kernels of domain0/domainU made at linux-2.6.16.ia64?
If so, each linux-2.6.16.ia64 must be remade at each building time.
Am I right?
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
