On Dec 3, 2007, at 2:36 PM, James Markakis wrote:
Has anyone gotten XEN running on either of these systems?
IBM IntelliStation POWER 185 Express
http://www-03.ibm.com/systems/intellistation/power/hardware/185/
index.html
Sorry, this already runs a "hypervisor" in the sock firmware, so you
Sorry Christian,
A lot of us have been at a conference this week.
Anyway... All our bits are in the the proper Xen development
repositories
The build instructions are the same, but you get the bits from there.
-JX
On Sep 26, 2007, at 2:07 AM, Christian Kaiser2 wrote:
Hi,
I found out that "h
On Aug 9, 2007, at 9:56 PM, Jun Hui Bu wrote:
Hello,
According to the instructions in Xen wiki, Xen could not set up
DOM0 guest OS(SLES10 SP1) when try it on JS20. Would you please
help take a look it? Thanks a lot!
I think it is you yaboot.conf
(XEN) Dom0 has maximum 2 VCPUs
(XEN) elf
On Jul 10, 2007, at 9:22 AM, Christian Ehrhardt wrote:
Jimi Xenidis wrote:
Now Executed in a xenppc DomU
./hellobit.32
Hello World!
./hellobit.64
-bash: ./hellobit.64: No such file or directory
hmm.. this works just fine for me and should have nothing to do
with Xen at all, unless your
On Jul 9, 2007, at 4:23 PM, Jimi Xenidis wrote:
On Jul 9, 2007, at 3:41 PM, Hollis Blanchard wrote:
On Mon, 2007-07-09 at 20:26 +0100, Keir Fraser wrote:
On 9/7/07 20:20, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
By the way, I wonder how PPC manages to build both driv
On Jul 9, 2007, at 3:41 PM, Hollis Blanchard wrote:
On Mon, 2007-07-09 at 20:26 +0100, Keir Fraser wrote:
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?
On Jul 9, 2007, at 7:47 AM, Christian Ehrhardt wrote:
Example:
#include
main()
{
printf ("Hello World!\n");
}
Compiled (on Dom0):
gcc -m32 hellobit.c -o hellobit.32
gcc -m64 hellobit.c -o hellobit.64
Now Executed in a xenppc DomU
./hellobit.32
Hello World!
./hellobit.64
-bash: ./hellobit.6
On Jun 18, 2007, at 3:26 PM, Jimmy Markakis wrote:
Where may one obtain the latest copy of XEN for PPC?
see:
http://wiki.xensource.com/xenwiki/XenPPC
Also, will XEN
support x86 virtualization (emulation or something similar) on POWER
architecture?
There are no plans for this at all.
-JX
On Jun 18, 2007, at 3:19 PM, James Bulpin wrote:
We're using our own "patchbot" script which pre-dates hg notification
support. I'd be keen to change to the latter for these trees. Any
objections?
Oh that would be awesome!
-JX
___
Xen-ppc-devel ma
Ian,
Any chance you can wire up the email notifications again?
-JX
On Jun 4, 2007, at 5:38 PM, Ian Campbell wrote:
On Mon, 2007-06-04 at 14:15 -0500, Hollis Blanchard wrote:
This way we'll end up with common names like:
/xen-unstable.hg
/linux-2.6.18-xen.hg
/staging/xen-unstable.hg
/staging/l
BTW: there was a quick discussion on this before:
http://lists.xensource.com/archives/html/xen-devel/2006-11/
msg00672.html
IIRC, We we continued "faking it out" until we got the ability to
mmap'ing arbitrary pages.
Now that we fixed the ability to properly address "remote" memory,
this s
On Jun 4, 2007, at 10:09 PM, 조승모 wrote:
I'd like to see the performance data of XenPPC, i.e. overhead due
to xen.
It seems that the original Xen-x86 has overhead about 5%. Is it
also true for XenPPC?
Unfortunately, but we have none. We have mostly been focusing on
functionality.
-JX
Yes, I agree, it is strange and could be coded either way.
I doubt there was any real intent here, is is simply how we coded it.
The 970 (our only port) has issues with external interrupt latencies
already, I doubt this code really effects performance.
At the moment we "share" control if the P
On May 17, 2007, at 10:33 AM, Hollis Blanchard wrote:
It looks like blktap is a loadable kernel module, and you don't
have it
loaded?
On Wed, 2007-05-16 at 13:43 +0200, Christian Ehrhardt wrote:
So, the question is - why is there no /sys/class/[xen|
misc]/blktap0/dev ?
Actually.. we neve
On Apr 12, 2007, at 9:51 AM, Fang Zhe wrote:
Hi, all
I'm wondering if XenPPC can work on Cell BE(As it includes a 970
compatiable Core),
Yes, it could work on Cell with not a whole lot of effort.
Some register remappings, IIC and IOMMU work and you'd get just about
everything else for free
On Apr 4, 2007, at 10:43 PM, Jerone Young wrote:
On Wed, 2007-04-04 at 08:57 -0400, Jimi Xenidis wrote:
hmm, how did this ever work?!
I your problem with a direct caller of __xchg() or is this thru the
macro xchg()?
The caller is in common/domain.c @ line 310:
/* Already dying? Then bail
There was an agreement not to allow packed in common code.
Could you sent this issue upstream and CC the author of the patch
that introduced these?
They should know better :)
-JX
On Apr 4, 2007, at 2:04 AM, Jerone Young wrote:
So use of "packed" attribute is bad for PPC. PPC Xen build check
hmm, how did this ever work?!
I your problem with a direct caller of __xchg() or is this thru the
macro xchg()?
I notice we have the macro wrong (at least in my copy of xen source):
#define xchg(ptr,v) ((__typeof__(*(ptr)))__xchg((unsigned long)(v),
(ptr),sizeof(*(ptr
where it should
On Apr 4, 2007, at 2:22 AM, Jerone Young wrote:
So now that __xchg has started to be used we have a problem building
xen-syms as the function __xchg_called_with_bad_pointer used in
"include/asm-powerpc/system.h" does not exist (see line 73).
I get a linker error but it's for an udefined refere
On Apr 1, 2007, at 2:38 PM, Andreas Barth wrote:
Hi,
I'm interessted in finding out whether Xen runs on my powerpc.
We only support PowerPC 970 CPUs.
Sadly, I
didn't find a page that tells me what the current state of the powerpc
support is, and which hardware is supported (or does that me
On Mar 28, 2007, at 2:39 PM, Christian Ehrhardt wrote:
Hi,
I'm curently implementing H_PERFMON and found some code in the file
arch/powerpc/of_handler/papr.S which is not clear for me by just
reading it ;)
This is code for the OF stub that we but in Dom0 address space, it
usually only n
On Mar 27, 2007, at 6:57 AM, Christian Ehrhardt wrote:
How does the inclusion of the code in the subdir platform/xen work
in xenppc-linux - Does it replace the bare metal code in platform/
pseries or does it "extend" it in any way?
Please go with option (b). Until we actually merge with up
On Mar 26, 2007, at 8:26 AM, Christian Ehrhardt wrote:
Jimi Xenidis wrote:
On Mar 23, 2007, at 9:07 AM, Hollis Blanchard wrote:
Right, that won't fit in EXCEPTION_HEAD (you will get the assembler
error messages Jimi pasted above).
Yeah,
So EXCEPTION_HEAD branches to a passed in
On Mar 23, 2007, at 8:57 AM, Hollis Blanchard wrote:
On Fri, 2007-03-23 at 09:38 +0100, Christian Ehrhardt wrote:
Jimi is suggesting that you implement the PAPR version of the
performance monitor hypercall, a.k.a. H_PERFMON. The specification he
pasted in email was from the PAPR.
Hopefully I
On Mar 23, 2007, at 9:07 AM, Hollis Blanchard wrote:
On Fri, 2007-03-23 at 08:52 +0100, Christian Ehrhardt wrote:
Jimi Xenidis wrote:
...
Ensure MMCR0[FCH] for this first step:
-(ensure) set MMCR[FCH] always in xen when entering xen space. This
should prevent a domain
messing up MMCR0[FCH
some comments
On Mar 20, 2007, at 2:09 PM, Christian Ehrhardt wrote:
Hi,
this mail consists of two parts. Part I tries to summarize all the
performance profiling related discussions of the past few weeks in
a short item listing that is now on my todo list ;)
In Part II I want to encourage e
On Mar 19, 2007, at 10:48 AM, Christian Ehrhardt wrote:
Jimi Xenidis wrote:
...
There really very little Linux work to do here. We need:
1. An hcall that turn the performance monitor on for the domain
2. Save and restore the relevant registers for any domain that is
has it turned on.
3
On Mar 20, 2007, at 11:36 AM, Hollis Blanchard wrote:
On Mon, 2007-03-19 at 15:30 +0100, Christian Ehrhardt wrote:
Hi,
I have one more questions regarding the oprofile extension to work in
xenppc guests.
The plain linux implementation sets !always! the vector for the
performance interrupt 0xf
On Mar 14, 2007, at 6:17 AM, Christian Ehrhardt wrote:
Jimi Xenidis wrote:
Christian, nice summary.
One question I have is does Xen allow the domain to extract domain
oprofile information as linxu would without Xen, or does xen allow
for some transport that eases the collection?
Short
selves via ppc_md.show_cpuinfo(). We
can get
that from the device tree, just like CHRP does.
On Tue, 2007-02-27 at 16:55 -0500, Jimi Xenidis wrote:
I agree, but in our current Kernel source the string in question
comes from the machine description.
Am I missing something?
-Jx
On Feb 27, 2007
chine is more specific). I think platform = Xen is
fine, and machine is the underlying machine.
On Tue, 2007-02-27 at 14:56 -0500, Jimi Xenidis wrote:
This comes from the fact that we are running xen from an underlying
host platform.
for example, if you boot linux without xen but on SLOF your mach
This comes from the fact that we are running xen from an underlying
host platform.
for example, if you boot linux without xen but on SLOF your machine
name is "Maple".
see:
arch/powerpc/platforms/xen/setup.c define_machine 246
define_machine(xen)
I'd be interested in changing this to "X
On Feb 22, 2007, at 5:07 PM, Ryan Harper wrote:
* Hollis Blanchard <[EMAIL PROTECTED]> [2007-02-22 15:01]:
On Wed, 2007-02-21 at 18:17 -0500, Ryan Harper wrote:
4 files changed, 72 insertions(+)
xen/arch/powerpc/domain.c| 60 ++
xen/arch/powerpc
On Feb 21, 2007, at 6:17 PM, Ryan Harper wrote:
2 files changed, 17 insertions(+), 14 deletions(-)
xen/arch/powerpc/domain_build.c | 24
xen/arch/powerpc/setup.c|7 +--
# HG changeset patch
# User Ryan Harper <[EMAIL PROTECTED]>
# Date 1172103252 21600
On Feb 21, 2007, at 6:16 PM, Ryan Harper wrote:
2 files changed, 6 insertions(+)
xen/common/domctl.c |4
xen/include/xen/shadow.h |2 ++
NIT: I think mm.h or domain.h is a better home for the macro/proto.
-JX
___
Xen-ppc-devel mai
hmm.. are we always going to include the IO space in dom0->p2m[] or
only when dom0->maxpage > IO_Base?
-JX
On Feb 23, 2007, at 1:05 PM, Ryan Harper wrote:
* Hollis Blanchard <[EMAIL PROTECTED]> [2007-02-23 11:43]:
On Fri, 2007-02-23 at 11:12 -0600, Ryan Harper wrote:
* Hollis Blanchard <[EMA
We don't consider the RMA boundary for the Xen heap at all anymore
(not for a while)
The Xen heap is calculated based on the estimated resources we'll need.
on example is that we need to get enough HTABs for all the domain, so
1/64th of all of memory is part of the Xen heap size.
check out p
On Feb 14, 2007, at 1:30 PM, Jimi Xenidis wrote:
nice, some comments.
On Feb 14, 2007, at 11:54 AM, Hollis Blanchard wrote:
Thoughts,
on the 970 if you have more than 2GiB of memory then your
frame_table will actually contain the IO area. In order to
s/In order to
nice, some comments.
On Feb 14, 2007, at 11:54 AM, Hollis Blanchard wrote:
I was talking with Ryan yesterday, and we settled on a scheme to
resolve
some of our current memory management ugliness.
If we have a notification hook in the XEN_DOMCTL_max_mem handler, we
could size an array for each
On Feb 8, 2007, at 8:45 AM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-02-08 06:48]:
some comments
On Feb 7, 2007, at 6:34 PM, Ryan Harper wrote:
This patch cleans up xen_init_early() to construct a start_info_t
only
from the devtree as Patch1 fixes xen to no
On Feb 8, 2007, at 8:40 AM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-02-08 06:30]:
Just 2 things.
(1) I really do not want OFD code to compute anything so please pass
in the shared page address for ofd_dom0_fixup()
heh, unlike how it was calculating star
some comments
On Feb 7, 2007, at 6:34 PM, Ryan Harper wrote:
This patch cleans up xen_init_early() to construct a start_info_t only
from the devtree as Patch1 fixes xen to no longer create a
start_info_t
for dom0.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, T
Just 2 things.
(1) I really do not want OFD code to compute anything so please pass
in the shared page address for ofd_dom0_fixup()
(2) I'm pretty sure the all of the #define RMA_* can go now.
-JX
On Feb 7, 2007, at 6:34 PM, Ryan Harper wrote:
The patch removes the construction of a start_in
mostly Linux Kernel style NITS
On Feb 7, 2007, at 4:26 PM, Jerone Young wrote:
With some of the logic change from the Xencomm patch. In a few
hypercalls introduces a situation where you can potentially have
memory
leaks if something fails. This patch address these issues.
Signed-off-by: Jer
On Feb 7, 2007, at 5:41 PM, Jerone Young wrote:
On Wed, 2007-02-07 at 17:37 -0500, Jimi Xenidis wrote:
On Feb 7, 2007, at 12:48 PM, Jerone Young wrote:
OK all is well...no fire here...move along. I figured out what
happened.
I included the vmlinux as the DOM0_IMAGE and not the zImage. It
On Feb 7, 2007, at 5:38 PM, Hollis Blanchard wrote:
If the problem were that dom0 was only partially transferred, we would
see dom0 start to boot and fail. The boot_of_alloc_init message
happens
way before that point.
Thats not really true, dom0 is in .data, there are actually
additional
On Feb 7, 2007, at 12:48 PM, Jerone Young wrote:
OK all is well...no fire here...move along. I figured out what
happened.
I included the vmlinux as the DOM0_IMAGE and not the zImage. It
compiled
through .. it is a bit surprising the Xen died though and not during
loading of Dom0. So ultimat
Last time we saw this it had to do with building optimized and the
linker script simplification I attempted, so we were actually missing
bits.
before you do anything, try a clean build.
Another possibility is some corruption, you may want to debug what
the boot_of_allocator is reserving.
pushed.. thanks
On Feb 5, 2007, at 5:42 PM, Jerone Young wrote:
Yes..another Xencomm patch :-). The last one actually hit a bug
that was
currently in xen-linux with handling of domain control operation
XEN_DOMCTL_shadow_op. This fix is included in the patch. I've also
added error handling and
On Feb 2, 2007, at 7:10 PM, Jerone Young wrote:
Sorry guys. Please ignore this patch. I found a bug with it. Will
submit
a fixed version shortly.
Ok, took a peek though and it seems that not all xencomm_map*() calls
have there return values checked.
Using ENOSPC for the errno for xencomm_
Thanks Ryan.
This is dom0, and the last time I saw this was because we had the
flat-tree reservations wrong in domu.
I wonder if there is any howto's on debugging a slab corruption?
-JX
On Feb 1, 2007, at 4:18 PM, Ryan Harper wrote:
I noticed the following output from the kernel running XenP
On Feb 1, 2007, at 4:07 PM, Yoder Stuart-B08248 wrote:
I'm trying to understand the paravirtualization interface
between the OS and Xen. Here is one thing that's confusing
me--
In Linux, the xen probe() routine calls hpte_init_lpar()
which hooks up some pseries hypervisor MMU routines. These
No need to respin, since this can wait for a follow-on/dom0 work, we
can lose:
+#define RMA_LAST_DOM0 2
+/* these are not used for dom0 so they should be last */
+#define RMA_CONSOLE 3
+#define RMA_STORE 4
+#define RMA_LAST_DOMU 4
Since dom0 does not use them, and
And when dom0 goes flat we can
Hollis, please ack the name change.
On Jan 29, 2007, at 1:45 AM, Jerone Young wrote:
Here is yet another go at this. This patch I have thoroughly gone
thought.
Changes:
- move xencomm_map_early to xencomm_map_no_alloc
- added xencomm_free everywhere
- return E
Ok, xencomm is simply a data structure that describes (we'll call it
the descriptor or "desc") the physical memory that another data
structure occupies (we'll call "data").
Sometimes this "data" is self described, such that all the data
exists on a single page, or proven to be physically co
On Jan 27, 2007, at 8:13 AM, Keir Fraser wrote:
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
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 conflict, since this is
your code?
-JX
On Jan 22, 2007, at 1:58 PM, Yoder Stuart-B08248 wrote:
It is taking a heck of a long time though. The simulator
cycle count appears to have about doubled.
BTW: check your linux config. IIRC stuff like CONFIG_DEBUG_SLAB will
kill you, I'd run thru and turn off all the CONFIG_DEBUG=*
-JX
On Jan 25, 2007, at 8:06 PM, Jerone Young wrote:
This patch should address all the issues Jimi has pointed out.
yes it does... thank you.
but still has a few issues..
Throughout the patch:
1. xencomm_create_inline() could never fail, xencomm_map() can so you
need to check ALL of them.
1. _i
On Jan 25, 2007, at 3:51 PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-25 14:40]:
Since you later look for the console_mfn and store_mfn later, it
would be better in the caller and pass then in.
FYI: It is xend that decides where store and console go.
shared_inf
pushed, thanks ryan
-JX
On Jan 25, 2007, at 2:32 PM, Ryan Harper wrote:
We don't need a custom buildDomain() anymore but we do need to
provide a
shadow memory calculation.
- Create PPC_LinuxImageHandler class to implement
getRequiredShadowMemory().
- Derive prose builder from PPC_LinuxIm
On Jan 25, 2007, at 3:16 PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-25 13:57]:
Thanks _a_lot_ Ryan.. this stuff is really tedious.
Just a few more things.
BTW: what about start_info->flags = SIF_PRIVILEGED or
SIF_INITDOMAIN. You will not need properties no
PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-24 12:42]:
The data that was in start_info_t should be just simple bindings
in "/
xen" since they describe xen, there is no need to create a new node.
many of the props are not needed since they are express
since we don;t use the sparse tree, we'll need a linux patch with
this change as well.
-JX
On Jan 24, 2007, at 12:41 PM, Ryan Harper wrote:
xenppc-unstable.hg's xen.h is out-of-sync with xen-unstable.hg w.r.t
the types used in start_info_t. Now that libxc is no longer
creating a
start_inf
The data that was in start_info_t should be just simple bindings in "/
xen" since they describe xen, there is no need to create a new node.
many of the props are not needed since they are expressed elsewhere
in the devtree or perhaps differently.
more below.
On Jan 24, 2007, at 12:41 PM, Ryan
On Jan 24, 2007, at 1:08 AM, Jerone Young wrote:
With all the recommendations here is another udpate to the Xencomm
patch.
Actually, you missed some.. :)
I was unable though to successfully remove xencomm_create & replace it
with xencomm_map. It was causing issues when loading of Dom0 that
On Jan 23, 2007, at 12:22 PM, Segher Boessenkool wrote:
Again -- do you have a testcase for the failure that made
you revert this patch?
yeah, gcc -O2
just build xen with debug=n, the symptom is that string literals got
truncated.. LITERALLY!
-JX
__
since those are arch/powerpc/platforms/xen specific stick the protos
in setup.h in that directory.
That file will need some tending to later, but for now I'd just put
it there.
-JX
On Jan 23, 2007, at 11:23 AM, Jerone Young wrote:
So I started to move HYPERVISOR_grant_table_op from
arch/powe
the original script came from binutils and we simply adapted it.
I tried to simplify but I was unable to predict all the gcc created
sections for various gcc flags (esp -O2), so I just put all that
stuff back.
I'll try another pass at another time, when I can test all scenarios.
There is a h
In case you missed it, a lot has been going on so please:
1. reconfigure and build your linux
2. rebuild your Xen management tools (make install-tools)
3. and don't forget to rebuild xen :)
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xen
compiler warns ctxt and rc are unused and breaks build.
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
diff -r bd937e22541d tools/libxc/xc_resume.c
--- a/tools/libxc/xc_resume.c Sun Jan 21 09:12:57 2007 -0500
+++ b/tools/libxc/xc_resume.c Sun Jan 21 09:14:46 2007 -0500
@@ -13,20
On Jan 18, 2007, at 4:26 PM, Hollis Blanchard wrote:
On Thu, 2007-01-18 at 16:18 -0500, Jimi Xenidis wrote:
Hey, wouldn't virt_addr_valid() do?
I can pass a perfectly "valid" virtual address that is within a
physically discontiguous area of memory, and this function wo
On Jan 18, 2007, at 1:55 PM, Hollis Blanchard wrote:
On Thu, 2007-01-18 at 12:17 -0500, Jimi Xenidis wrote:
I agree with most of Hollis's comments, but have some of my own.
First, I do not think that the implementation of is_phys_contiguous()
answers the question in its name and IMNS
I agree with most of Hollis's comments, but have some of my own.
First, I do not think that the implementation of is_phys_contiguous()
answers the question in its name and IMNSHO is bogus. Perhaps
something like:
mm/sparse.c vaddr_in_vmalloc_area 232 static int
vaddr_in_vmalloc_area(void
Thanks Maria.. pushed.
On Jan 16, 2007, at 8:58 PM, Maria Butrico wrote:
Summary: fix for the prose builder.
Minor fixed for the prose builder.
Signed-off-by: Maria Butrico <[EMAIL PROTECTED]>
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.x
This broke the x86 build, I usually build x86 just to make sure it
does build but I guess I haven't since september.
-JX
On Jan 17, 2007, at 5:50 PM, Xen patchbot-xenppc-unstable wrote:
# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
---
diff -r 58d6c9cb95c6 tools/libxc/xc_tbuf.c
--- a/tools/libxc/xc_tbuf.c Wed Jan 17 14:57:04 2007 -0500
+++ b/tools/libxc/xc_tbuf.c Wed Jan 17 17:13:10 2007 -0500
@@ -96,15 +96,25 @@ int xc_tbuf_set_cpu_mask(int xc_
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
---
diff -r 58d6c9cb95c6 tools/libxc/xc_byteorder.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/tools/libxc/xc_byteorder.hWed Jan 17 16:42:03 2007 -0500
@@ -0,0 +1,33 @@
+#ifdef __sun__
+#include
+#define bswap_8 B
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
---
diff -r 58d6c9cb95c6 xen/common/bitmap.c
--- a/xen/common/bitmap.c Wed Jan 17 14:57:04 2007 -0500
+++ b/xen/common/bitmap.c Wed Jan 17 15:09:23 2007 -0500
@@ -10,6 +10,7 @@
#include
#include
#include
+#i
The following patches handle endian issues with converstion to
byte-stream bitmaps from: uint32_t, unint64_t, and long arrays.
Tried to be Solaris/Sun friendly
Build tested on x86.
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
___
Xen-ppc
I just forced a re-indexed my MacOS,Mail.app database, and some (4?)
really old emails went out.
Sorry about that.
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
splitting continues
On Oct 6, 2006, at 7:59 AM, Jimi Xenidis wrote:
Kawachiya-san, thank you for the exhaustive analysis!
On Oct 6, 2006, at 7:38 AM, Kiyokuni Kawachiya wrote:
3. I also cannot boot the official XenPPC in XenSource, which I
already
reported.
:
Welcome to
On Sep 10, 2006, at 2:57 AM, Muli Ben-Yehuda wrote:
On Sat, Sep 09, 2006 at 08:04:38PM -0400, Maria Butrico wrote:
Putting the partition xen console in the background (e. g, xm
create -c
... & or xm console &) seems to kill the console (xenconsole)
process.
Is this behavior expected?
Ce
On Jul 10, 2006, at 9:11 AM, Jimi Xenidis wrote:
the modules come from this ramdisk, but my guess is the ramdisk
does other stuff as well.
if you take this initrd and copy to you build machine, then:
1. $ gzip -c initrd > ramdisk.image.gz
2. $ cp ramdisk.image.gc /arch/powerpc/b
(root, "linux,initrd-start", val, sizeof(val[0]));
+ft_prop(root, "linux,initrd-end", val, sizeof(val[0]));
Now that we do this in libcx, we _can_ know the answer and define
them once and even drop the prop and reservation if there _is_ no
initrd.
-JX
On Jan 16, 2007
On Jan 16, 2007, at 10:05 AM, Ryan Harper wrote:
* Hollis Blanchard <[EMAIL PROTECTED]> [2007-01-15 20:44]:
On Mon, 2007-01-15 at 21:29 -0500, Jimi Xenidis wrote:
On Jan 15, 2007, at 8:20 PM, Hollis Blanchard wrote:
On Mon, 2007-01-15 at 17:25 -0500, Jimi Xenidis wrote:
+int make_d
On Jan 15, 2007, at 8:20 PM, Hollis Blanchard wrote:
On Mon, 2007-01-15 at 17:25 -0500, Jimi Xenidis wrote:
+int make_devtree(
[snip]
Any ideas what this reservation is for? is it for the flat-devtree
itself?
Nope.
+/* root.reserve(0x100, 0x1000) */
+val[0] = cpu_to_be64
Please double-check the usedbit issue below otherwise I'll ACK this.
-JX
On Jan 11, 2007, at 4:51 PM, Hollis Blanchard wrote:
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Date 1168550320 21600
# Node ID d98b2fbc100cfec5678a787ba7bfd0b065254793
# Parent dbc74db14a4b39d3593
On Jan 15, 2007, at 4:13 PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-15 14:53]:
On Jan 15, 2007, at 1:51 PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-11 16:53]:
[snip]
- renamed find_first_cpu to find_cpu, we don't care which
On Jan 15, 2007, at 1:51 PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-11 16:53]:
Ok there are a few things here.
BTW: some of these issues existed in the original python, but they
are yours now :)
Respun with fixes:
- preserve and return errno where appr
On Jan 15, 2007, at 12:37 PM, Hollis Blanchard wrote:
On Fri, 2007-01-12 at 20:34 -0500, Jimi Xenidis wrote:
I just built clean xenppc-unstable.hg (assuming it has the issues you
state below) and all IPI ^A*3 tests (esp 't' and 'd') work just fine
on my maple
What abo
Please check if you linux kernel is up to date.
I just built clean xenppc-unstable.hg (assuming it has the issues you
state below) and all IPI ^A*3 tests (esp 't' and 'd') work just fine
on my maple
I created an NFS domain and Did get:
(XEN) Assertion '!cpu_isset(nxt, cpu_core_map[cpu])' fai
Ok there are a few things here.
On Jan 11, 2007, at 1:42 PM, Ryan Harper wrote:
7 files changed, 617 insertions(+), 17 deletions(-)
tools/libxc/powerpc64/Makefile |1
tools/libxc/powerpc64/mk_flatdevtree.c | 520 ++
++
tools/libxc/powerpc64/mk_flatdevtr
Straight off, prose should have no flat tree reference at all.
-JX
On Jan 11, 2007, at 1:42 PM, Ryan Harper wrote:
5 files changed, 48 insertions(+), 376 deletions(-)
tools/python/xen/xend/FlatDeviceTree.py | 359
---
tools/libxc/powerpc64/xc_prose_build.c | 44
On Jan 10, 2007, at 4:29 PM, Hollis Blanchard wrote:
On Wed, 2007-01-10 at 13:55 -0500, Jimi Xenidis wrote:
SLOF:
- does implement, but does not update "available", though recent
resions might
Current SLOF does.
- "claim" will only tell you about conflicts its self
On Jan 10, 2007, at 12:43 PM, Hollis Blanchard wrote:
On Tue, 2007-01-09 at 12:24 -0500, Jimi Xenidis wrote:
We have currently have three page allocators. The first is PPC-
specific,
and it includes the Xen image, RTAS, and our copy of the Open
Firmware
device tree.
More precisely, it
On Mon, Jan 01, 2007 at 04:44:30PM +, Keir Fraser wrote:
On 1/1/07 12:21 am, "Rik van Riel" <[EMAIL PROTECTED]> wrote:
XenSource has usually been less than useful when it comes
to tracking the upstream kernel. I suspect they'll be
obsoleted by KVM and/or lhype at some point in the future
On Jan 9, 2007, at 12:34 PM, Segher Boessenkool wrote:
Wait a minute, doesn't systemsim has a passthrough call for
memmove? If
we should wire that up then this won't impact performance at all.
We were/are trying to eliminate all simulator specific passthrus
in the Xen core code.
That so
On Jan 9, 2007, at 12:09 PM, Hollis Blanchard wrote:
On Thu, 2007-01-04 at 15:56 -0500, Jimi Xenidis wrote:
We did a lot of work here so that stuff could be placed anywhere. I
admit it was not pretty but I'd expect this patch to
replace/improve
not remove.
The memmove below means
On Jan 9, 2007, at 11:24 AM, Hollis Blanchard wrote:
On Mon, 2007-01-08 at 18:38 -0500, Jimi Xenidis wrote:
Removing our custom allocator is important to simplify the
upcoming
multiboot2 conversion.
how?
We have currently have three page allocators. The first is PPC-
specific,
and
1 - 100 of 380 matches
Mail list logo
