Bug 210637
|
Description
Aron Griffis
2006-10-13 14:19:09 UTC
Regarding the safeness of pulling in these changesets, note these are all
ia64-specific. Here is the list of files affected.
Kernel patches:
$ filterdiff --strip=1 linux-2.6-xen-ia64-*.patch | diffstat
arch/ia64/Kconfig | 14
arch/ia64/kernel/setup.c | 3
arch/ia64/xen/Makefile | 3
arch/ia64/xen/hypervisor.c | 363 +++++++++++++++++-----
arch/ia64/xen/util.c | 2
arch/ia64/xen/xcom_hcall.c | 469 +++++++++++++++++++++++++++++
arch/ia64/xen/xcom_privcmd.c | 608 +++++++++++++++++++++++++++++++++++++-
arch/ia64/xen/xencomm.c | 244 +++++++++++++++
arch/ia64/xen/xensetup.S | 21 -
drivers/xen/privcmd/privcmd.c | 13
include/asm-ia64/hypercall.h | 288 +++++++++---------
include/asm-ia64/hypervisor.h | 11
include/asm-ia64/maddr.h | 15
include/asm-ia64/xen/privop.h | 3
include/asm-ia64/xen/xcom_hcall.h | 74 ++++
include/asm-ia64/xen/xencomm.h | 57 +++
include/xen/interface/arch-ia64.h | 80 ++---
lib/Makefile | 2
18 files changed, 1961 insertions(+), 309 deletions(-)
Hypervisor patches:
$ filterdiff --strip=1 xen-ia64-*.patch | diffstat
arch/ia64/Rules.mk | 8
arch/ia64/asm-offsets.c | 2
arch/ia64/linux-xen/sal.c | 75 +++
arch/ia64/linux-xen/unaligned.c | 20 -
arch/ia64/tools/p2m_expose/Makefile | 28 +
arch/ia64/tools/p2m_expose/README.p2m_expose | 12
arch/ia64/tools/p2m_expose/expose_p2m.c | 185 +++++++++
arch/ia64/vmx/Makefile | 1
arch/ia64/vmx/mmio.c | 12
arch/ia64/vmx/optvfault.S | 518 +++++++++++++++++++++++++++
arch/ia64/vmx/vlsapic.c | 6
arch/ia64/vmx/vmmu.c | 23 -
arch/ia64/vmx/vmx_entry.S | 2
arch/ia64/vmx/vmx_init.c | 3
arch/ia64/vmx/vmx_interrupt.c | 19
arch/ia64/vmx/vmx_ivt.S | 8
arch/ia64/vmx/vmx_phy_mode.c | 53 --
arch/ia64/vmx/vmx_process.c | 124 +++---
arch/ia64/vmx/vmx_vcpu.c | 32 +
arch/ia64/xen/Makefile | 2
arch/ia64/xen/dom0_ops.c | 5
arch/ia64/xen/domain.c | 59 ++-
arch/ia64/xen/faults.c | 6
arch/ia64/xen/fw_emul.c | 2
arch/ia64/xen/hypercall.c | 93 +---
arch/ia64/xen/mm.c | 184 +++++++++
arch/ia64/xen/regionreg.c | 2
arch/ia64/xen/vcpu.c | 36 -
arch/ia64/xen/vhpt.c | 166 ++++++--
arch/ia64/xen/xen.lds.S | 3
arch/ia64/xen/xencomm.c | 380 +++++++++++++++++++
arch/ia64/xen/xenmem.c | 95 ++--
arch/ia64/xen/xenpatch.c | 124 ++++++
arch/ia64/xen/xensetup.c | 28 -
arch/ia64/xen/xentime.c | 2
include/asm-ia64/dom_fw.h | 7
include/asm-ia64/domain.h | 25 -
include/asm-ia64/guest_access.h | 152 ++++---
include/asm-ia64/ia64_int.h | 4
include/asm-ia64/linux-xen/asm/cache.h | 2
include/asm-ia64/linux-xen/asm/pgtable.h | 14
include/asm-ia64/linux-xen/asm/processor.h | 18
include/asm-ia64/linux-xen/asm/system.h | 1
include/asm-ia64/linux/asm/sal.h | 10
include/asm-ia64/mm.h | 19
include/asm-ia64/perfc_defn.h | 27 +
include/asm-ia64/uaccess.h | 18
include/asm-ia64/vhpt.h | 37 +
include/asm-ia64/vmx.h | 1
include/asm-ia64/vmx_vcpu.h | 4
include/asm-ia64/xenkregs.h | 3
include/public/arch-ia64.h | 80 +---
52 files changed, 2229 insertions(+), 511 deletions(-)
Note that only two files aren't in an ia64-specific path. Here is that diff:
$ filterdiff --strip=1 -p1 -i 'lib/Makefile' -i 'drivers/xen/privcmd/privcmd.c'
*.patch
--- lib/Makefile Sun Oct 08 18:30:31 2006 -0600
+++ lib/Makefile Sun Oct 08 18:35:17 2006 -0600
@@ -45,9 +45,7 @@ obj-$(CONFIG_TEXTSEARCH_FSM) += ts_fsm.o
obj-$(CONFIG_TEXTSEARCH_FSM) += ts_fsm.o
obj-$(CONFIG_SWIOTLB) += swiotlb.o
-ifneq ($(CONFIG_XEN_IA64_DOM0_NON_VP),y)
swiotlb-$(CONFIG_XEN) := ../arch/i386/kernel/swiotlb.o
-endif
hostprogs-y := gen_crc32table
clean-files := crc32table.h
--- drivers/xen/privcmd/privcmd.c Sun Oct 01 19:10:18 2006 -0600
+++ drivers/xen/privcmd/privcmd.c Mon Oct 02 14:03:42 2006 -0600
@@ -83,18 +83,7 @@ static int privcmd_ioctl(struct inode *i
: "r8", "r10", "memory" );
}
#elif defined (__ia64__)
- __asm__ __volatile__ (
- ";; mov r14=%2; mov r15=%3; "
- "mov r16=%4; mov r17=%5; mov r18=%6;"
- "mov r2=%1; break 0x1000;; mov %0=r8 ;;"
- : "=r" (ret)
- : "r" (hypercall.op),
- "r" (hypercall.arg[0]),
- "r" (hypercall.arg[1]),
- "r" (hypercall.arg[2]),
- "r" (hypercall.arg[3]),
- "r" (hypercall.arg[4])
- : "r14","r15","r16","r17","r18","r2","r8","memory");
+ ret = privcmd_hypercall(&hypercall);
#endif
}
break;
in kernel-2.6.18-1.2728.el5 Is it truly fixed? Both Xen and Kernel-Xen should be fixed. At this point, I never see the xencomm code in xen-3.0.3-rc3 src. and Plan to fix FC6? (In reply to comment #2) > in kernel-2.6.18-1.2728.el5 No, none of these patches have been included. I think this was marked incorrectly because Don and Rik thought the patches were in xen-3.0.3 Created attachment 139540 [details]
xen-ia64 patches, ported to kernel-2.6.18-1.2736.el5
Created attachment 139541 [details]
linux-xen-ia64 patches, ported to kernel-2.6.18-1.2736.el5
Is it truly fixed? It seems nothing changes in Kernel. (In reply to comment #7) > Is it truly fixed? > It seems nothing changes in Kernel. No, see comment #4 From: Atsushi SAKAI (Fujitsu) Date: Tue, 07 Nov 2006 18:30:36 +0900 Subject: [ipf-virtualization]Test Results about Aron's package Hi, We do the follwing tests to the Aron's packages and it passed. VTI Create/Destroy One U and One VTI Create VTI Kernel Build Two VTI Coexist Four VTI Coexist One_VTI One_XenU One_SMP_VTI VTI_Without_vif One_SMP_XenU Of course, the error messsages like "kernel unaligned access" and "Can't allocate memory" are erased. "kernel aligned access" is checked by ping the packet to outbound from DomU. "Can't allocate memory" is checked by Create/Destroy 300times. This test was done by KUWAMURA Shin'ya. Thanks Atsushi SAKAI *** Bug 214785 has been marked as a duplicate of this bug. *** Aron, once we get pm/devel/qa acks, please submit the patches to rhkernel-list and virtualist. (In reply to comment #12) > Aron, once we get pm/devel/qa acks, please submit the patches to rhkernel-list > and virtualist. Thanks Rik, I'll do that. Sorry for the slowness on my part. I recall now that you mentioned rhkernel-list on IRC but I'd forgotten about it. I'm subscribed now and will post the patches after pm/devel/qa acks. *** Bug 212540 has been marked as a duplicate of this bug. *** I've got a box running a 2746-based kernel with these patches on an HP zx2000. The situation is definitely better, but still no-go for me. Not getting a dom0 kp when I try a guest install, but I do get a guest kp sometimes after retrieving minstg2.img (Kernel panic - not syncing: Unable to reduce memory reservation) and if I get past that, the installer hangs indefinitely on "Searching for Red Hat Enterprise Linux Server installations...". OK, I see the source of the initial confusion why we thought it would be upstream. The changeset numbers are all smaller than what's in 3.0.3 final. Unfortunately, these are from a different repository :) Aron, Jarod, are all of the patches you want merged in RHEL5 upstream in xen-unstable? (In reply to comment #16) > [...] and if I get past that, the installer hangs indefinitely on > "Searching for Red Hat Enterprise Linux Server installations...". Okay, not indefinitely. Let it run for a good hour or so. During that hour, it was pegging the cpu. It finally gave up the ghost though, once again spewing this to the console: Kernel panic - not syncing: Unable to reduce memory reservation Just tried the same setup on another ia64 machine. I get identical results on an HP Integrity rx2620 (dual Montecito) box. Same results on an 8-way Montecito Intel devel box. Also noticed that on these smp boxes, they both come up on a single processor and only 497M of RAM. The virt-manager GUI does recognize the right amount of cpus and memory though. Is this intended behavior on ia64? I don't see this on x86 or x86_64... I'm aware of the dom0_mem=xM parameter, and have used that successfully up to a certain amount of memory (~800M, iirc), but experienced failures trying to allocate anything over 1GB (again, iirc). Raising severity to agree with Issue Tracker 106342 which is a sev=2. (In reply to comment #17) > Aron, are all of the patches you want merged in RHEL5 upstream in > xen-unstable? Yes, but they're mixed in with plenty of patches you don't want, which is why I pulled them out explicitly and ported them to the RHEL5 kernel. (In reply to comment #16) > I've got a box running a 2746-based kernel with these patches on an HP zx2000. > The situation is definitely better, but still no-go for me. Not getting a dom0 > kp when I try a guest install, but I do get a guest kp sometimes after > retrieving minstg2.img (Kernel panic - not syncing: Unable to reduce memory > reservation) and if I get past that, the installer hangs indefinitely on > "Searching for Red Hat Enterprise Linux Server installations...". These patches aren't expected to fix xenguest-install because the blktap patches are separate. Is that what you're trying to do here? (In reply to comment #20) > Same results on an 8-way Montecito Intel devel box. > > Also noticed that on these smp boxes, they both come up on a single processor > and only 497M of RAM. The virt-manager GUI does recognize the right amount of > cpus and memory though. Is this intended behavior on ia64? I don't see this on > x86 or x86_64... Yes, that is expected behavior. Xen/ia64 upstream is working on changing to max processors and memory by default on dom0 (to match x86) but it isn't ready for inclusion in RHEL5. > I'm aware of the dom0_mem=xM parameter, and have used that successfully up to a > certain amount of memory (~800M, iirc), but experienced failures trying to > allocate anything over 1GB (again, iirc). Yeah, you're likely to still find problems here. Best to stick with the default for now. (In reply to comment #22) > (In reply to comment #16) > > I've got a box running a 2746-based kernel with these patches on an HP zx2000. > > The situation is definitely better, but still no-go for me. Not getting a dom0 > > kp when I try a guest install, but I do get a guest kp sometimes after > > retrieving minstg2.img (Kernel panic - not syncing: Unable to reduce memory > > reservation) and if I get past that, the installer hangs indefinitely on > > "Searching for Red Hat Enterprise Linux Server installations...". > > These patches aren't expected to fix xenguest-install because the blktap patches > are separate. Is that what you're trying to do here? If we don't have blktap support, we fall back to loop mounts in xenguest-install (er, now virt-install). I get to the point where its searching the disk for installs, so I don't think lack of blktap support is the problem (neither did some other folks here I talked to). Could be that we're doing something bad w/non-blktap installs now though... However, with these patches and installing into a chrooted loop-mounted image via yum, then some manual tweaking and bypassing pygrub, I do now have a xen guest up and running, complete with networking. Tons of unaligned access messages started spewing to the console when dhclient kicked in, but I can ssh into the guest and muck around as I please. Cool! Progress... :) (In reply to comment #23) > However, with these patches and installing into a chrooted loop-mounted image > via yum, then some manual tweaking and bypassing pygrub, I do now have a xen > guest up and running, complete with networking. Tons of unaligned access > messages started spewing to the console when dhclient kicked in, but I can ssh > into the guest and muck around as I please. Cool! Progress... :) Good to hear! The unaligned messages are fixed by the patch in bug 212645. Both of these patchsets are available in my testing rpms at http://free.linux.hp.com/~agriffis/rhel5/ (password-protected; see ipf-virtualization archives or email me for access) Created attachment 141556 [details] hypervisor patches for ia64 hvm bugs Required patches for ia64 HVM from Fred Yang (Intel) on ipf-virtualization ML: [1] xen-ia64-unstable 12005 Revert PAL_VM_SUMMARY and PAL_VM_INFO handling for VTI domain http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=01b257e72d5e [2] xen-ia64-unstable 12007 [IA64] Accelerate RSM, SSM and MOV_TO_PSR http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=622bb65e2011 [3] xen-ia64-unstable 12014 [IA64] physical mode fix http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=9c649ca5c1cc [4] xen-ia64-unstable 12015 [IA64] Remove ar.rsc save/restore code in HV http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=0a490cf4b21d [5] xen-ia64-unstable 12017 [IA64] fix rsc save/restore http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=5ebc7ee315cc [6] xen-ia64-unstable 12334 [IA64][VMX] Fix 3G memory limit for VTi domain. http://xenbits.xensource.com/xen-unstable.hg?cs=2a7b8d75ebf7 [7] xen-ia64-unstable 12387 [IA64] Fix SMP Windows boot failure http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=4816a891b3d6 Created attachment 141557 [details] xenlinux patch for xenperf repair with xencomm Required patch for ia64 xenperf, which is otherwise broken by the xencomm patches in this bug, from Fred Yang (Intel) on ipf-virtualization ML: [8] xen-ia64-unstable 12006 [IA64] fix xenperf http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=5cd95a6f8412 Created attachment 141559 [details]
patch to xen (tools) rpm
This patch looks huge because it's the full gamut of requested ia64 patches in
this bug. Technically only a small amount is necessary to update the tools and
header files in the xen rpm, but it doesn't seem like a good idea to separate
those patches from the associated linux-2.6-sparse and hypervisor patches.
Here is what really matters from this patch:
$ filterdiff -p1 -i 'tools/*' -i '*.h' xen-3.0.3-ia64-11859.patch | diffstat
a/xen/include/asm-ia64/vmx_uaccess.h | 156 --
b/linux-2.6-xen-sparse/include/asm-ia64/xen/xcom_hcall.h | 74 +
b/linux-2.6-xen-sparse/include/asm-ia64/xen/xencomm.h | 57 +
b/xen/include/asm-ia64/flushtlb.h | 89 +
b/xen/include/asm-ia64/linux/hash.h | 58 +
b/xen/include/asm-ia64/p2m_entry.h | 76 +
b/xen/include/asm-ia64/tlb_track.h | 152 ++
b/xen/include/asm-ia64/vcpumask.h | 60 +
linux-2.6-xen-sparse/include/asm-ia64/hypercall.h | 292 ++---
linux-2.6-xen-sparse/include/asm-ia64/hypervisor.h | 27
linux-2.6-xen-sparse/include/asm-ia64/maddr.h | 15
linux-2.6-xen-sparse/include/asm-ia64/xen/privop.h | 3
linux-2.6-xen-sparse/include/asm-ia64/xen/xcom_hcall.h | 2
linux-2.6-xen-sparse/include/asm-ia64/xen/xencomm.h | 3
tools/blktap/drivers/blktapctrl.c | 4
tools/blktap/drivers/tapdisk.c | 4
tools/blktap/drivers/tapdisk.h | 1
tools/blktap/lib/blktaplib.h | 7
tools/ioemu/vl.c | 24
tools/libxc/ia64/xc_ia64_hvm_build.c | 10
tools/libxc/ia64/xc_ia64_linux_restore.c | 3
tools/libxc/ia64/xc_ia64_linux_save.c | 3
tools/libxc/xc_linux_build.c | 2
tools/libxc/xenctrl.h | 9
tools/python/xen/xend/image.py | 2
tools/xentrace/xenctx.c | 108 +-
xen/include/asm-ia64/dom_fw.h | 9
xen/include/asm-ia64/domain.h | 63 -
xen/include/asm-ia64/guest_access.h | 152 +-
xen/include/asm-ia64/ia64_int.h | 4
xen/include/asm-ia64/linux-xen/asm/cache.h | 2
xen/include/asm-ia64/linux-xen/asm/pgtable.h | 34
xen/include/asm-ia64/linux-xen/asm/processor.h | 18
xen/include/asm-ia64/linux-xen/asm/system.h | 1
xen/include/asm-ia64/linux/asm/sal.h | 10
xen/include/asm-ia64/mm.h | 24
xen/include/asm-ia64/perfc_defn.h | 65 +
xen/include/asm-ia64/privop.h | 4
xen/include/asm-ia64/tlb_track.h | 15
xen/include/asm-ia64/tlbflush.h | 10
xen/include/asm-ia64/uaccess.h | 18
xen/include/asm-ia64/vcpu.h | 317 ++---
xen/include/asm-ia64/vhpt.h | 45
xen/include/asm-ia64/vmmu.h | 3
xen/include/asm-ia64/vmx.h | 1
xen/include/asm-ia64/vmx_pal_vsa.h | 7
xen/include/asm-ia64/vmx_phy_mode.h | 9
xen/include/asm-ia64/vmx_platform.h | 2
xen/include/asm-ia64/vmx_vcpu.h | 809
+++++++--------
xen/include/asm-ia64/vmx_vpd.h | 1
xen/include/asm-ia64/vtm.h | 3
xen/include/asm-ia64/xenkregs.h | 3
xen/include/asm-ia64/xensystem.h | 1
xen/include/public/arch-ia64.h | 86 -
54 files changed, 1831 insertions(+), 1126 deletions(-)
Note that the blktap patches also require this change in kernel-2.6.18-ia64-xen.config -# CONFIG_XEN_BLKDEV_TAP is not set +CONFIG_XEN_BLKDEV_TAP=m Sorry, comment 28 should have been in bug 208895 Per discussion with Prarit and Aron,
> Bug 210637: patches from xen-ia64-unstable
> Status-ASSIGNED to Aron Griffis, patch attached. You've had dialog.
Should be in RHEL5.0 before RC.
Aron please ACK for devel; QA please ACK/NAK accordingly.
I need some explanation of the changes to the common code before I can ack this (blktap changes, xentrace, etc.) Ping devel.......... Please ACK. Per Daniel, this is required for Xen TP on ia64. Note that per comment #27, the entire patch (which is hugh) is not required. Devel, can we get the actual patch required so Engineering can review and comment. Functionality-wise, these patches are indeed a huge step forward. With these added to the mix, I've got an ia64 xen guest all the way up and running, complete with networking. Its still a bit of a hack to get it up and running (can't use virt-install and/or blktap), but its better than the current situation... Created attachment 142639 [details]
kernel-2.6.18-1.2747.el5-xen-ia64-linux.patch (kernel patch)
Created attachment 142640 [details]
kernel-2.6.18-1.2747.el5-xen-ia64-xen.patch (hypervisor patch)
Comment on attachment 141559 [details]
patch to xen (tools) rpm
Obsoleting huge tools patch, will follow up with applicable subset
Created attachment 142684 [details]
kernel-2.6.18-1.2747.el5-xen-ia64-linux.patch (without blktap)
Removed blktap support, to be applied via separate patch to make collisions
easier to fix.
Escalating for RHEL5.0 consideration per Thursday's RHEL5 meeting. We need a DEVEL ACK (Aron/Prarit or your management) assuming comment #38 contains final patch. Then QA can review patch and ACK to NAK. Also will need new bugzilla for blktap patch mentioned above and now separate from the patch in comment #38 (blktap patch may not make RHEL5.0). devel ACK (is this all I do to ACK the bug? haven't done this before) Jay: regarding common code changes, there are none in this patch. I extracted the blktap changes and put them in bug 208895 QE ack for RHEL5. in 2.6.18-1.2839.el5 *** Bug 215756 has been marked as a duplicate of this bug. *** A package has been built which should help the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |