[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
On Mon, Sep 10, 2007 at 09:56:11AM +0100, Keir Fraser wrote: > Hi, > > A provisional patchqueue for Xen 3.1.1 is available at > http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with > http://xenbits.xensource.com/xen-3.1-testing.hg. > > Please kick this pq around and check whether the patches you want to see in > 3.1.1 are included. 15214-5710c94e6539 is reverted by 15239-656b8175f4f2. Should it be removed from the queue and 15239-656b8175f4f2 remade to remove the parts that revert 15214? -- Eduardo ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Keir Fraser wrote: > Hi, > > A provisional patchqueue for Xen 3.1.1 is available at > http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with > http://xenbits.xensource.com/xen-3.1-testing.hg. > > Please kick this pq around and check whether the patches you want to see in > 3.1.1 are included. > > -- Keir Sorry for being late to the party. I think if we can pull in the fixes to QEMU and xend for the fully virtualized live migration, that would be good. Changesets: 15778 15779 15780 Thanks, Chris Lalancette ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Can you please provide a patch to apply to xen-3.1-testing.pq.hg? The patches you add to the queue should have the same style of changeset comment as the existing ones -- 'hg export' format plus the two xen-unstable changeset references immediately after the signed-off-by line(s). I've cc'ed Ben Guthro since he also has proposed a few patches, and I'd like to receive a patch from him for those too. Including 15185, since I changed my mind on that one! Fix the odd characters in changeset comments at the same time, if they're still causing you problems. Thanks, Keir On 11/9/07 16:15, "Alex Williamson" <[EMAIL PROTECTED]> wrote: > >Updated cset numbers now that all the ia64 patches are merged into > mainline... > > On Mon, 2007-09-10 at 13:18 -0600, Alex Williamson wrote: >> http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/6644d8486266 >> ia64/15762:6644d8486266 - cleanup NVRAM failure case > > Now > http://xenbits.xensource.com/staging/xen-unstable.hg?rev/6644d8486266 > 15850:6644d8486266 > >> http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/f88eea67a469 >> *ia64/15764:f88eea67a469 - move NVRAM from /usr to /var > > Now > http://xenbits.xensource.com/staging/xen-unstable.hg?rev/f88eea67a469 > 15852:f88eea67a469 (but you'll still need to use the modified version > attached previously) > > Thanks, > > Alex ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Updated cset numbers now that all the ia64 patches are merged into mainline... On Mon, 2007-09-10 at 13:18 -0600, Alex Williamson wrote: > http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/6644d8486266 > ia64/15762:6644d8486266 - cleanup NVRAM failure case Now http://xenbits.xensource.com/staging/xen-unstable.hg?rev/6644d8486266 15850:6644d8486266 > http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/f88eea67a469 > *ia64/15764:f88eea67a469 - move NVRAM from /usr to /var Now http://xenbits.xensource.com/staging/xen-unstable.hg?rev/f88eea67a469 15852:f88eea67a469 (but you'll still need to use the modified version attached previously) Thanks, Alex -- Alex Williamson HP Open Source & Linux Org. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
On Mon, 2007-09-10 at 09:56 +0100, Keir Fraser wrote:
> Hi,
>
> A provisional patchqueue for Xen 3.1.1 is available at
> http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
> http://xenbits.xensource.com/xen-3.1-testing.hg.
>
> Please kick this pq around and check whether the patches you want to see in
> 3.1.1 are included.
Hi Keir,
Here's a proposed list of patches for ia64:
Must have fixes:
http://xenbits.xensource.com/xen-unstable.hg?rev/51f5bea7b0d8
15348:51f5bea7b0d8 - adds free_irq(), necessary for build
http://xenbits.xensource.com/xen-unstable.hg?rev/b46c2ff6dfb0
15331:b46c2ff6dfb0 - fixes boot on NUMA systems
http://xenbits.xensource.com/xen-unstable.hg?rev/f536eb8576ee
15579:f536eb8576ee - fix VTI domain shutdown
http://xenbits.xensource.com/xen-unstable.hg?rev/d4f59e652078
15096:d4f59e652078 - fix pcifront with CONFIG_NUMA
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/1483ef74511b
linux/56:1483ef74511b - update for acm interface changes
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-11/msg00358.html
ia64-sal-get-state-info - Avoid GFP_KERNEL allocation from interrupt
context. This was only recently fixed in upstream and is dependent on
other patches. This is the simple fix proposed on the mailing list.
Patch attached.
These are all related to working out bugs and save location for NVRAM
support (must have):
http://xenbits.xensource.com/xen-unstable.hg?rev/71377eab1874
15349:71377eab1874 - white space cleanup - necessary for subsequent
patches
http://xenbits.xensource.com/xen-unstable.hg?rev/634b7f7f8584
*15265:634b7f7f8584 - allow domu nvram saving to fail gracefully
http://xenbits.xensource.com/xen-unstable.hg?rev/1623f5f5094f
15364:1623f5f5094f - don't save NVRAM on PV guests
http://xenbits.xensource.com/xen-unstable.hg?rev/33cc64dcaead
15365:33cc64dcaead - create NVRAM save directory
http://xenbits.xensource.com/xen-unstable.hg?rev/fd0103b55504
15366:fd0103b55504 - error checking for creat NVRAM save directory
http://xenbits.xensource.com/xen-unstable.hg?rev/38d061886873
1:38d061886873 - avoid saving garbage to NVRAM on config error
http://xenbits.xensource.com/xen-unstable.hg?rev/2a5b463f2e8d
15557:2a5b463f2e8d - fix NVRAM save on reboot
http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/6644d8486266
ia64/15762:6644d8486266 - cleanup NVRAM failure case
http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/f88eea67a469
*ia64/15764:f88eea67a469 - move NVRAM from /usr to /var
These add the PCI Controller backend (high want - driver domains on some
systems won't work without this):
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/93a955c2bebb
linux/46:93a955c2bebb - introduces controller backend
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/a62cfa35d3b5
*linux/55:a62cfa35d3b5 - add hypercall to register i/o spaces
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/452c5d4a5537
*linux/61:452c5d4a5537 - enable controller as default PCI backend
http://xenbits.xensource.com/xen-unstable.hg?rev/601509daabfc
*15353:601509daabfc - xen side support for multiple i/o spaces
Patches with an asterisk above require some modification to apply (white
space/file location/invalid chunks). I've attached the modified
versions below. Also note that 15265 is intentionally applied after
15349 above. There's some screwiness around a merge for these and it
was easier to modify the white space in the smaller one and apply it
later.
Other ia64'ers, please speak up if there's something else missing.
Thanks,
Alex
--
Alex Williamson HP Open Source & Linux Org.
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1181644323 -3600
# Node ID 634b7f7f8584f478c9e45a98998c7e7c1b8e3b3d
# Parent e1c54c14220a4d4ab38d8a3d409ab678275a5426
[IA64] When a domU is destroyed, it will fall into NVRAM saving
path. But if there is no NVRAM file for the domU, the save operation
would fail. Then domU blocked by Xend's exception. This patch fixs
that issue.
Signed-off-by: Zhang Xin <[EMAIL PROTECTED]>
diff -r e1c54c14220a -r 634b7f7f8584 tools/libxc/ia64/xc_ia64_hvm_build.c
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c Tue Jun 12 11:29:27 2007 +0100
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c Tue Jun 12 11:32:03 2007 +0100
@@ -712,11 +712,15 @@ int xc_ia64_save_to_nvram(int xc_handle,
xc_get_hvm_param(xc_handle, dom, HVM_PARAM_NVRAM_FD, &nvram_fd);
if ( !IS_VALID_NVRAM_FD(nvram_fd) )
-{
PERROR("Nvram not be initialized. Nvram save fail!\n");
-return -1;
-}
-return copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);
+else
+copy_from_GFW_to_nvram(xc_handle, dom, (int)nvram_fd);
+
+// although save to nvram maybe fail, we don't return any error number
+// to Xend. This is quite logical because damage of NVRAM on native would
+// not block OS's executive path. Return error number will cause an
exception
+// of Xe
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
On Monday, 10 September 2007 at 08:48, Ben Guthro wrote: > > Keir Fraser wrote: >> We're using mercurial patchqueues. Mercurial version 0.9.1. I've >> just cloned and applied the patch queue from scratch with no >> problems. >> > Perhaps it is a regression in the behavior of hg? I am using 0.9.3, and > cannot get the patch queue to apply: ... > [EMAIL PROTECTED] xen-3.1.1.hg]$ hg qpush -a ... > applying 15078-6145e5508d6b > abort: decoding near 'Ingard Mev�g bytes in position 186-188: invalid data! > transaction abort! > rollback completed Looks like the patch header is latin-1 (or thereabouts) and your LANG is utf-8. "LANG=latin-1 hg qpush" is likely to fix it, and "HGENCODINGMODE=replace hg push -a" will silently replace any undecodable characters with ?. Since this only applies to the patch header it's probably fine for your purposes. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Keir The fix discussed in the Xen-Devel thread "PCI Passthru: fn0 exported but not fn1" is not in the pq. Please include the same. http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00549.html http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00595.html http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00674.html Regards, Jambunathan K. Keir Fraser wrote: > Hi, > > A provisional patchqueue for Xen 3.1.1 is available at > http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with > http://xenbits.xensource.com/xen-3.1-testing.hg. > > Please kick this pq around and check whether the patches you want to see in > 3.1.1 are included. > > -- Keir > > > > ___ > Xen-devel mailing list > [EMAIL PROTECTED] > http://lists.xensource.com/xen-devel > ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Keir Fraser wrote:
On 10/9/07 13:03, "Ben Guthro" <[EMAIL PROTECTED]> wrote:
15185-1f8fb764f843
http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843
I'm inclined not to backport this one.
Attached is the exported changeset, series file, and updated patch
15473, should you change your mind.
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 300d1effb792700ad231a9627443be4158b832a8
# Parent d6078c9423555d7ada248594114ff041893bade6
Use short name format when reference to vcpu vmx union member.
Signed-off-by: Xin Li <[EMAIL PROTECTED]>
xen-unstable changeset: 15473:300d1effb792700ad231a9627443be4158b832a8
xen-unstable date: Fri Jul 06 14:36:34 2007 +0100
diff -r 3df9bf768ba3 xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c Mon Sep 10 09:13:38 2007 -0400
+++ b/xen/arch/x86/hvm/vmx/intr.c Mon Sep 10 09:13:38 2007 -0400
@@ -73,7 +73,7 @@
static void enable_irq_window(struct vcpu *v)
{
-u32 *cpu_exec_control = &v->arch.hvm_vcpu.u.vmx.exec_control;
+u32 *cpu_exec_control = &v->arch.hvm_vmx.exec_control;
if ( !(*cpu_exec_control & CPU_BASED_VIRTUAL_INTR_PENDING) )
{
diff -r 3df9bf768ba3 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c Mon Sep 10 09:13:38 2007 -0400
+++ b/xen/arch/x86/hvm/vmx/vmcs.c Mon Sep 10 09:15:23 2007 -0400
@@ -316,7 +316,7 @@ static void construct_vmcs(struct vcpu *
__vmwrite(VM_EXIT_CONTROLS, vmx_vmexit_control);
__vmwrite(VM_ENTRY_CONTROLS, vmx_vmentry_control);
__vmwrite(CPU_BASED_VM_EXEC_CONTROL, vmx_cpu_based_exec_control);
-v->arch.hvm_vcpu.u.vmx.exec_control = vmx_cpu_based_exec_control;
+v->arch.hvm_vmx.exec_control = vmx_cpu_based_exec_control;
if ( vmx_cpu_based_exec_control & ACTIVATE_SECONDARY_CONTROLS )
__vmwrite(SECONDARY_VM_EXEC_CONTROL, vmx_secondary_exec_control);
diff -r 3df9bf768ba3 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.cMon Sep 10 09:13:38 2007 -0400
+++ b/xen/arch/x86/hvm/vmx/vmx.cMon Sep 10 09:13:38 2007 -0400
@@ -417,8 +417,8 @@ static inline void vmx_save_dr(struct vc
/* Clear the DR dirty flag and re-enable intercepts for DR accesses. */
v->arch.hvm_vcpu.flag_dr_dirty = 0;
-v->arch.hvm_vcpu.u.vmx.exec_control |= CPU_BASED_MOV_DR_EXITING;
-__vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vcpu.u.vmx.exec_control);
+v->arch.hvm_vmx.exec_control |= CPU_BASED_MOV_DR_EXITING;
+__vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
savedebug(&v->arch.guest_context, 0);
savedebug(&v->arch.guest_context, 1);
@@ -1410,9 +1410,9 @@ static void vmx_dr_access(unsigned long
__restore_debug_registers(v);
/* Allow guest direct access to DR registers */
-v->arch.hvm_vcpu.u.vmx.exec_control &= ~CPU_BASED_MOV_DR_EXITING;
+v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MOV_DR_EXITING;
__vmwrite(CPU_BASED_VM_EXEC_CONTROL,
- v->arch.hvm_vcpu.u.vmx.exec_control);
+ v->arch.hvm_vmx.exec_control);
}
/*
@@ -2967,15 +2967,15 @@ asmlinkage void vmx_vmexit_handler(struc
break;
case EXIT_REASON_PENDING_VIRT_INTR:
/* Disable the interrupt window. */
-v->arch.hvm_vcpu.u.vmx.exec_control &= ~CPU_BASED_VIRTUAL_INTR_PENDING;
+v->arch.hvm_vmx.exec_control &= ~CPU_BASED_VIRTUAL_INTR_PENDING;
__vmwrite(CPU_BASED_VM_EXEC_CONTROL,
- v->arch.hvm_vcpu.u.vmx.exec_control);
+ v->arch.hvm_vmx.exec_control);
break;
case EXIT_REASON_PENDING_VIRT_NMI:
/* Disable the NMI window. */
-v->arch.hvm_vcpu.u.vmx.exec_control &= ~CPU_BASED_VIRTUAL_NMI_PENDING;
+v->arch.hvm_vmx.exec_control &= ~CPU_BASED_VIRTUAL_NMI_PENDING;
__vmwrite(CPU_BASED_VM_EXEC_CONTROL,
- v->arch.hvm_vcpu.u.vmx.exec_control);
+ v->arch.hvm_vmx.exec_control);
break;
case EXIT_REASON_TASK_SWITCH:
goto exit_and_crash;
15023-6e597e529fea
15035-23c4790512db
15038-e19ddfa781c5
15039-60240a72e2b2
15043-759d924af6d8
15044-03a13457d993
15045-5f6da38ff828
15046-e527b4ff1948
15048-e33cce8fa400
15049-174995130550
15051-384a29655270
15052-65ce4866d20b
15053-3ecf51689671
15056-a605044ecb33
15057-75b4c7cb007d
15058-3581a77791e3
15061-05ea0d79a92f
15062-b2adb797900a
15063-807f374e720d
15064-eb027b704dc5
15065-f4390e34ad12
15066-9e9c09c75110
15067-c027880b50b4
15068-dc4324d3fbb0
15069-cb006eecd6f5
15070-fbce94a9feaa
15072-d4a0706d6747
15073-e1f43038f1d8
15074-5c7a1e3abd54
15075-5efb46bfbcac
15076-9ec165fa8128
15077-711bfe07999b
15078-6145e5508d6b
15079-11a97dca57aa
15080-089696e0c603
15082-0fd2bf14f38a
15083-b9da101ed945
15128-f6928d636999
15130-a40967e39652
15132-17f6163ae930
15133-46095d5a59a9
15134-96915ca8d5f2
15135-e49b110cbb4a
15136-cc60c18247f1
15137-297d98f057e8
15138-471478a1b89e
15139-020530a6ff5c
15141-12a12637af46
15142-acee9e2c6f8b
15143-2623444e6d33
15144-f38f7f583f33
15147-3695
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Or mercurial has a dependency that behaves differently on your system. This patchqueue is only temporary until the 3.1.1 release -- I'd just modify that one patch in your private repo to exclude the troublesome character. -- Keir On 10/9/07 13:48, "Ben Guthro" <[EMAIL PROTECTED]> wrote: > > Keir Fraser wrote: >> We're using mercurial patchqueues. Mercurial version 0.9.1. I've just cloned >> and applied the patch queue from scratch with no problems. >> >> -- Keir >> > Perhaps it is a regression in the behavior of hg? I am using 0.9.3, and > cannot get the patch queue to apply: > > > [EMAIL PROTECTED] dev]$ rm -rf xen-3.1.hg/ > [EMAIL PROTECTED] dev]$ hg clone -q > http://xenbits.xensource.com/xen-3.1-testing.hg xen-3.1.1.hg > abort: destination 'xen-3.1.1.hg' already exists > [EMAIL PROTECTED] dev]$ rm -rf xen-3.1.1.hg/ > [EMAIL PROTECTED] dev]$ hg clone -q > http://xenbits.xensource.com/xen-3.1-testing.hg xen-3.1.1.hg > [EMAIL PROTECTED] dev]$ cd xen-3.1.1.hg/.hg > [EMAIL PROTECTED] .hg]$ hg clone -q > http://xenbits.xensource.com/xen-3.1-testing.pq.hg patches > [EMAIL PROTECTED] .hg]$ cd .. > [EMAIL PROTECTED] xen-3.1.1.hg]$ hg qpush -a > applying 15023-6e597e529fea > applying 15035-23c4790512db > applying 15038-e19ddfa781c5 > applying 15039-60240a72e2b2 > applying 15043-759d924af6d8 > applying 15044-03a13457d993 > applying 15045-5f6da38ff828 > applying 15046-e527b4ff1948 > applying 15048-e33cce8fa400 > applying 15049-174995130550 > applying 15051-384a29655270 > applying 15052-65ce4866d20b > applying 15053-3ecf51689671 > applying 15056-a605044ecb33 > applying 15057-75b4c7cb007d > applying 15058-3581a77791e3 > applying 15061-05ea0d79a92f > applying 15062-b2adb797900a > applying 15063-807f374e720d > applying 15064-eb027b704dc5 > applying 15065-f4390e34ad12 > applying 15066-9e9c09c75110 > applying 15067-c027880b50b4 > applying 15068-dc4324d3fbb0 > applying 15069-cb006eecd6f5 > applying 15070-fbce94a9feaa > applying 15072-d4a0706d6747 > applying 15073-e1f43038f1d8 > applying 15074-5c7a1e3abd54 > applying 15075-5efb46bfbcac > applying 15076-9ec165fa8128 > applying 15077-711bfe07999b > applying 15078-6145e5508d6b > abort: decoding near 'Ingard Mev�g bytes in position 186-188: invalid data! > transaction abort! > rollback completed > [EMAIL PROTECTED] xen-3.1.1.hg]$ hg --version > Mercurial Distributed SCM (version 0.9.3) > > Copyright (C) 2005, 2006 Matt Mackall <[EMAIL PROTECTED]> > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
On Mon, 2007-09-10 at 08:48 -0400, Ben Guthro wrote: > Keir Fraser wrote: > > We're using mercurial patchqueues. Mercurial version 0.9.1. I've just cloned > > and applied the patch queue from scratch with no problems. > > > > -- Keir > > > Perhaps it is a regression in the behavior of hg? I am using 0.9.3, and > cannot get the patch queue to apply: Perhaps something in the environment, e.g. $LANG? Ian. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Keir Fraser wrote: We're using mercurial patchqueues. Mercurial version 0.9.1. I've just cloned and applied the patch queue from scratch with no problems. -- Keir Perhaps it is a regression in the behavior of hg? I am using 0.9.3, and cannot get the patch queue to apply: [EMAIL PROTECTED] dev]$ rm -rf xen-3.1.hg/ [EMAIL PROTECTED] dev]$ hg clone -q http://xenbits.xensource.com/xen-3.1-testing.hg xen-3.1.1.hg abort: destination 'xen-3.1.1.hg' already exists [EMAIL PROTECTED] dev]$ rm -rf xen-3.1.1.hg/ [EMAIL PROTECTED] dev]$ hg clone -q http://xenbits.xensource.com/xen-3.1-testing.hg xen-3.1.1.hg [EMAIL PROTECTED] dev]$ cd xen-3.1.1.hg/.hg [EMAIL PROTECTED] .hg]$ hg clone -q http://xenbits.xensource.com/xen-3.1-testing.pq.hg patches [EMAIL PROTECTED] .hg]$ cd .. [EMAIL PROTECTED] xen-3.1.1.hg]$ hg qpush -a applying 15023-6e597e529fea applying 15035-23c4790512db applying 15038-e19ddfa781c5 applying 15039-60240a72e2b2 applying 15043-759d924af6d8 applying 15044-03a13457d993 applying 15045-5f6da38ff828 applying 15046-e527b4ff1948 applying 15048-e33cce8fa400 applying 15049-174995130550 applying 15051-384a29655270 applying 15052-65ce4866d20b applying 15053-3ecf51689671 applying 15056-a605044ecb33 applying 15057-75b4c7cb007d applying 15058-3581a77791e3 applying 15061-05ea0d79a92f applying 15062-b2adb797900a applying 15063-807f374e720d applying 15064-eb027b704dc5 applying 15065-f4390e34ad12 applying 15066-9e9c09c75110 applying 15067-c027880b50b4 applying 15068-dc4324d3fbb0 applying 15069-cb006eecd6f5 applying 15070-fbce94a9feaa applying 15072-d4a0706d6747 applying 15073-e1f43038f1d8 applying 15074-5c7a1e3abd54 applying 15075-5efb46bfbcac applying 15076-9ec165fa8128 applying 15077-711bfe07999b applying 15078-6145e5508d6b abort: decoding near 'Ingard Mev�g bytes in position 186-188: invalid data! transaction abort! rollback completed [EMAIL PROTECTED] xen-3.1.1.hg]$ hg --version Mercurial Distributed SCM (version 0.9.3) Copyright (C) 2005, 2006 Matt Mackall <[EMAIL PROTECTED]> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
We're using mercurial patchqueues. Mercurial version 0.9.1. I've just cloned and applied the patch queue from scratch with no problems. -- Keir On 10/9/07 13:28, "Ben Guthro" <[EMAIL PROTECTED]> wrote: > Also - what tool are you using to apply these patches? > > mercurial queues seem to be incompatible with some of the non utf-8 > characters in some of the patches: > > applying 15075-5efb46bfbcac > applying 15076-9ec165fa8128 > applying 15077-711bfe07999b > applying 15078-6145e5508d6b > abort: decoding near 'Ingard Mev�g bytes in position 186-188: invalid data! > transaction abort! > rollback completed > > Ben Guthro wrote: >> Keir Fraser wrote: >>> On 10/9/07 13:03, "Ben Guthro" <[EMAIL PROTECTED]> wrote: >>> 15185-1f8fb764f843 http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843 >>> I'm inclined not to backport this one. >>> >> If I recall - It applied against our 3.1 tree without any >> backporting...we just exported, and applied it. It increased >> performance on Caneland machines greatly. Test results against our 3.1 >> based product below: >> >> >> At Ben's request, I did a quick evaluation of the APIC TPR patch for >> Caneland. >> I used yesterday's build to establish a baseline for booting, running >> SPECjbb2005, and >> netperf on a SMP XP guest. I then repeated the tests with a custom >> kernel. The patch >> showed significant improvement for 2 of the 3 tests I used. Here are >> the results: >> >> Test 20070816 Patch % Improvement >> Boot time - Seconds 62.6 40.5 35% >> SPECjbb2005 OPs/Sec 35216 35686 1% >> TCP XMIT (MBits/sec) 70.2 309.5 341% >> TCP RCV (MBits/Sec) 122.3 423.5 246% >> >> These tests were done on a Caneland, with 4 quad-core sockets and 32GB >> of memory. >> The guest is Windows XP Professional with SP2, 2 CPUs, 2GB memory. >> This afternoon, >> I'll repeat the experiment on a non-Caneland machine to see if there >> are any >> side effects. >> >> >> >>> The two Linux changesets are not applicable to 3.1. >> Yes, of course...my mistake. I forgot to weed out my "unstable-only" >> patches from the list. >> >> >> ___ >> Xen-devel mailing list >> [EMAIL PROTECTED] >> http://lists.xensource.com/xen-devel > ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Also - what tool are you using to apply these patches? mercurial queues seem to be incompatible with some of the non utf-8 characters in some of the patches: applying 15075-5efb46bfbcac applying 15076-9ec165fa8128 applying 15077-711bfe07999b applying 15078-6145e5508d6b abort: decoding near 'Ingard Mev�g bytes in position 186-188: invalid data! transaction abort! rollback completed Ben Guthro wrote: Keir Fraser wrote: On 10/9/07 13:03, "Ben Guthro" <[EMAIL PROTECTED]> wrote: 15185-1f8fb764f843 http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843 I'm inclined not to backport this one. If I recall - It applied against our 3.1 tree without any backporting...we just exported, and applied it. It increased performance on Caneland machines greatly. Test results against our 3.1 based product below: At Ben's request, I did a quick evaluation of the APIC TPR patch for Caneland. I used yesterday's build to establish a baseline for booting, running SPECjbb2005, and netperf on a SMP XP guest. I then repeated the tests with a custom kernel. The patch showed significant improvement for 2 of the 3 tests I used. Here are the results: Test 20070816 Patch % Improvement Boot time - Seconds 62.6 40.5 35% SPECjbb2005 OPs/Sec 35216 35686 1% TCP XMIT (MBits/sec) 70.2 309.5 341% TCP RCV (MBits/Sec) 122.3 423.5 246% These tests were done on a Caneland, with 4 quad-core sockets and 32GB of memory. The guest is Windows XP Professional with SP2, 2 CPUs, 2GB memory. This afternoon, I'll repeat the experiment on a non-Caneland machine to see if there are any side effects. The two Linux changesets are not applicable to 3.1. Yes, of course...my mistake. I forgot to weed out my "unstable-only" patches from the list. ___ Xen-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
Keir Fraser wrote: On 10/9/07 13:03, "Ben Guthro" <[EMAIL PROTECTED]> wrote: 15185-1f8fb764f843 http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843 I'm inclined not to backport this one. If I recall - It applied against our 3.1 tree without any backporting...we just exported, and applied it. It increased performance on Caneland machines greatly. Test results against our 3.1 based product below: At Ben's request, I did a quick evaluation of the APIC TPR patch for Caneland. I used yesterday's build to establish a baseline for booting, running SPECjbb2005, and netperf on a SMP XP guest. I then repeated the tests with a custom kernel. The patch showed significant improvement for 2 of the 3 tests I used. Here are the results: Test 20070816 Patch% Improvement Boot time - Seconds62.640.5 35% SPECjbb2005 OPs/Sec 35216 35686 1% TCP XMIT (MBits/sec) 70.2 309.5341% TCP RCV (MBits/Sec) 122.3 423.5246% These tests were done on a Caneland, with 4 quad-core sockets and 32GB of memory. The guest is Windows XP Professional with SP2, 2 CPUs, 2GB memory. This afternoon, I'll repeat the experiment on a non-Caneland machine to see if there are any side effects. The two Linux changesets are not applicable to 3.1. Yes, of course...my mistake. I forgot to weed out my "unstable-only" patches from the list. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
On 10/9/07 13:03, "Ben Guthro" <[EMAIL PROTECTED]> wrote: > 15185-1f8fb764f843 > http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843 I'm inclined not to backport this one. > 15806-577313e3c0a6 (not exactly crucial, but would be nice) > http://xenbits.xensource.com/xen-unstable.hg?rev/577313e3c0a6 Yes could take this one. The two Linux changesets are not applicable to 3.1. -- Keir > linux: > 189-720571c2139e > http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/720571c2139e > > 193-9e03bcda0054 > http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/9e03bcda0054 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue
The ones I can see missing from our local patch queue are: Xen: 15185-1f8fb764f843 http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843 15806-577313e3c0a6 (not exactly crucial, but would be nice) http://xenbits.xensource.com/xen-unstable.hg?rev/577313e3c0a6 linux: 189-720571c2139e http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/720571c2139e 193-9e03bcda0054 http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/9e03bcda0054 Keir Fraser wrote: Hi, A provisional patchqueue for Xen 3.1.1 is available at http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with http://xenbits.xensource.com/xen-3.1-testing.hg. Please kick this pq around and check whether the patches you want to see in 3.1.1 are included. -- Keir ___ Xen-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
