[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] [IA64] Creates tools/libxc/ia64 directory.

2006-07-28 Thread Keir Fraser
On 28 Jul 2006, at 20:17, Hollis Blanchard wrote: I'm not sure this is the best way. We'll need to do the same thing for xc_ppc_linux_build.c, but it seems a little silly to unconditionally include powerpc/Makefile as well... perhaps -include $(XEN_TARGET_ARCH)/Makefile would suffice?

[XenPPC] Re: [PATCH] [LIBXC] add architecture-specific parameter to xc_linux_build()

2006-08-09 Thread Keir Fraser
On 8/8/06 9:28 pm, Hollis Blanchard [EMAIL PROTECTED] wrote: Keir, this patch applies on top of the xc.c whitespace patch I just sent, and also on top of the contents of xenppc-unstable-merge.hg (because we've moved xc_ppc_linux_build.c into its own directory). We also have a couple

[XenPPC] Re: [Xen-devel] Re: [PATCH] [LIBXC] add architecture-specific parameter to xc_linux_build()

2006-08-09 Thread Keir Fraser
On 9/8/06 10:56 am, Keir Fraser [EMAIL PROTECTED] wrote: Keir, this patch applies on top of the xc.c whitespace patch I just sent, and also on top of the contents of xenppc-unstable-merge.hg (because we've moved xc_ppc_linux_build.c into its own directory). We also have a couple important

[XenPPC] Re: [PATCH] [LIBXC] add architecture-specific parameter to xc_linux_build()

2006-08-09 Thread Keir Fraser
On 9/8/06 4:00 pm, Hollis Blanchard [EMAIL PROTECTED] wrote: The diffstat doesn't correspond to the patch. Can I ignore the diffstat? Sorry for being unclear. The diffstat corresponds to the contents of the xenppc-unstable-merge.hg tree, which I was asking you to pull. Ah, I missed that

Re: [XenPPC] [PATCH] [POWERPC] fix vga.c compilation

2006-08-16 Thread Keir Fraser
On 16/8/06 1:30 am, Hollis Blanchard [EMAIL PROTECTED] wrote: Looks like I bungled this whitespace; could you fix when you commit please? It would probably be best to combine this patch with the ia64 patch and put both our signed-off lines on it. (I'll sign off on Alex's changes, FWIW.)

Re: [Xen-devel] Re: [XenPPC] [PATCH] [POWERPC] fix vga.c compilation

2006-08-16 Thread Keir Fraser
On 16/8/06 2:59 pm, Alex Williamson [EMAIL PROTECTED] wrote: In general this looks a lot better, but I think ia64 is still going to have trouble with the chunk below. It seems that a VGA card operating in a standard text mode doesn't necessarily respond to all of these addresses. On

[XenPPC] Re: [Xen-devel] fix vga.c compilation

2006-08-16 Thread Keir Fraser
On 16/8/06 4:35 pm, Hollis Blanchard [EMAIL PROTECTED] wrote: On Wed, 2006-08-16 at 11:49 +0100, Keir Fraser wrote: @@ -159,12 +160,8 @@ * into a single 16-bit quantity */ #define VGA_OUT16VAL(v, r) (((v) 8) | (r)) -#if defined(__i386__) || defined(__x86_64__) -# define

[XenPPC] Re: [Xen-devel] RFC: xencomm in common

2006-08-21 Thread Keir Fraser
On 21/8/06 9:03 am, Tristan Gingold [EMAIL PROTECTED] wrote: xencomm is the ppc infrastructure to do hypercalls with guest physical addresses instead of virtual address. Because ia64 should also use physicall address, I think it's better to re-use the ppc code and to put into common

[XenPPC] Re: [Xen-devel] RFC: xencomm in common

2006-08-21 Thread Keir Fraser
On 21/8/06 10:20 am, Tristan Gingold [EMAIL PROTECTED] wrote: Fine in principle. Specific comments: * powerpc should be cleaned up at the same time to use the common infrastructure. I don't want duplicated code hanging around in arch/powerpc I have attached a blindly-made patch again

[XenPPC] Re: Resend: [Xen-devel] [PATCH][TOOLS] Fix xenconsoled SEGV if domain is destroyed while connected.

2006-08-28 Thread Keir Fraser
On 27/8/06 11:01 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: Any response to this? http://lists.xensource.com/archives/html/xen-devel/2006-08/ msg01315.html It's fine. I'm just behind on applying patches. -- Keir ___ Xen-ppc-devel mailing

[XenPPC] Re: [Xen-devel] Re: [patch] fix void* arithmetic

2006-08-30 Thread Keir Fraser
On 29/8/06 10:18 pm, Hollis Blanchard [EMAIL PROTECTED] wrote: Looks like PPC is the only arch using -Wpointer-arith, is there a reason for that? Is there are reason the other architectures *aren't* using it? We have some extra warnings enabled because they've helped us in the past

[XenPPC] Re: [Xen-devel] What actually destroys a domain?

2006-09-12 Thread Keir Fraser
Xenconsoled's mapping of the console page should keep the domain alive. -- Keir On 12/9/06 2:22 am, Jimi Xenidis [EMAIL PROTECTED] wrote: Collegues say that x86 does not have this problem, however on PowerPC if you: 1) start a domain 2) attach console 3) destroy the domain The

[XenPPC] Re: [Xen-devel] What actually destroys a domain?

2006-09-13 Thread Keir Fraser
On 12/9/06 14:05, Jimi Xenidis [EMAIL PROTECTED] wrote: Xenconsoled's mapping of the console page should keep the domain alive. hmm, I'm having trouble associating the mapping and a refcount of some sort somewhere, any pointers? See share_xen_page_with_guest() in arch/x86/mm.c. The

[XenPPC] Re: [Xen-devel] [PATCH][XEN] __trap_to_gdb should return something different

2006-09-23 Thread Keir Fraser
On 22/9/06 4:07 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: --text follows this line-- This patch allows the caller to find out if the gdbstub actually did anything. Signed-off-by: Jimi Xenidis [EMAIL PROTECTED] What different actions do you envisage the caller will take? If they are

[XenPPC] Re: [Xen-devel] [PATCH 0/3][XM-TEST] Updates to xm-test ramdisk code

2006-09-29 Thread Keir Fraser
On 29/9/06 5:52 am, Hollis Blanchard [EMAIL PROTECTED] wrote: 1: Instead of using a dated snapshot (which no longer exists) use buildroot-snapshot. 2: Remove hardcoded references to i386. 3: Rename configs/buildroot - configs/buildroot-i386 and update Makefiles. With patches

Re: [XenPPC] Re: [Xen-devel] [PATCH 0/6][TOOLS][XM-TEST] [v2] Update xm-test to support new architectures

2006-10-03 Thread Keir Fraser
On 3/10/06 16:53, Hollis Blanchard [EMAIL PROTECTED] wrote: I've got no particular problem with these patches (we'll host the buildroot tar on xenbits, which was the only query). The tree's feature-frozen now though -- we're at RC2 -- so these will drop in immediately after the release.

[XenPPC] Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

2006-10-19 Thread Keir Fraser
On 18/10/06 10:57 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: It looks like IA64 has introduced a start_pfn for xc_get_pfn_list(). The PPC port requires this as well since it allows us to fill in the page_array a little bit at a time. I can either replicate the IA64 ifdef logic (yuk!) or we

[XenPPC] Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

2006-10-19 Thread Keir Fraser
On 19/10/06 14:12, Jimi Xenidis [EMAIL PROTECTED] wrote: use the start_pfn member of struct xen_domctl_getmemlist Fix all callers and change xen to pay attention to it, I think I have the x86-xen patch. Sure. Actually this interface is going away for x86, but not in the immediate future.

[XenPPC] Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

2006-10-19 Thread Keir Fraser
On 19/10/06 14:54, Jimi Xenidis [EMAIL PROTECTED] wrote: use the start_pfn member of struct xen_domctl_getmemlist Fix all callers and change xen to pay attention to it, I think I have the x86-xen patch. Sure. Actually this interface is going away for x86, but not in the immediate

[XenPPC] Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

2006-10-20 Thread Keir Fraser
On 20/10/06 13:29, Gerd Hoffmann [EMAIL PROTECTED] wrote: I'm not after the xc_get_pfn_list hypercall, but the (appearently?) other hypercall Keir mentioned ... Could be xc_domain_memory_increase_reservation() or xc_domain_memory_populate_physmap() ... Oh, it's called from xend python

[XenPPC] Re: [Xen-devel] [TOOLS][RFC] xc_get_pfn_list() and getmemlist.start_pfn

2006-10-20 Thread Keir Fraser
On 20/10/06 09:01, Gerd Hoffmann [EMAIL PROTECTED] wrote: domain builder. I could leave the interface just for that I suppose, but equally we could fill in the initial P2M table when we allocate the domain's initial memory reservation (since that hypercall returns the PFNs). Who does

[XenPPC] Re: [Xen-devel] RFC: PowerPC and VIO

2006-10-31 Thread Keir Fraser
On 30/10/06 8:51 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: Immediate questions do come to mind: Why do we return the MFN on a GNTTABOP_map_grant_ref? It's the *dev* *bus* *addr*. The one you program into your device's DMA engine. We can't hide that. Yes, in future it will not necessarily

[XenPPC] Re: [Xen-devel] [PATCH] xencomm, xenmem and hypercall continuation

2006-11-10 Thread Keir Fraser
On 10/11/06 5:49 am, Isaku Yamahata [EMAIL PROTECTED] wrote: fix xenmem hypercall for non-trivial xencomm arch(i.e. ia64, and powerpc) On ia64 and powerpc, guest_handle_add_offset() effect persists over hypercall continuation because its consumed offset is recorced in guest domains memory

[XenPPC] Re: [Xen-devel] [PATCH] xencomm, xenmem and hypercall continuation

2006-11-10 Thread Keir Fraser
On 10/11/06 08:45, Isaku Yamahata [EMAIL PROTECTED] wrote: - introduce guest_handle_add_offset_after_continuatiton() and replace guest_handle_add_offset() in memory.c with it. leave do_multicall() and guest_console_write() as is. This is the best option I think. But I'm loathe to make it

[XenPPC] Re: Question about: [LINUX] Various fixes for mmapping I/O and foreign memory pages.

2006-11-13 Thread Keir Fraser
On 13/11/06 8:50 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: auto-translate guests can use remap_pfn_range() rather than direct_remap_pfn_range(). This change was specifically made so that mmap of /dev/mem would work (i.e., mapping of I/O memory) on mini-xen (dom0 guest running on minimal

[XenPPC] Re: [Xen-devel] [PATCH][XEN][POWERPC] allocate shadow memory for PPC Linux domains

2006-12-09 Thread Keir Fraser
On 8/12/06 8:25 pm, Hollis Blanchard [EMAIL PROTECTED] wrote: Allocate shadow memory for PPC Linux domains. Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] Just check all these patches into the PPC tree and I¹ll merge them into unstable with the rest. I always check the diff when I merge

[XenPPC] Re: [Xen-devel] schedule() vs softirqs

2006-12-15 Thread Keir Fraser
On 15/12/06 17:27, Hollis Blanchard [EMAIL PROTECTED] wrote: We recently uncovered a bug on PowerPC where if a timer tick arrives just inside schedule() while interrupts are still enabled, the decrementer is never reprogrammed to that appropriate value. This is because once inside schedule(),

[XenPPC] Re: [Xen-devel] schedule() vs softirqs

2006-12-15 Thread Keir Fraser
On 15/12/06 20:41, Hollis Blanchard [EMAIL PROTECTED] wrote: It's an issue with any architecture with a large number of registers which aren't automatically saved by hardware (and a C ABI that makes some of them non-volatile). x86 has a small number of registers. ia64 automatically saves

[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] [HVM] save restore: new hyper-call

2007-01-19 Thread Keir Fraser
On 19/1/07 17:50, Hollis Blanchard [EMAIL PROTECTED] wrote: This patch breaks PowerPC, which does not supply arch_(get| set)hvm_ctxt(). In fact, I don't see where IA64 supplies these either. Please revert and refactor into arch_do_domctl(), thanks. Now done. K.

[XenPPC] Re: [Xen-devel] /dev/mem and xlate_dev_mem_ptr*()

2007-01-27 Thread Keir Fraser
On 27/1/07 12:49 pm, Jimi Xenidis [EMAIL PROTECTED] wrote: in the 2.6.18 linux of the sparse tree you have: drivers/xen/char/mem.c using xlate_dev_mem_ptr as 2 args. What is the story with this? has the interface changed from under you? Why not invent a new interface that does not

[XenPPC] Re: [Xen-devel] please pull xenppc-unstable-merge.hg

2007-02-14 Thread Keir Fraser
On 14/2/07 16:44, Hollis Blanchard [EMAIL PROTECTED] wrote: On Fri, 2007-02-09 at 14:58 -0600, Hollis Blanchard wrote: Hi Keir, please pull from http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg Among the PPC updates are the two libelf patches I sent separately. Hi Keir, any

Re: [XenPPC] Re: [Xen-devel] [PATCH] [GNTTAB] expandable grant table

2007-02-26 Thread Keir Fraser
On 26/2/07 23:31, Hollis Blanchard [EMAIL PROTECTED] wrote: Hi Yamahata-san, thanks very much for your patch! I'm confused about one thing though: why do we need to take a lock to read d-grant_table-nr_grant_frames? It's a simple integer, so no lock is required or useful. I haven't got

Re: [XenPPC] Re: [Xen-devel] [PATCH] [GNTTAB] expandable grant table

2007-02-26 Thread Keir Fraser
On 27/2/07 00:05, Hollis Blanchard [EMAIL PROTECTED] wrote: I don't believe that's a concern, since updating grant_table-nr_grant_frames is the very last step in gnttab_grow_table(), and it will only grow. If there's a memory barrier before the update of nr_grant_frames, explicitly or

[XenPPC] Re: [Xen-devel] please pull xenppc-unstable-merge.hg

2007-03-06 Thread Keir Fraser
The xenppc-unstable is already merged and fixed. -- Keir On 5/3/07 19:24, Hollis Blanchard [EMAIL PROTECTED] wrote: There are two patches that touch common code: * Add a guest_physmap hook for max_mem changes. We've finally gotten around to removing a hack we've carried in

[XenPPC] Re: Periodic VIRQ_TIMER required?

2007-03-10 Thread Keir Fraser
On 9/3/07 21:16, Hollis Blanchard [EMAIL PROTECTED] wrote: So in conclusion, I think we'll need the legacy behavior, though it might be interesting for us in the future to modify Linux to use hcalls to create timer events. Okay. That¹s where Jeremy is going with the paravirt_ops patches

[XenPPC] Re: please pull xenppc-unstable-merge.hg

2007-03-21 Thread Keir Fraser
On 21/3/07 23:48, Hollis Blanchard [EMAIL PROTECTED] wrote: Hi Keir, please pull from http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg Done. It looks like that will bring in about 775 changesets without changing any code, but that's the amount of work you would have gotten all

[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] xen: Split domain_flags into discrete first-class fields in the

2007-04-05 Thread Keir Fraser
On 5/4/07 16:44, Hollis Blanchard [EMAIL PROTECTED] wrote: This is an interface problem: using the interface in a way that works on x86 fails on other architectures. PLEASE let's redefine the interface to prevent this from happening. In this case, that means replacing the xchg() macro with

[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] xen: Split domain_flags into discrete first-class fields in the

2007-04-05 Thread Keir Fraser
On 5/4/07 16:56, Keir Fraser [EMAIL PROTECTED] wrote: On 5/4/07 16:44, Hollis Blanchard [EMAIL PROTECTED] wrote: This is an interface problem: using the interface in a way that works on x86 fails on other architectures. PLEASE let's redefine the interface to prevent this from happening

[XenPPC] Re: [Xen-devel] dom0 auto-translate mmap()

2007-06-11 Thread Keir Fraser
On 11/6/07 17:42, Hollis Blanchard [EMAIL PROTECTED] wrote: The net is that I would like to remove the above test. I wonder why it was added in the first place? Somebody has a privileged autotranslate domain and mistakenly tried to run the domain building tools? Interesting. How does this

[XenPPC] Re: [Xen-devel] [PATCH 3 of 6] [XEN][LINUX] Add architecture-generic xencomm infrastructure

2007-07-05 Thread Keir Fraser
On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote: diff -r 001c42f8079e -r e2681868041e drivers/xen/Kconfig --- a/drivers/xen/Kconfig Thu Jul 05 16:01:18 2007 -0500 +++ b/drivers/xen/Kconfig Thu Jul 05 16:01:18 2007 -0500 @@ -278,4 +278,7 @@ config XEN_BALLOON bool default y

[XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctl conversion for 64-bit kernels

2007-07-05 Thread Keir Fraser
CONFIG_COMPAT stuff doesn't belong in include/xen/public/privcmd.h. That header is shared with userspace so it should stay clean. Make a new one in include/xen, or in drivers/xen/privcmd, whichever makes most sense. -- Keir On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote: 5 files

Re: [XenPPC] Re: [Xen-devel] [PATCH 3 of 6] [XEN][LINUX] Add architecture-generic xencomm infrastructure

2007-07-05 Thread Keir Fraser
On 5/7/07 22:35, Hollis Blanchard [EMAIL PROTECTED] wrote: +config XEN_XENCOMM + bool + Shouldn't this have a 'depends on', and 'default y'? This will be selected by architectures that need it. If that means it is automatically be handled by the build system and won't appear in 'make

[XenPPC] Re: [Xen-devel] [PATCH 4 of 6] [XEN][LINUX] #ifdef x86-specific alloc_vm_area()

2007-07-05 Thread Keir Fraser
On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote: [XEN][LINUX] #ifdef x86-specific alloc_vm_area(). Since neither IA64 nor PowerPC wants this code, in the future it should really be moved out of drivers/xen/ Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] The IA64 version will get

[XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctlconversion for 64-bit kernels

2007-07-06 Thread Keir Fraser
On 6/7/07 09:09, Jan Beulich [EMAIL PROTECTED] wrote: --- a/fs/compat_ioctl.c Thu Jul 05 17:25:47 2007 -0500 +++ b/fs/compat_ioctl.c Thu Jul 05 17:26:48 2007 -0500 @@ -2948,6 +2953,18 @@ COMPATIBLE_IOCTL(LPRESET) /*LPGETSTATS not implemented, but no kernels seem to compile it in anyways*/

[XenPPC] Re: [Xen-devel] [PATCH 5 of 6] [XEN][LINUX] Refactor grant table allocation into arch-specific code

2007-07-06 Thread Keir Fraser
Patches 1 thru 4 are applied. This one (patch 5) breaks the x86 build and even if that is fixed breaks the semantics of gnttab_map() (apply_to_page_range() is invoked on every call, not just when shared==NULL). -- Keir On 5/7/07 23:27, Hollis Blanchard [EMAIL PROTECTED] wrote: 3 files

Re: [Xen-devel] Re: [XenPPC] [PATCH][POWERPC] Fix missing '{' for mm.c in xen-unstable

2007-07-06 Thread Keir Fraser
On 6/7/07 16:33, Hollis Blanchard [EMAIL PROTECTED] wrote: Doh, thanks. I have had this locally, but apparently forgot to push it... I will apply to the PPC tree, along with a few other changes, and push upstream later. Ah, I just threw it into the xen-unstable main tree. -- Keir

[XenPPC] Re: [Xen-devel] please pull PowerPC trees

2007-07-07 Thread Keir Fraser
Changes inside powerpc files are fine. Obviously powerpc-specific changes inside common files are usually fine. Changes to locking protocols in common files (e.g., changed usage of mmap_sem in privcmd.c) is *not* fine. Please post patches for that kind of thing. -- Keir On 6/7/07 22:29, Hollis

Re: [XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctlconversion for 64-b

2007-07-09 Thread Keir Fraser
On 9/7/07 10:03, Jan Beulich [EMAIL PROTECTED] wrote: We've already fixed all the shared structures (e.g. sysctl) to use explicitly-sized types, so the PowerPC port has always had proper interfaces. For example, look at the definition of xen_ulong_t on the different architectures. The x86

[XenPPC] Re: [Xen-devel] [PATCH] Take a writer lock for mmap_sem.

2007-07-09 Thread Keir Fraser
On 9/7/07 16:45, Hollis Blanchard [EMAIL PROTECTED] wrote: My mistake, I meant to send this separately. In 2.6.17, we did our own locking inside direct_remap_pfn_range(). In the current Linux tree though, the locking is done in privcmd_ioctl(). However, since direct_remap_pfn_range()

[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add #ifdef ARCH_HAS_DEV_MEM to archtecture specific file_operations.

2007-07-09 Thread Keir Fraser
On 9/7/07 20:20, Hollis Blanchard [EMAIL PROTECTED] wrote: By the way, I wonder how PPC manages to build both drivers/char/mem.c and drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be that mem_fops defined by the Xen file is picked up by the generic file. If

[XenPPC] Re: [Xen-devel] todays xen-unstable is throwing gcc errors when compiling on PPC

2007-07-09 Thread Keir Fraser
This problem is caused by my patch which moved the addition of -fno-strict-aliasing to CFLAGS into Config.mk. At the same time I *removed* -fno-strict-aliasing from arch/{x86,powerpc,ia64}/Rules.mk. My assumption was that everyone would simply add to the CFLAGS created by Config.mk and

[XenPPC] Re: [Xen-devel] [PATCH 0/4] xencomm take 2: preparation for consolidation and various fixes

2007-08-13 Thread Keir Fraser
I'll apply these if Alex and Hollis will ack them. -- Keir On 13/8/07 04:59, Isaku Yamahata [EMAIL PROTECTED] wrote: This updated patch series is for xencomm consolidation and various fixes based on Hollis's comment. Changes from take 1: xen side varisous fixes and preparation for

[XenPPC] Re: [Xen-devel] [PATCH 0/4] xencomm take 2: preparation for consolidation and various fixes

2007-08-13 Thread Keir Fraser
On 13/8/07 13:44, Alex Williamson [EMAIL PROTECTED] wrote: On Mon, 2007-08-13 at 10:10 +0100, Keir Fraser wrote: I'll apply these if Alex and Hollis will ack them. They look OK to me. Acked-by: Alex Williamson [EMAIL PROTECTED] Okay, just needs someone from the PPC side to comment

[XenPPC] Re: [Xen-devel] [PATCH 0/7] xencomm take 3: preparation for consolidation and various fixes

2007-08-14 Thread Keir Fraser
On 14/8/07 10:50, Isaku Yamahata [EMAIL PROTECTED] wrote: This take 3 patch series is for xencomm consolidation and various fixes. I split up the xen side patch into 4 smaller ones and cleaned them up. Linux side patch is same as previous one. The issue is the complexity and the multi page

[XenPPC] Re: [Xen-devel] [PATCH 2/3] xencomm take 4: xen side multiple page support

2007-08-28 Thread Keir Fraser
On 28/8/07 07:17, Isaku Yamahata [EMAIL PROTECTED] wrote: +static int +xencomm_ctxt_next(struct xencomm_ctxt *ctxt, int i) +{ +BUG_ON(i = ctxt-nr_addrs); +/* in i == 0 case, we already calculated in xecomm_addr_init() */ +if ( i != 0 ) +ctxt-address++; This function

[XenPPC] Xen 3.1.1 -- initial patchqueue

2007-09-10 Thread Keir Fraser
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

[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

2007-09-10 Thread Keir Fraser
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)

[XenPPC] Re: [Xen-devel] Xen 3.1.1 -- initial patchqueue

2007-09-11 Thread Keir Fraser
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

[XenPPC] Re: [Xen-devel] [PATCH] nr_cpus calculation problem due to incorrect sockets_per_node

2007-10-29 Thread Keir Fraser
No changes are allowed to the tools interfaces within a stable release series. It'll be in 3.2.0 in a few weeks time. -- Keir On 29/10/07 15:37, beth kon [EMAIL PROTECTED] wrote: Hi. Wondering if this patch has been reviewed and could be considered for inclusion in 3.2. Sorry about the late

[XenPPC] Re: [Xen-devel] [Patch] [RFC] avoid debugger_trap when we don't expect

2008-01-30 Thread Keir Fraser
On 30/1/08 08:48, Akio Takebe [EMAIL PROTECTED] wrote: This doesn't need to be fixed on x86 -- the int3 handler will return silently if the debugger is not configured. It would be nice if the ia64 handler would do the same. If that is not possible then change only ia64 code and if you need to

[XenPPC] Third release candidate for 3.1.3

2008-01-30 Thread Keir Fraser
A new releaase candidate is tagged in http://xenbits.xensource.com/xen-3.1-testing.hg. Assuming no problems are revealed by testing, I'd like to make this the proper 3.1.3 release asap. Thanks, Keir ___ Xen-ppc-devel mailing list