http://lists.xensource.com/archives/html/xen-changelog/2008-05/msg00091.html
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
xperimental work has been done for e500 with KVM.
There's been some discussion on kvm-ppc-devel
(http://marc.info/?l=kvm-ppc-devel) .
Can I ask what your interest is? Are you a developer or just looking to
use it? If you had virtualization on e500 today, how would you use it?
--
Holli
kernel booting as a guest, but userspace doesn't work yet.
I think KVM makes more sense for embedded PowerPC because we can reuse
Linux's existing support for the huge variety of cores/chips/boards.
By the way, what RTOS are you using, and what sort of real-time an
(returning into elsewhere in Xen) or at the top of the stack
>
>
>
> _______
> Xen-ppc-devel mailing list
> Xen-ppc-devel@lists.xensource.com
> http://lists.xensource.com/xen-ppc-devel
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
I've been looking at the Xen patches first because those can go in
before the Linux patches. The opposite of course isn't true...
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
On Wed, 2007-08-15 at 12:46 +0900, Isaku Yamahata wrote:
> On Tue, Aug 14, 2007 at 09:48:00AM -0500, Hollis Blanchard wrote:
>
> > However, there are a few places below where you call memcpy() without
> > checking the result of xencomm_maddr_to_vaddr(). Actually, I see the
>
addr(paddr_to_maddr((unsigned long)*handle));
> if (desc == NULL)
> return -1;
>
> @@ -310,7 +322,8 @@ int xencomm_handle_is_null(void *handle)
> if (xencomm_is_inline(handle))
> return xencomm_inline_addr(handle) == 0;
>
> -desc = (struct xencomm_desc *)paddr_to_madd
xes are needed (especially
checking for the descriptor page overlap, and using get/put_page()).
However, this code is difficult to follow already, and these patches are
confusing *me* (and I wrote it! :) so I'm very nervous about increasing
the complexity.
Since the only issue you've ide
the
whole domain IMHO...
> +*page = virt_to_page(*maddr);
This line doesn't make sense. Is it an maddr or a vaddr? If it's an
maddr, we shouldn't be passing it as "virt" to virt_to_page().
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
looks suspicious if it's supposed to be an ELF
file...
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
operly?
> At least my powerpc64-linux-gcc (gcc 4.1.1) doesn't seem to support
> __attribute__((aligned(32))) on stack variables.
Hmm, the bug includes a comment that says "If the code is not very
complex, the alignment appears to work," so I guess we've just
On Fri, 2007-08-03 at 11:12 +0900, Isaku Yamahata wrote:
> On Thu, Aug 02, 2007 at 10:00:46AM -0500, Hollis Blanchard wrote:
> > On Thu, 2007-08-02 at 11:44 +0900, Isaku Yamahata wrote:
> > >
> > > > But we can issue sequential p2m hcalls with different offsets, s
On Mon, 2007-07-30 at 17:11 -0500, Hollis Blanchard wrote:
> Hi Keir, please from
> http://xenbits.xensource.com/ext/ppc/xen-unstable.hg
>
> There are a pair of build fixes and support for the new multiboot2
> loader in grub2.
... except I forgot to commit the new multiboo
> > implement a couple hooks; I can't imagine it would take more than a day
> > to do it.)
>
> Sorry for that. It seems to be good time to resolve it.
> I'll work on xencomm consolidation.
No need to apologize, I'm just surprise
cross a page boundary. So
even if Linux sends down a multipage descriptor, Xen will return EINVAL.
Am I missing something?
(As a side question, is it really so difficult for you guys to just use
the common code? I tried very hard to make it easy for you to just
implement a couple hooks; I can&#x
Hi Keir, please from
http://xenbits.xensource.com/ext/ppc/xen-unstable.hg
There are a pair of build fixes and support for the new multiboot2
loader in grub2.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen
Hi Keir, please pull from both
http://xenbits.xensource.com/ext/ppc/linux-2.6.18-xen.hg
and
http://xenbits.xensource.com/ext/ppc/xen-unstable.hg
Along with a couple build fixes, we now support in-guest profiling and
support for the ACM hypercalls (thanks Stefan!).
--
Hollis Blanchard
IBM Linux
0x3f875eb0
It also looks like we need to have the callers of paddr_to_maddr()
(within Xen) do some error-checking and return the error.
However, it isn't the kernel's job to be checking these addresses, so
this patch isn't the right solution.
--
H
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? The
ric file. If
> !ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up the Xen
> mem_fops?
Hmmm, yeah. Looks like we haven't tested that... :)
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-de
ouldn't that be a a write lock rather than a read lock?
[XEN][LINUX] Take a writer lock for mmap_sem.
direct_remap_pfn_range() will be modifying the mm.
Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
diff -r e5f633c33025
ludes changes necessary to run the new Linux
2.6.18 kernel.
Thanks!
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
On Fri, 2007-07-06 at 17:09 +0100, Jan Beulich wrote:
> >>> Hollis Blanchard <[EMAIL PROTECTED]> 06.07.07 17:44 >>>
> >> Where does the hypercall argument translation happen?
> >
> >It happens inside privcmd_hypercall(). See
> >http://xenbit
3 files changed, 24 insertions(+), 14 deletions(-)
arch/ia64/xen/hypervisor.c |5 +
drivers/xen/core/gnttab.c | 31 +--
include/xen/gnttab.h |2 ++
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Date 1183738982 18000
# N
he function is named "arch_privcmd_hypercall".) IA64 and
PPC both implement this function now; only x86 is left with #ifdefs in
drivers/xen/privcmd/privcmd.c .
COMPATIBLE_IOCTL is just about the ioctl itself, not the sub-structures.
--
Hollis Blanchard
IBM Linux Technology Center
___
; printk("%s: new_addr not supported\n", __func__);
> BUG();
> return GNTST_general_error;
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,
On Thu, 2007-07-05 at 22:41 +0100, Keir Fraser wrote:
> 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 com
On Thu, 2007-07-05 at 22:44 +0100, Keir Fraser wrote:
> On 5/7/07 22:35, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
>
> >>> +config XEN_XENCOMM
> >>> + bool
> >>> +
> >>
> >> Shouldn't this have a 'depend
On Thu, 2007-07-05 at 22:29 +0100, Keir Fraser wrote:
> 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/driv
On Thu, 2007-07-05 at 13:07 -0500, Hollis Blanchard wrote:
> Hi Christian, as far as I can see the vast majority of this patch is
> not needed; the only part that's required is
> phys_to_machine_mapping_valid().
I take it back. Not sure how I wasn't seeing this before...
-
e_ma(pfn, prot) __pte(((pfn) << PAGE_SHIFT) |
> pgprot_val(prot))
>
> typedef unsigned long maddr_t;
> +typedef unsigned long paddr_t;
>
> #ifdef CONFIG_XEN_SCRUB_PAGES
Hi Christian, as far as I can see the vast majority of this patch is not
needed; the only part that's require
're not already an MQ user, see
http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension or just
patch by hand.
I haven't figured out how to effectively share this queue, but since I
think it's pretty much done at this point, we'll be able to commit and
send upstream soon (but I w
t; Thanks,
> James Markakis
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of James
> Bulpin
> Sent: Monday, June 18, 2007 3:20 PM
> To: Ian Campbell; Jimi Xenidis
> Cc: [EMAIL PROTECTED]; Hollis Blanchard; James Bulpin; Aron
> Griffis;
it, so essentially we're talking about a
rewrite to move to 32-bit. Since 32-bit PowerPC don't have hardware
support for hypervisors, you'd need to emulate a lot in software (which
must be the approach taken by Integrity Padded Cell).
--
Hollis Blanchard
IBM Li
space as needed, rather than halving the physical address space. For the
moment though, it also looks like a fair amount of more code... :)
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
y since most "64-bit"
processors don't use many more bits than that anyways...
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 too
On Mon, 2007-06-04 at 13:02 -0600, Alex Williamson wrote:
> On Mon, 2007-06-04 at 12:46 -0500, Hollis Blanchard wrote:
> > On Mon, 2007-06-04 at 11:25 -0600, Alex Williamson wrote:
> > >
> > > > Another option would be to move the ia64 and ppc trees into separate
pull it all into xen-unstable.hg.
xenppc-unstable-merge.hg is much cleaner.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
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 ?
--
Hollis Blanchard
IBM Linux Tec
This is a workaround that might get you past your current problem.
There were also another boatload of fixes to this code that just landed
30 minutes ago, so you should probably try tip again first.
--
Hollis Blanchard
IBM Linux Technology Center
--- Begin Message ---
diff -r bb9ed6b69f8c
>4443 inst = XendNode()
> File "//usr/lib/python/xen/xend/XendNode.py", line 168, in
> __init__
>4445 XendPIF.recreate(pif, pif_uuid)
>4446 File "//usr/lib/python/xen/xend/XendPIF.py&quo
e printk prefix "(XEN) " when falling into gdb, because gdb
> tried to parse the "(XEN) " response sometimes
> - return E00 on unknown command (thx to jimi)
Without the "(XEN)" prefix, won't GDB still try to parse printk output
as pa
> #include
> #include
>
> -#define DEBUG
> +#undef DEBUG
>
> #ifdef DEBUG
> #define DBG(fmt...) printk(fmt)
I committed something like this recently, so if you update your Linux
tree it should be fixed.
--
Hollis Blanchard
IBM Linux Technology Center
___
,
so in theory it should be possible to port Xen to it. I wouldn't call
its core "970 compatible" other than in the way all PowerPC cores are
+/- "compatible".
PS3 has its own hypervisor which of course won't let user-supplied code
run in hypervisor mode.
--
Hi Keir, please pull from
http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg
It contains two build fixes needed for 3.0.5 and one bug fix.
Thanks!
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
[EMAIL
On Thu, 2007-04-05 at 17:59 +0100, Keir Fraser wrote:
> 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 t
On Thu, 2007-04-05 at 16:56 +0100, Keir Fraser 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
.
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
static inline xchg(atomic_t *ptr, a
strlcpy(bootargs, cmdline, sizeof(bootargs));
> +}
> bsz = strlen(bootargs) + 1;
> rm = sizeof (bootargs) - bsz;
Scary, it looks like we're doing strlen(NULL) in strlcpy(), which must
be returning a non-0 length (since the memory at 0 actually cont
l need a Linux patch
because that bit is hardcoded in some assembly.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
.hg remains as our Linux
tree.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
\scratch,\scratch,MMCR0_FCH
> mtspr SPRN_MMCR0, \scratch
> .endm
>
> and added the following to EXCEPTION_HEAD, but I guess it it wrong that
> way ;)
>
> PMU_SAVE_STATE r0 r0
Right, that won't fit in EXCEPTION_HEAD (you will get the assembler
error messages Jimi pasted above).
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
code
changes. Once you grasp the core data structures, cscope can tell you
all you need to know. :)
However, having a high-level description of e.g. event channels is
valuable. Some of that information is actually available in docs/src
('make docs' should build it), and also on the wi
was a bad idea, and I would be
happy to elaborate for anybody who is considering this model.)
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
one of the next implementation steps.
> Should/Can I use this complex hcall to set that simple flag e.g. by
> skipping all other attributes or do we need a new one?
I think you should use the current H_PERFMON hcall. It's really not
complex...
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
uestion about translation. The domains do not
share code. For example, it is not possible for an interrupt in Dom1 to
trigger an exception handler in Dom0.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
gest issue for us
is that the System p hypervisor prevents all other software from using
hypervisor mode on these processors, and that is what Xen requires.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@li
ng ifdefs)
wherever possible.
Here's my current confusion: where are these ELF features described?
Since PowerPC domU communicate only via GPFNs, do I need to set the
"auto-translated" feature?
What is the difference between dom->shadow_enable and
xc_dom_feature_translated()?
--
Ho
pend a lot of time
replaying the ticks it missed.
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.
--
Hollis Blanchard
IBM Linux Technology Center
___
that would be possible, so I assume a20ec270998b was just an
oversight?
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
On Fri, 2007-03-02 at 17:52 -0600, Hollis Blanchard wrote:
> Hi Keir, could you please pull from
> http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg ?
>
> There are two patches that touch common code:
> * Add a guest_physmap hook for max_mem changes. We've fina
ude/asm/platform.h' instead of
asm-powerpc. I think I've fixed it now.
I also opened a Mercurial bug
(http://www.selenic.com/mercurial/bts/issue509) to try to prevent this
from happening in the future.
--
Hollis Blanchard
IBM Linux Technology Center
_
iry to me, but when I sat down with it I couldn't
figure out how to improve it, at least until PowerPC gets rid of
some assumptions about MFN locations.
Thanks!
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-de
>
> define_machine(xen) {
> - .name = "Xen-Maple",
> + .name = "Xen",
> .probe = xen_probe,
> .setup_arch = xen_setup_arch,
> + .show_cpuinfo = xen_show_
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, at 3:43 PM, Hollis Blanchard wrote:
>
> > Jimi, the context is that we need to modify Fedora's installer so that
> >
ly be better. What do you guys
> > think ?
> >
> >
> > ___
> > Xen-ppc-devel mailing list
> > Xen-ppc-devel@lists.xensource.com
> > http://lists.xensource.com/xen-ppc-devel
>
>
> ___
> Xen-ppc-devel mailing list
> Xen-ppc-devel@lists.xensource.com
> http://lists.xensource.com/xen-ppc-devel
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
I pushed a xen-unstable merge to xenppc-unstable yesterday. It pretty
much shouldn't matter, and we aren't all the way caught up with upstream
xen-unstable yet, but just FYI.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-dev
On Mon, 2007-02-26 at 23:39 +, Keir Fraser wrote:
> 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 d
ery 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.
--
Hollis Blanchard
IBM Linux Technology Center
On Fri, 2007-02-23 at 11:12 -0600, Ryan Harper wrote:
> * Hollis Blanchard <[EMAIL PROTECTED]> [2007-02-23 10:58]:
> > On Fri, 2007-02-23 at 10:21 -0600, Ryan Harper wrote:
> > >
> > > The other method I was going to look into was to allocate dom0's rma,
>
fn + dom0_nrpages - rma_sz) -
> IO_SIZE_PAGES;
>
> Any other good way to figure how much of dom0's allocation will fall
> within 2-4G IO hole?
Why are you looking for another approach? What's wrong with this
solution?
--
Hollis Blanchard
IBM Linux Technology Center
_
your question, the 970MP (in JS21) supports the same RMA sizes
as 970 and 970FX (in JS20).
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
re splitting these patches up a lot more than necessary (to
the point I've having a hard time understanding them). Also, the above
code is just removed by the next patch! If you combine 4 and 5 I think
it will actually be smaller and easier to understan
powerpc/shadow.hWed Feb 21 18:14:12 2007 -0600
> @@ -37,6 +37,10 @@ extern void guest_physmap_remove_page(
> extern void guest_physmap_remove_page(
> struct domain *d, unsigned long gpfn, unsigned long mfn);
>
> +int do_guest_physmap_max_mem(struct domain *d, unsig
On Wed, 2007-02-14 at 18:55 +, Keir Fraser wrote:
> 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
domain heap to avoid exhausting the Xen heap.
We don't need to use an array long-term, though I think it's the easiest
initial implementation.
The simplest version of this patch would just replace the RMA and extent
list walking in pfn2mfn(), so it's nothing radical.
--
Hollis B
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 comments on this?
--
Hollis Blanchard
IBM Linu
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.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel
tatic void boot_of_alloc_init(int m, ui
u64 start;
u64 size;
+if (((ulong)_end >> PAGE_SHIFT) >= MEM_AVAILABLE_PAGES)
+of_panic("image is too big");
+
rc = of_getprop(m, "available", a, sizeof (a));
if (rc > 0) {
int l = rc
tirq() crashes trying to call a
null function pointer.
In cases like this where you *know* you're going to break the non-x86
architectures, please email xen-ppc-devel and xen-ia64-devel to let us
know what we'll need to do in the future, rather than force us to
reverse-engineer the crash.
Th
trick, maybe something like:
if (dom0_start + dom0_len > (32<<20))
panic("dom0 is too big");
--
Hollis Blanchard
IBM Linux Technology Center
On Wed, 2007-02-07 at 11:48 -0600, Jerone Young wrote:
> OK all is well...no fire here...move along. I fig
a(), should only be used when building the contents of
> "desc" in order to describe "data", _not_ in creating the value of
> "desc", that should always be __pa().
Yup, using __va() and __pa() should work because desc is always obtained
via kmalloc
On Fri, 2007-01-26 at 10:58 -0600, Hollis Blanchard wrote:
> On Fri, 2007-01-26 at 13:43 +, Keir Fraser wrote:
> > Hi,
> >
> > This is a heads up, mainly to the PowerPC and IA64 folks, that Gerd's new
> > domain builder (including new Elf parser) is now checked
you *do* use the common elf parser, and so your domain builder code needs to
> be changed to talk to Gerd's libelf.
Gerd, what do we need to do to replace probe_elf()/load_funcs ?
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-dev
What exact model do you have: 8842-21X, 8842-41X, or 8842-42X? I assume
you have a lot of them?
--
Hollis Blanchard
IBM Linux Technology Center
On Mon, 2007-01-22 at 22:31 +0100, Mario Macías wrote:
> Hi Hollis,
> We are using JS20 machines.
> Regards
>
> En/na Hollis Blan
"0x%lx[size 0x%lx]\n",
__func__, mod0_start, mod0_size);
--
Hollis Blanchard
IBM Linux Technology Center
On Mon, 2007-01-22 at 15:31 -0500, Mark F Mergen wrote:
>
> I cannot replicate Stuart's successful report. I'm su
ree before that changeset went in (hg update -C $(hg parents -qr
5bcb155e5de5)).
Thanks!
--
Hollis Blanchard
IBM Linux Technology Center
On Sun, 2007-01-21 at 19:24 -0500, Mark F Mergen wrote:
>
> From the standpoint of us Lone Rangers using Mambo (Stuart and me),
> things are bro
Xen with our testing
> into research applications.
Hi Mario, nice to meet you. :) What sort of PowerPC systems do you plan
to use Xen on?
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
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.
--
Hollis Blanchard
IBM Linux Technology Center
On Thu, 2007-01-18 at 19:05 -0800, Xen patchbot-uns
On Thu, 2007-01-18 at 17:16 -0500, Jimi Xenidis wrote:
> 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 per
On Thu, 2007-01-18 at 16:18 -0500, Jimi Xenidis wrote:
> 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.
> >>
> >> F
+}
...
>
> Since we are completely automating MINI we can simplify (remove) all
> the alignment logic by asking gcc for some help.
>
> > +#define xencomm_map_early(ptr, bytes) \
> > + ({char xc_area[XENCOMM_MINI_AREA];\
> ({char xc_area[XENCOMM_MINI_AREA] \
>
On Fri, 2007-01-12 at 11:40 -0600, Hollis Blanchard wrote:
> While pushing a couple of Ryan's patches, I accidentally pushed a
> broken merge into xenppc-unstable. (I really don't know why I was
> trying to merge using my "pristine" tree.) So that tree is going to
&
id *)(paddr | XENCOMM_INLINE_FLAG);
}
We should change this to BUG_ON(!is_phys_contig((unsigned long)ptr)) to
prevent accidents.
As soon as these issues are solved and you've tested the patch with VIO
modules, I'll check it in.
--
Hollis Blanchard
IBM Linux Technology Center
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_devtree(
> >> [snip]
> >>>> Any ideas what this reserv
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Date 1168914221 21600
# Node ID dc8551babde44184e72cada0416b9c1f19ed1ada
# Parent dbc74db14a4b39d359365fcf8257216d968fa269
[POWERPC][XEN] Mark heap memory based on boot_of.c's allocator.
- Explain why we have anothe
KiB)\n", eomem >> 20, eomem >>
> > 10);
> >
> > -/* Architecturally the first 4 pages are exception hendlers, we
> > - * will also be copying down some code there */
> > +/* Architecturally the first 4 pages are exception handlers. */
>
000, 0x1000) */
> >>> +val[0] = cpu_to_be64((u64) 0x100);
> >>> +val[1] = cpu_to_be64((u64) 0x1000);
> >>> +ft_add_rsvmap(root, val[0], val[1]);
Yes, it is: see DEVTREE_ADDR in xc_linux_build.c .
--
Hollis Blanchard
IBM Linux Technology Center
_
On Mon, 2007-01-15 at 11:23 -0600, Hollis Blanchard wrote:
> On Fri, 2007-01-12 at 19:41 -0500, Amos Waterland wrote:
> > On Fri, Jan 12, 2007 at 05:45:03PM -0600, Hollis Blanchard wrote:
> > > We seem to have an IPI problem, which causes vcpu_pause() to hang the
> > >
t we solved it so well, paravirt_ops was modeled on PowerPC's
struct machdep_calls. x86 is playing catchup here.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
1 - 100 of 330 matches
Mail list logo
