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 lines on it. (I'll sign off on Alex's changes,
On Aug 15, 2006, at 2:41 AM, Tony Breeds wrote:
On Mon, Aug 14, 2006 at 07:17:37PM -0400, Amos Waterland wrote:
Using a `powerpc64-linux-gcc (GCC) 4.1.1 ()' x86->ppc toolchain,
if I do this:
diff -r 9563f5c9ab19 xen/include/asm-powerpc/config.h
/usr/powerpc64/lib/gcc/powerpc64-linux/4.1
spent a while on a wrong track, basically
because a #endif didn't say wha tit was an endif for. (in xen/smp.h). I
did a quick grep and half the endifs in .h files have a comment that says
what #ifdef they correspond to, and the other half do not. Do we
have a style for this?_
On Wed, 2006-08-16 at 10:09 -0400, Orran Y Krieger wrote:
>
> spent a while on a wrong track, basically because a #endif didn't say
> wha tit was an endif for. (in xen/smp.h). I did a quick grep and half
> the endifs in .h files have a comment that says what #ifdef they
> correspond to, and the o
On Wed, 2006-08-16 at 11:49 +0100, Keir Fraser wrote:
> Here you go. Arch/powerpc/vga.c isn't great but I assume it's
> temporary
> until vga support is fixed properly.
>
> If you think it looks okay I'll apply it. Also Sign-off or Ack if you
> like.
Hi Keir,
In general this looks a lot bette
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 Wed, 2006-08-16 at 15:24 +0100, Keir Fraser wrote:
> Actually I'm not sure this is particularly necessary for headless x86
> either. I could move the test to the end of setup_vga(), and only probe
> 0xb8000?
Hi Keir,
Yeah, I think something like the below change to your previous patch
woul
Hi,
[xen-ppc-devel is on CC just for info]
I am porting xen-ppc's xencomm to xen/ia64.
Currently on xen/ia64 copy_from/to_guest uses guest virtual address. This
works well as long as the virtual addresses are in the TLB. When not in TLB
(or vTLB) the hypercall can't success without domain hel
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 vgabase 0
> -# define VGA_OUTW_WRITE
> -# define vga_readb(x) (*
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__)
On Wed, 2006-08-16 at 16:40 +0100, Keir Fraser wrote:
>
> 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)
On Wed, 2006-08-16 at 14:05 +1000, Tony Breeds wrote:
> --- maple_devices.tcl~ 2006-08-16 13:35:27.0 +1000
> +++ maple_devices.tcl 2006-08-16 13:35:32.0 +1000
> @@ -14,7 +14,7 @@
> set uart0_intr 0xa
>
> # UART 1
> -set uart1_enable 0
> +set uart1_enable 1
> set uart1_start
Perhaps, this is just mythology/warm-n-fuzzy for me, but I really
like having 1 PHDR.
Lemmy collect my thoughts and come up with a rational reason.
1 PHDR works just as well; the important thing is to explicitly define
your PHDRs in the linker script.
Segher
___
On Aug 16, 2006, at 10:09 AM, Orran Y Krieger wrote:
spent a while on a wrong track, basically because a #endif didn't
say wha tit was an endif for. (in xen/smp.h). I did a quick grep
and half the endifs in .h files have a comment that says what
#ifdef they correspond to, and the other
Mini-os on x86 seems to work. Someone working with us has successfully
augmented it with a stripped down version of the J9 JVM.
I have another question related to small, non-linux, os'es that can be
used as a model to build a domU for xen/ppc. I am basically redoing a
similar thing, that is
From the xen/ppc wiki:
---
For convenience, here is a list of rpms I needed for Dom0 running
SLES-10 *libgcrypt-devel*, *glibc-devel*, *python-devel*,
*ncurses-devel-5.5-18*, *zlib-devel*, *openssl-devel*, and *gcc*.
I am looking at the sles10 install dvd images. We have
libgcrypt-dev
On Aug 16, 2006, at 3:52 PM, Maria Butrico wrote:
From the xen/ppc wiki:
---
For convenience, here is a list of rpms I needed for Dom0 running
SLES-10 *libgcrypt-devel*, *glibc-devel*, *python-devel*, *ncurses-
devel-5.5-18*,
hmm any ncurses-devel should do.
*zlib-devel*, *openssl-devel*
On Wed, 2006-08-16 at 15:52 -0400, Maria Butrico wrote:
> From the xen/ppc wiki:
> ---
> For convenience, here is a list of rpms I needed for Dom0 running
> SLES-10 *libgcrypt-devel*, *glibc-devel*, *python-devel*,
> *ncurses-devel-5.5-18*, *zlib-devel*, *openssl-devel*, and *gcc*.
>
>
>
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Date 1155763645 18000
# Node ID fcf9104665f59d886733c985ced0827be32c8874
# Parent 41827ce2ccebf927df251ce3024eb10023de7d5b
[XEND] abstract architecture-specific bits in image.py
- create arch.type (which evaluates to "x86", "ia64"
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Node ID 2d465991275d5ca7f1ae8a27ad35ca41ece5cd06
# Parent 41827ce2ccebf927df251ce3024eb10023de7d5b
[XEND] abstract architecture-specific bits in image.py
- create arch.type (which evaluates to "x86", "ia64" or "powerpc")
- create s
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Node ID 279843441136b04e11d8c49249c009ef7823cc5e
# Parent f4e9ed4708a39ef9abe37cc9148867d4e4a53322
[POWERPC] add PowerPC-specific loader to xend
- create a flat device tree to pass to libxc
Signed-off-by: Hollis Blanchard <[EMAIL P
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Node ID f4e9ed4708a39ef9abe37cc9148867d4e4a53322
# Parent 2d465991275d5ca7f1ae8a27ad35ca41ece5cd06
[POWERPC] support flat device tree in libxc
- pass a flattened device tree argument from python to xc_linux_build()
- remove hardcod
I just pushed three patches to xen-ppc-unstable that enable domU loading
via xend. In particular, things like initrd loading and boot arguments
in the xm create config file work properly[1].
This will cause merge headaches down the road, because Keir wants
xc_linux_build() and related python to be
On Aug 15, 2006, at 6:39 PM, Hollis Blanchard wrote:
On Mon, 2006-08-14 at 17:20 -0400, poff wrote:
OF: Xen/PPC version 3.0-unstable ([EMAIL PROTECTED]) (gcc
version 3.4.1) Mon Aug 14 15:09:27 EDT 2006
boot_of_init args: 0x0 0x0 0x111027c 0x0 0x0
boot msr: 0x10003000
boot_of_init: _s
On Wed, Aug 16, 2006 at 11:30:48AM -0500, Hollis Blanchard wrote:
> Add to the wiki, please:
> http://wiki.xensource.com/xenwiki/XenPPC/Run/SystemSim
>
> Also please add a note about the required memory increase.
Done x2
When I workout how to get a root image under systemsim I'll document
that
On Wed, Aug 16, 2006 at 08:10:20AM -0400, Jimi Xenidis wrote:
> Thanks for getting to the bottom of this Tony.
>
> >As it's empty the linker decides to start a
> >3rd segment rather than waste disk space.
>
> Hmm, what is "empty"?
By empty I mean "filled with 0s", which I believe is because all
On Aug 16, 2006, at 10:00 PM, Tony Breeds wrote:
On Wed, Aug 16, 2006 at 08:10:20AM -0400, Jimi Xenidis wrote:
Thanks for getting to the bottom of this Tony.
As it's empty the linker decides to start a
3rd segment rather than waste disk space.
Hmm, what is "empty"?
By empty I mean "fill
On Wed, Aug 16, 2006 at 10:23:08PM -0400, Jimi Xenidis wrote:
> Not really its not like we protect any of it :) and the section
> separation still exits
> after-all we all (kernels/xen) link with -N/--omagic, which does not
> page align the data sections which has always implied a single PHDR.
29 matches
Mail list logo
