On 25 Jul 2006, at 19:30, Hollis Blanchard wrote:
I object to these uses of (synch_)cmpxchg on a uint16_t in common code.
Many architectures, including PowerPC, do not support 2-byte atomic
operations, but this code is common to all Xen architectures.
We'll use synch_cmpxchg_subword() in the
On 27 Jul 2006, at 21:40, Hollis Blanchard wrote:
Keir, you mentioned that start_info probably doesn't make much sense
for
PowerPC. However, if for no other reason than linux/drivers/xen has
many
references to it, we'd like to fix it for now and figure out how to
replace it later.
I think t
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?
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
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 int
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 miss
On 9/8/06 4:14 pm, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
> That direction certainly seems like a good one to me.
>
> In this case, we need to load the device tree into the domain's memory
> and pass its address in a register (i.e. via xc_vcpu_setcontext).
> Currently it doesn't look li
On 14/8/06 8:37 pm, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
> Could we abstract this part more please? I think calling into an
> arch-provided xen_get_store_mfn() function would be good. (And of course
> the same for store_evtchn and the console_* equivalents.)
No, that's it from Steve's
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,
On 16/8/06 10:15 am, "Keir Fraser" <[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
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 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))
>>
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 com
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
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 mai
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 t
On 5/9/06 20:33, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
>> That's not going to be true for PowerPC and soon IA64.
>>
>> Because of Xen's use of pointers for hypercall parameters, we need the
>> kernel to translate virtual addresses to physical addresses. That means
>> any time a new hyperc
On 5/9/06 21:17, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
> A very similar problem hits us when building Linux. Without __XEN__ or
> __XEN_TOOLS__ defined, Linux gets a __XEN_INTERFACE_VERSION__ of 0, and
> so the current API will never be used (regardless of what the tools
> tried to do).
>
On 6/9/06 2:18 pm, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote:
> First off, I realize I have an SMP bug where my second processor is
> hung somewhere, I'm not sure where, but for the sake of this argument
> lets assume it has suffered an unrecoverable fault.
>
> My primary CPU is fine and is hung i
On 7/9/06 14:37, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote:
>> these assumptions are likely not true and the CPU has gone
>> down taking some locks with it.
>
> Hypervisors should increase the availability of the machine as a
> whole, PPC machines tend to have many HA features that when unhandled
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
>
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/x
On 13/9/06 10:23, "Keir Fraser" <[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 refcou
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 the
On 25/9/06 14:27, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote:
> Currently there are two failure cases:
>1) GDB had no transport available for its use (UART or otherwise)
>2) "unexpected trap", usually another trap occurs while gdb is in
> control
>
> I suppose we could have (1) -EIO and
On 25/9/06 15:09, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote:
> Here is the code that cares:
>
> #ifdef CRASH_DEBUG
> if (__trap_to_gdb(regs, cookie) == 0)
> return;
> #endif /* CRASH_DEBUG */
>
> printk("%s: type: 0x%lx\n", __func__, cookie);
> show_backtrace_regs(regs);
>
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.
>>
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 re
On 3/10/06 17:39, "Aron Griffis" <[EMAIL PROTECTED]> wrote:
> Keir Fraser wrote: [Tue Oct 03 2006, 11:59:28AM EDT]
>> Xen-unstable is currently a staging tree for xen-3.0.3-testing. Development
>> is frozen until 3.0.3-0 is released.
>
> Hi Keir,
>
>
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!)
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 fut
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
>
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
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).
>
> W
On 22/10/06 22:09, "Jimi Xenidis" <[EMAIL PROTECTED]> wrote:
> I cannot speak for Hollis (I think he may actually disagree with me)
> but see this as an opportunity to design something better, or at
> least have the debat (again).
> What might be a better alternative an to actually have an allocat
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 necess
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 mem
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 ma
On 10/11/06 10:42, "Isaku Yamahata" <[EMAIL PROTECTED]> wrote:
>> This is the best option I think. But I'm loathe to make it part of the
>> guest_handle API. We should avoid getting into this mess in the first place
>> for future hypercalls, so this will be a memory-specific function.
>>
>> We sh
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
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
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 sche
On 15/12/06 19:09, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
> Ah OK, I see now how x86 is doing that. I don't think that code flow
> really makes sense: why would you jump out of do_softirq() into assembly
> just to call do_softirq() again?
Well, that's the way it works out on x86. It is a b
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
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.
___
On 26/1/07 5:04 pm, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
>> Not sure what you mean by "our own domain builder"; we've been
>> implementing xc_linux_build() for quite a while now (and thus integrated
>> with xend).
>
> Sorry, I misunderstood. I was seeing all the libelf churn, and I misse
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
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
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 ha
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
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 carr
On 6/3/07 20:56, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
> Hi Keir, it turns out I was confused about libxc, and we were depending
> on the just-removed ELF loader. I'm fixing that now; please give me a
> heads-up on the 3.0.5 release so I'm not caught out.
You have a couple of weeks at lea
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 patc
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 a
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
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. PLEA
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 th
On 11/6/07 17:51, "Keir Fraser" <[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 bui
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
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 file
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 w
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
On 5/7/07 22:08, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
> These patches reorganize arch-generic Xen Linux code, so I'm sending them by
> mail for review. If they are acceptable, I will commit them (and the PowerPC
> code that depends on them) to the PowerPC Linux tree so you can pull from
>
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 an
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 ch
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.
-- K
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
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.
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_p
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
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
xen/Rules.mk
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
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]
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 mul
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++;
Thi
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
__
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/5
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
>>>>
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 behav
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 G
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
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 be able to probe gdbstub configuration then add a
public fun
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
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
Xen-ppc-devel@lists
84 matches
Mail list logo
