Red Hat Bugzilla – Bug 210637
patches from xen-ia64-unstable
Last modified: 2010-10-22 02:26:14 EDT
Description of problem:
There are some important patches queued at
http://xenbits.xensource.com/ext/xen-ia64-unstable.hg to fix issues in xen on
ia64. Unfortunately these patches won't be in 3.0.3 so I'm requesting they be
included directly in FC6 and RHEL5. Probably the easiest method would be for
Juan to pull them into his tree (from which the xen patch is generated) instead
of including them in the spec file.
Here are the changesets listed by category. If you'd prefer patches instead of
a pointer to the tree, I can provide them.
11702:5c97ef4c7147 [IA64] Use xencomm for hypercalls.
11704:c3f71a4ed653 [IA64] Implement fast hypercall for physdevop eoi.
11721:1ec09a35d13d [IA64] add GNTTABOP_copy to xencommize_grant_table_op
11722:3f3a818d56f5 [IA64] revert xen-ia64-unstable.hg cset 11039
11723:49bf2381e009 [IA64] xencomm_privcmd_sched_op
11724:4786a0b3d6c5 [IA64] remove getmeminfo.nr_pages trick from xencomm
11726:0bb486157ff5 [IA64] expose p2m table. xen side part.
11727:d1d9f3f6ca09 [IA64] p2m exposure. linux side part.
11728:c1a8785f0eb1 [IA64] p2m exposure test module
11729:3e9fcbee3c09 [IA64] fix sparse tree build with p2m exposure disabled
11730:77f554ef7484 [IA64] update buildconfigs for p2m exposure
11457:36a3c92cdf8f [IA64] fix a vhpi bug
11459:997bd5fcf307 [IA64] Fix a bug in set_rse_reg
11460:da942e577e5e [IA64] Instruction emulation patch
11606:1824ee11fc53 [IA64] pickled code fix
11609:7b250cf49e50 [IA64] create page table for virtual frame table
11610:9da2d9b48ff8 [IA64] Complete fpswa handler retry mechanism
11636:3470d9cd27e5 [IA64] Modify p2m converter to avoid hypervisor crash
11637:f6007621cc0c [IA64] VTi TLB miss fix
11640:53ec7e3d3a8a [IA64] Fix a VTi physical mode bug
11705:6268aa7b9177 [IA64] Bind event channels of VT-i domain to vcpu 0
11706:64290e7622d2 [IA64] Prevent domains to itc/ptd in shared_info_va.
11712:6e7cc23ab18c [IA64] backport check_sal_cache_flush()
11458:a34659228c24 [IA64] Avoid iterative VHPT purges
11607:5292d57b0771 [IA64] Accelerate some virtualization faults
11703:bacae4057790 [IA64] Renumber dom0vp hypercalls and reformat comments.
11707:a3a079af0e92 [IA64] avoid long time interrupt masking.
11708:3f28ffed6fff [IA64] add perfcounter for vTLB flush.
11709:ce9816c14040 [IA64] add perfcounter to mm.c
11710:0c7e58ba4fbd [IA64] add perfcounter of dom0vp_phystomach and dom0vp_machtophys
11742:61504e80defa [IA64] __read_mostly
11743:6fae3a36f50b [IA64] added __read_mostly to some variables
11745:5176c3ea3293 [IA64] per vcpu vhpt
11608:06bec182a66e [IA64] warning fix
11638:92bd25c46f27 [IA64] do not export XSI_BASE, use set_shared_info_va
11641:914c44d10c8d [IA64] warning fix
11711:5727c3c4070e [IA64] don't export GPFN_xxx flags.
11725:7cfc7cb7cea7 [IA64] Clean up extern declarations in arch/ia64/xen/domain.c
11740:70d5d92066e5 [IA64] add a warning message when ioremap hypercall fails
11741:e9c7f965e70a [IA64] make efi_print()'s output more readable
11744:4eb6e2ec1b39 [IA64] Remove test of dead CONFIG_XEN_IA64_DOM0_NON_VP
11639:a947ca5d4731 [IA64] initial xen relocation support
Regarding the safeness of pulling in these changesets, note these are all
ia64-specific. Here is the list of files affected.
$ 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(-)
$ 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'
--- 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
swiotlb-$(CONFIG_XEN) := ../arch/i386/kernel/swiotlb.o
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),
- "r" (hypercall.arg),
- "r" (hypercall.arg),
- "r" (hypercall.arg),
- "r" (hypercall.arg)
- : "r14","r15","r16","r17","r18","r2","r8","memory");
+ ret = privcmd_hypercall(&hypercall);
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
We do the follwing tests to the Aron's packages and it passed.
One U and One VTI Create
VTI Kernel Build
Two VTI Coexist
Four VTI Coexist
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.
*** 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
(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
(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
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
(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:
 xen-ia64-unstable 12005 Revert PAL_VM_SUMMARY and PAL_VM_INFO
handling for VTI domain
 xen-ia64-unstable 12007 [IA64] Accelerate RSM, SSM and MOV_TO_PSR
 xen-ia64-unstable 12014 [IA64] physical mode fix
 xen-ia64-unstable 12015 [IA64] Remove ar.rsc save/restore code in HV
 xen-ia64-unstable 12017 [IA64] fix rsc save/restore
 xen-ia64-unstable 12334 [IA64][VMX] Fix 3G memory limit for VTi domain.
 xen-ia64-unstable 12387 [IA64] Fix SMP Windows boot failure
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:
 xen-ia64-unstable 12006 [IA64] fix xenperf
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
-# CONFIG_XEN_BLKDEV_TAP is not set
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.
*** 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.