[XenPPC] latest noHV patches
Patches for noHV are up-to-date and tested with trees from the repository as of the date and time of this posting. I can send them to anyone interested, but probably the only people who have interest also have access to my tress and can get the patches there. The Xen patch is in /a/kix/homes/kix/mergen/xen/xen-nohv/xen-nohv. The Linux patch is in /a/kix/homes/kix/mergen/xen/linux/linux-2.6.prlp/linux-prlp. For Xen you also need the two new files nohv.c and nohv.h which are in /a/kix/homes/kix/mergen. They need to be placed in your tree in your analogue of xen/xen-nohv/xen/arch/powerpc/powerpc64/nohv.c and xen/xen-nohv/xen/include/asm-powerpc/nohv.h. Mark Mergen___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] merge with linux-2.6.tip-xen.hg
On Mon, Aug 07, 2006 at 06:44:01PM -0400, Jimi Xenidis wrote: > > What you did not see is the merge linux-2.6.tip-xen.hg which would > have resulted in 2492 emails :( How do you get around the massive "spam" when merging upstream? currently I filter based on commiter, but that's obviously very fragile. Cheers, Muli ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [RFC] consolidated libdt proposal
On 08 Αυγ 2006, at 8:37 ΠΜ, Haren Myneni wrote: Hollis Blanchard wrote: On Sun, 2006-08-06 at 19:38 -0500, Hollis Blanchard wrote: Hmm, so we'll have at least three copies of this code: uboot, kernel, and Xen. Would it make sense to put this stuff into a libdt.a? Technically, dtc has a "libdt" already, but it's absurdly incomplete (I don't even know why it's there), so we could just replace it. Mark, I had a look at the code Pantelis wrote for u-boot, and it was pretty easy to adapt to meet Xen's (userspace-based) needs. I've attached my version below (and see ft_setup() at the bottom of the file). Does it meet your requirements for the kernel bootwrapper? One limitation of the attached code is that it doesn't support changing the *size* of properties, though I don't think that would be too difficult to add if needed. Haren, what about using this in kexec-tools? Hollis, Good idea to have this lib. Based on brief look, some of these funcs are also useful for kexec-tools. Yes, as you mentioned, changing the size of properties is important for kexec/kdump. Present flattened device-tree process in kexec-tools: - Kexec-tool reads the /proc/device-tree and sort these entries since we get the different order than the first kernel uses. - creates linux,usable-memory property under /proc/device-tree/ [EMAIL PROTECTED] as appropriate. (for kdump) - Modify the reserve map for RTAS, initrd, TCE and (0- crashkernel- start) - Create initrd properties if not exist in the first kernel as needed - Modify bootargs property Thanks Haren Hi Haren, Mind writing down what your requirements are? Just modifying the size of the properties? Note that my functions work in a two phases. In the first phase the tree is build with the string table being put at the end of the allocated memory area in a downward motion. When the tree is finalized the string table is memmov'ed to be adjacent to the structure proper. Could you use this two phased approach for you uses? I.e. first work with maximum sized properties and perform a move & fixup stage when finalizing? Regards Pantelis If everybody can use this (I expect small modifications would be needed), I think we should turn it into a library in the dtc source tree. The various projects using it could then include snapshots (to avoid dependencies). In general I'd like to avoid everybody writing and maintaining their own version of this stuff (myself included). - --- / ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [linux-ppc-2.6] [POWERPC] init hpte pointers in probe
# HG changeset patch
# User Jimi Xenidis <[EMAIL PROTECTED]>
# Node ID dbc5fdc3a38251f8a11eb442c6e9139b36e02e54
# Parent 29fd5adfdc07e67c065ee00987317d58f6bcdd1f
[POWERPC] init hpte pointers in probe
Just like everyone else, reduces out non-xen patch, which is always goodness.
Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/xen/setup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -r 29fd5adfdc07 -r dbc5fdc3a382 arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.cMon Aug 07 18:15:57 2006 -0400
+++ b/arch/powerpc/platforms/xen/setup.cMon Aug 07 18:27:04 2006 -0400
@@ -90,8 +90,6 @@ static void __init xen_init_early(void)
DBG(" -> %s\n", __func__);
- hpte_init_lpar();
-
xen = of_find_node_by_path("/xen");
si = (u64 *)get_property(xen, "start-info", NULL);
@@ -260,6 +258,8 @@ static int __init xen_probe(void)
return 0;
xen_fw_feature_init();
+
+ hpte_init_lpar();
return 1;
}
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] fixed bad swap of console and store event channels
On Aug 6, 2006, at 7:27 PM, [EMAIL PROTECTED] wrote: Quoting Jimi Xenidis <[EMAIL PROTECTED]>: Unfortunately this isn't working for me: my output stops after PID hash table entries: 512 (order: 9, 4096 bytes) Hmm, thats odd, this is where it used to hang. When I bang keys, I can see events going on dom0 evtchn 10/domU evtchn 2: dom0/10 sends an event to domU/2 (presumably to notify domU of the input), and domU/2 sends an event to dom0/10 (presumably to notify dom0 that there is new console output to display). Strace on the "xm console" process seems to confirm that the incoming event does not wake xm console from its select() call. xm console launches xenconsole, but that just sits on a PTY, the program that actually select()s on evtchns is xenconsoled (the daemon. I'm pretty sure I've rebuilt/reinstalled the various components cleanly, twice. Could there be an outstanding diff still? There was a Linux push after this mail, hg shows nothing in status or outgoing Did you re-install (make install-tools) in dom0? That _is_ where the bug was. Clean builds on my end have everything working. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [linux-ppc-2.6] [POWEPRC] new default config
# HG changeset patch # User Jimi Xenidis <[EMAIL PROTECTED]> # Node ID e4a11039ee9ec7b0b728981fc7b0a6c0c972b0e4 # Parent dbc5fdc3a38251f8a11eb442c6e9139b36e02e54 [POWEPRC] new default config --- arch/powerpc/configs/xen_maple_defconfig | 18 -- 1 files changed, 16 insertions(+), 2 deletions(-) diff -r dbc5fdc3a382 -r e4a11039ee9e arch/powerpc/configs/xen_maple_defconfig --- a/arch/powerpc/configs/xen_maple_defconfig Mon Aug 07 18:27:04 2006 -0400 +++ b/arch/powerpc/configs/xen_maple_defconfig Tue Aug 08 09:36:48 2006 -0400 @@ -1,13 +1,14 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.17 -# Wed Jul 26 14:58:48 2006 +# Tue Aug 8 09:35:08 2006 # CONFIG_PPC64=y CONFIG_64BIT=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y @@ -34,6 +35,7 @@ CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=32 +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options @@ -68,6 +70,7 @@ CONFIG_BUG=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y +CONFIG_RT_MUTEXES=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y @@ -118,6 +121,7 @@ CONFIG_PPC_MAPLE=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set +# CONFIG_UDBG_RTAS_CONSOLE is not set CONFIG_PPC_XEN=y CONFIG_XICS=y CONFIG_U3_DART=y @@ -151,6 +155,7 @@ CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_IOMMU_VMERGE=y # CONFIG_HOTPLUG_CPU is not set +CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_IRQ_ALL_CPUS=y @@ -173,6 +178,7 @@ CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_EXTREME=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_RESOURCES_64BIT=y # CONFIG_PPC_64K_PAGES is not set # CONFIG_SCHED_SMT is not set CONFIG_PROC_DEVICETREE=y @@ -699,6 +705,7 @@ CONFIG_VT=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y +# CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_SERIAL_NONSTANDARD is not set # @@ -727,6 +734,7 @@ CONFIG_HVC_CONSOLE=y # Watchdog Cards # # CONFIG_WATCHDOG is not set +CONFIG_HW_RANDOM=y CONFIG_GEN_RTC=y # CONFIG_GEN_RTC_X is not set # CONFIG_DTLK is not set @@ -809,7 +817,6 @@ CONFIG_I2C_AMD8111=y # # Dallas's 1-wire bus # -# CONFIG_W1 is not set # # Hardware Monitoring support @@ -836,6 +843,7 @@ CONFIG_VIDEO_V4L2=y # # Graphics support # +CONFIG_FIRMWARE_EDID=y # CONFIG_FB is not set # @@ -1049,6 +1057,7 @@ CONFIG_INFINIBAND_IPOIB_DEBUG=y CONFIG_INFINIBAND_IPOIB_DEBUG=y CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y CONFIG_INFINIBAND_SRP=y +# CONFIG_INFINIBAND_ISER is not set # # EDAC - error detection and reporting (RAS) (EXPERIMENTAL) @@ -1169,6 +1178,7 @@ CONFIG_RPCSEC_GSS_KRB5=y # CONFIG_RPCSEC_GSS_SPKM3 is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set +# CONFIG_CIFS_DEBUG2 is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set @@ -1247,6 +1257,7 @@ CONFIG_CRC32=y CONFIG_CRC32=y # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y +CONFIG_PLIST=y # # Instrumentation Support @@ -1259,12 +1270,15 @@ CONFIG_ZLIB_INFLATE=y # # CONFIG_PRINTK_TIME is not set CONFIG_MAGIC_SYSRQ=y +# CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_MUTEXES=y +# CONFIG_DEBUG_RT_MUTEXES is not set +# CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_KOBJECT is not set ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] latest noHV patches
On Tue, 2006-08-08 at 04:45 -0400, Mark F Mergen wrote: > > Patches for noHV are up-to-date and tested with trees from the > repository as of the date and time of this posting. I can send them > to anyone interested, but probably the only people who have interest > also have access to my tress and can get the patches there. Hi Mark, we have non-IBM folks on this list, and even some IBMers (like me) have no idea how to access the distributed filesystem you seem to be using. Could you send out patches? 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
[XenPPC] bugzilla request
Hi James, I've started using http://bugzilla.xensource.com/ to track PowerPC issues. I was wondering if we could make it so that all Platform==PPC bugs could be assigned by default to xen-ppc-devel, or at least CCed there? (If the mail becomes too much then we may want to change that, but for now I think it should be fine.) How does that work with the xen-bugs mailing list? When a bug is assigned to someone, do you then put xen-bugs on CC? -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] architecture-specific stuff in xend
Hi Ewan, I'm almost ready to integrate some PPC-specific stuff into
xend, and I was wondering if you had a plan for how that should work.
First example: the device tree data structure we talked about a few
weeks ago. We will need to pass the config data to PPC code, probably in
XendDomainInfo.initDomain(), and then pass the resulting data structure
into libxc's xc_linux_load() somehow.
As another example, initDomain() already has some architecture hackage
in it for memory allocation. We think we'll need to modify that some
more in the future for PPC, possibly even changing the "order" argument
to xc.domain_memory_increase_reservation().
Rather than having these inline tests everywhere ("if os.uname()[4] in
('ia64', 'ppc64'):"), would it make more sense to have some sort of
"architecture" object, and do things like:
class Architecture:
def init_reservation(self, mem_kb):
return mem_kb
def init_reservation_order(self):
return 0
class ia64_Architecture(Architecture):
def init_reservation(self, mem_kb):
if 'hvm' in xc.xeninfo()['xen_caps']:
mem_kb += 4*1024;
return mem_kb
Sample use in XendDomainInfo.py:
from xen.xend import arch
...
init_reservation = arch.init_reservation(mem_kb)
I'm not sure how/where to instantiate the arch object though.
Does that make sense to you? The Architecture object would expand to
include every piece of arch-specific functionality we run across in the
future.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] architecture-specific stuff in xend
On Tue, Aug 08, 2006 at 10:34:25AM -0500, Hollis Blanchard wrote:
> Rather than having these inline tests everywhere ("if os.uname()[4] in
> ('ia64', 'ppc64'):"), would it make more sense to have some sort of
> "architecture" object, and do things like:
It'd be good if it were slightly more general and covered other system
stuff too (namely OS). On Solaris some of the Xen binaries/scripts live
in different locations in order to meet our file system requirements.
> I'm not sure how/where to instantiate the arch object though.
Presumably you could do the instance() singleton trick?
regards
john
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] architecture-specific stuff in xend
On Tue, 2006-08-08 at 16:59 +0100, John Levon wrote:
> On Tue, Aug 08, 2006 at 10:34:25AM -0500, Hollis Blanchard wrote:
>
> > Rather than having these inline tests everywhere ("if os.uname()[4] in
> > ('ia64', 'ppc64'):"), would it make more sense to have some sort of
> > "architecture" object, and do things like:
>
> It'd be good if it were slightly more general and covered other system
> stuff too (namely OS).
Sure, we could make it "class Platform" and have it represent an
architecture/OS pair.
> On Solaris some of the Xen binaries/scripts live
> in different locations in order to meet our file system requirements.
Does that impact code under tools/python/xen much?
> > I'm not sure how/where to instantiate the arch object though.
>
> Presumably you could do the instance() singleton trick?
Not sure what you mean.
Actually, you bring up a good point: since we have no state (at least
not in the examples I'm thinking of), we really don't want/need a class;
a module would do just fine. So we could have separate files/modules
with just plain functions:
platform/ia64.py:
def init_reservation(mem_kb):
return something
platform/platform.py:
import xen.xend.platform.ia64 as platform
... or something. Like I said, I really don't know modules, but as long
as we don't have any arch-specific state we need to save, I'm pretty
sure modules are the right solution to this problem.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] architecture-specific stuff in xend
On Tue, Aug 08, 2006 at 11:15:18AM -0500, Hollis Blanchard wrote: > > On Solaris some of the Xen binaries/scripts live > > in different locations in order to meet our file system requirements. > > Does that impact code under tools/python/xen much? Very little, but it does affect the location of the network scripts, for example. > > Presumably you could do the instance() singleton trick? > > Not sure what you mean. See XendRoot.py's instance(). > Actually, you bring up a good point: since we have no state (at least > not in the examples I'm thinking of), we really don't want/need a class; > a module would do just fine. So we could have separate files/modules > with just plain functions: > > platform/ia64.py: > def init_reservation(mem_kb): > return something > > platform/platform.py: > import xen.xend.platform.ia64 as platform We'd still need something to import the right bits... regards john ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [RFC] consolidated libdt proposal
Hi Hollis, On Mon, Aug 07, 2006 at 04:58:41PM -0500, Hollis Blanchard wrote: > On Sun, 2006-08-06 at 19:38 -0500, Hollis Blanchard wrote: > > > > Hmm, so we'll have at least three copies of this code: uboot, kernel, > > and Xen. Would it make sense to put this stuff into a libdt.a? > > Technically, dtc has a "libdt" already, but it's absurdly incomplete > > (I don't even know why it's there), so we could just replace it. > > Mark, I had a look at the code Pantelis wrote for u-boot, and it was > pretty easy to adapt to meet Xen's (userspace-based) needs. I've > attached my version below (and see ft_setup() at the bottom of the > file). Does it meet your requirements for the kernel bootwrapper? [Disclaimer: I did a fairly quick scan of your patch so I may have misread or missed something.] Except for not being able to extend a property (see below), I think it does meet my needs (at least as I know them today). However, I was hoping to keep the interfaces in the bootwrapper similar to the ones used in the kernel. To that end, I had a routine to find a device node and other routines to find and modify a property within that node. I didn't notice a "finddevice" type of function to find a device node. Would you have a problem adding one? > One limitation of the attached code is that it doesn't support changing > the *size* of properties, though I don't think that would be too > difficult to add if needed. If we're going to allow cmdline editing in the bootwrapper, we would need to extend the size of a property. We've never really talked about cmdline editing in the powerpc branch but I assume that its a good thing(tm). I know I would like to have it so, IMHO, I think we should add it (and therefore require extending a property). Mark ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [TOOLS] allow the selection of blktap and firmware thru config files
# HG changeset patch # User Jimi Xenidis <[EMAIL PROTECTED]> # Node ID 4f919c8e61adff4d8db75bbc8bfbd97d0d536701 # Parent 058f2e27476d686538de2671f57c1ded5c693b47 [TOOLS] allow the selection of blktap and firmware thru config files The following patch enables blktap and firmware using config variables. Specific issues are with POWERPC: 1) does not require firmware build 2) nasty build break in libaio I'm guessing for IA64. Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]> --- config/ia64.mk |2 ++ config/x86_32.mk |2 ++ config/x86_64.mk |2 ++ tools/Makefile |9 - 4 files changed, 10 insertions(+), 5 deletions(-) diff -r 058f2e27476d -r 4f919c8e61ad config/ia64.mk --- a/config/ia64.mkMon Aug 07 17:49:16 2006 -0500 +++ b/config/ia64.mkTue Aug 08 14:01:39 2006 -0400 @@ -1,5 +1,7 @@ CONFIG_IA64 := y CONFIG_IA64 := y CONFIG_IOEMU := y CONFIG_XCUTILS := y +CONFIG_BLKTAP := y +CONFIG_FIRMWARE := y LIBDIR := lib diff -r 058f2e27476d -r 4f919c8e61ad config/x86_32.mk --- a/config/x86_32.mk Mon Aug 07 17:49:16 2006 -0500 +++ b/config/x86_32.mk Tue Aug 08 14:01:39 2006 -0400 @@ -4,6 +4,8 @@ CONFIG_XCUTILS := y CONFIG_XCUTILS := y CONFIG_IOEMU := y CONFIG_MBOOTPACK := y +CONFIG_BLKTAP := y +CONFIG_FIRMWARE := y CFLAGS += -m32 -march=i686 LIBDIR := lib diff -r 058f2e27476d -r 4f919c8e61ad config/x86_64.mk --- a/config/x86_64.mk Mon Aug 07 17:49:16 2006 -0500 +++ b/config/x86_64.mk Tue Aug 08 14:01:39 2006 -0400 @@ -4,6 +4,8 @@ CONFIG_XCUTILS := y CONFIG_XCUTILS := y CONFIG_IOEMU := y CONFIG_MBOOTPACK := y +CONFIG_BLKTAP := y +CONFIG_FIRMWARE := y CFLAGS += -m64 LIBDIR = lib64 diff -r 058f2e27476d -r 4f919c8e61ad tools/Makefile --- a/tools/MakefileMon Aug 07 17:49:16 2006 -0500 +++ b/tools/MakefileTue Aug 08 14:01:39 2006 -0400 @@ -1,4 +1,5 @@ XEN_ROOT = ../ XEN_ROOT = ../ +include $(XEN_ROOT)/Config.mk include $(XEN_ROOT)/tools/Rules.mk SUBDIRS-y := @@ -8,16 +9,14 @@ SUBDIRS-y += examples SUBDIRS-y += examples SUBDIRS-y += xentrace SUBDIRS-$(CONFIG_XCUTILS) += xcutils -SUBDIRS-y += firmware +SUBDIRS-$(CONFIG_FIRMWARE) += firmware SUBDIRS-y += security SUBDIRS-y += console SUBDIRS-y += xenmon SUBDIRS-y += guest-headers -SUBDIRS-$(VTPM_TOOLS) += vtpm_manager -SUBDIRS-$(VTPM_TOOLS) += vtpm +SUBDIRS-$(VTPM_TOOLS) += vtpm_manager vtpm SUBDIRS-y += xenstat -SUBDIRS-y += libaio -SUBDIRS-y += blktap +SUBDIRS-$(CONFIG_BLKTAP) += libaio blktap # These don't cross-compile ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [RFC] consolidated libdt proposal
On Tue, 2006-08-08 at 11:04 -0700, Mark A. Greer wrote: > > Except for not being able to extend a property (see below), > I think it does meet my needs (at least as I know them today). Great. > However, I was hoping to keep the interfaces in the bootwrapper > similar to the ones used in the kernel. To that end, I had a > routine to find a device node and other routines to find and modify > a property within that node. I didn't notice a "finddevice" type of > function to find a device node. Would you have a problem adding one? The way property modification works now is this: p = ft_get_prop(tree, "/xen/console/interrupts", &len); if ((NULL == p) || (len != foolen)) return; *p = cpu_to_be32(foo); (That does need to be hidden in a yet-to-be-written ft_set_prop().) If necessary, it looks like it would be possible to modify ft_get_prop() to return a pointer to the beginning of the node structure, but is it really necessary? Do you have code that would be difficult to convert to using ft_set_prop(tree, "/node/prop", buf, buflen); ? > > One limitation of the attached code is that it doesn't support changing > > the *size* of properties, though I don't think that would be too > > difficult to add if needed. > > If we're going to allow cmdline editing in the bootwrapper, we would > need to extend the size of a property. We've never really talked about > cmdline editing in the powerpc branch but I assume that its a good > thing(tm). I know I would like to have it so, IMHO, I think we should > add it (and therefore require extending a property). I agree, and it shouldn't be too much work. I'll take a look later this week, if nobody else has. -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [RFC] consolidated libdt proposal
Hi Hollis,
Attached is a modified version of ft_build.c and ft_build.h from u-boot.
-Matthew
On Mon, 2006-08-07 at 16:58 -0500, Hollis Blanchard wrote:
> On Sun, 2006-08-06 at 19:38 -0500, Hollis Blanchard wrote:
> >
> > Hmm, so we'll have at least three copies of this code: uboot, kernel,
> > and Xen. Would it make sense to put this stuff into a libdt.a?
> > Technically, dtc has a "libdt" already, but it's absurdly incomplete
> > (I don't even know why it's there), so we could just replace it.
>
> Mark, I had a look at the code Pantelis wrote for u-boot, and it was
> pretty easy to adapt to meet Xen's (userspace-based) needs. I've
> attached my version below (and see ft_setup() at the bottom of the
> file). Does it meet your requirements for the kernel bootwrapper?
>
> One limitation of the attached code is that it doesn't support changing
> the *size* of properties, though I don't think that would be too
> difficult to add if needed.
>
> Haren, what about using this in kexec-tools?
>
> If everybody can use this (I expect small modifications would be
> needed), I think we should turn it into a library in the dtc source
> tree. The various projects using it could then include snapshots (to
> avoid dependencies). In general I'd like to avoid everybody writing and
> maintaining their own version of this stuff (myself included).
>
> ___
> Linuxppc-dev mailing list
> [EMAIL PROTECTED]
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
/*
* OF flat tree builder
* Written by: Pantelis Antoniou <[EMAIL PROTECTED]>
* Updated by: Matthew McClintock <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
#include
#include
#include
#ifdef CONFIG_OF_FLAT_TREE
#include
#include
#include
#undef DEBUG
/* align addr on a size boundary - adjust address up if needed -- Cort */
#define _ALIGN(addr,size) (((addr)+(size)-1)&(~((size)-1)))
#ifndef CONFIG_OF_BOOT_CPU
#define CONFIG_OF_BOOT_CPU 0
#endif
#define SIZE_OF_RSVMAP_ENTRY (2*sizeof(u64))
static void ft_put_word(struct ft_cxt *cxt, u32 v)
{
memmove(cxt->p + sizeof(u32), cxt->p, cxt->p_end - cxt->p);
*(u32 *) cxt->p = cpu_to_be32(v);
cxt->p += sizeof(u32);
cxt->p_end += sizeof(u32);
}
static inline void ft_put_bin(struct ft_cxt *cxt, const void *data, int sz)
{
int aligned_size = ((u8 *)_ALIGN((unsigned long)cxt->p + sz,
sizeof(u32))) - cxt->p;
memmove(cxt->p + aligned_size, cxt->p, cxt->p_end - cxt->p);
/* make sure the last bytes are zeroed */
memset(cxt->p + aligned_size - (aligned_size % sizeof(u32)), 0,
(aligned_size % sizeof(u32)));
memcpy(cxt->p, data, sz);
cxt->p += aligned_size;
cxt->p_end += aligned_size;
}
void ft_begin_node(struct ft_cxt *cxt, const char *name)
{
ft_put_word(cxt, OF_DT_BEGIN_NODE);
ft_put_bin(cxt, name, strlen(name) + 1);
}
void ft_end_node(struct ft_cxt *cxt)
{
ft_put_word(cxt, OF_DT_END_NODE);
}
void ft_nop(struct ft_cxt *cxt)
{
ft_put_word(cxt, OF_DT_NOP);
}
static int lookup_string(struct ft_cxt *cxt, const char *name)
{
u8 *p;
p = cxt->p;
while (p < cxt->p_end) {
if (strcmp(p, name) == 0)
return p - cxt->p;
p += strlen(p) + 1;
}
return -1;
}
void ft_prop(struct ft_cxt *cxt, const char *name, const void *data, int sz)
{
int off = 0;
off = lookup_string(cxt, name);
if (off == -1) {
memcpy(cxt->p_end, name, strlen(name) + 1);
off = cxt->p_end - cxt->p;
cxt->p_end += strlen(name) + 2;
}
/* now put offset from beginning of *STRUCTURE* */
/* will be fixed up at the end */
ft_put_word(cxt, OF_DT_PROP);
ft_put_word(cxt, sz);
ft_put_word(cxt, off);
ft_put_bin(cxt, data, sz);
}
void ft_prop_str(struct ft_cxt *cxt, const char *name, const char *str)
{
ft_prop(cxt, name, str, strlen(str) + 1);
}
void ft_prop_int(struct ft_cxt *cxt, const char *name, int val)
{
u32 v = cpu_to_be32((u32) val);
ft_prop(cxt, name, &v, sizeof(u32));
}
/* pick up and start working on a tree in place */
void ft_init_cxt(struct ft_cxt *cxt, void *blob)
{
struct boot_param_header *bph = blob;
memset(cxt, 0, sizeof(*cxt));
cxt->bph = bph;
bph->boot_cpuid_phys = CONFIG_OF_BOOT_CPU;
/* find beginning and end of reserve map table (zeros in last entry) */
cxt->p_rsvmap = (u8 *)bph + bph->off_mem_rsvmap;
while ( ((uint64_t *)cxt->p_rsvmap)[0] != 0 &&
[XenPPC] Re: [RFC] consolidated libdt proposal
On Tue, Aug 08, 2006 at 01:25:10PM -0500, Hollis Blanchard wrote: > On Tue, 2006-08-08 at 11:04 -0700, Mark A. Greer wrote: > > > > Except for not being able to extend a property (see below), > > I think it does meet my needs (at least as I know them today). > > Great. > > > However, I was hoping to keep the interfaces in the bootwrapper > > similar to the ones used in the kernel. To that end, I had a > > routine to find a device node and other routines to find and modify > > a property within that node. I didn't notice a "finddevice" type of > > function to find a device node. Would you have a problem adding one? > > The way property modification works now is this: > p = ft_get_prop(tree, "/xen/console/interrupts", &len); > if ((NULL == p) || (len != foolen)) > return; > *p = cpu_to_be32(foo); > (That does need to be hidden in a yet-to-be-written ft_set_prop().) > > If necessary, it looks like it would be possible to modify ft_get_prop() > to return a pointer to the beginning of the node structure, but is it > really necessary? No, its just a preference to have it look similar to kernel code. > Do you have code that would be difficult to convert to > using > ft_set_prop(tree, "/node/prop", buf, buflen); > ? No. > > > One limitation of the attached code is that it doesn't support changing > > > the *size* of properties, though I don't think that would be too > > > difficult to add if needed. > > > > If we're going to allow cmdline editing in the bootwrapper, we would > > need to extend the size of a property. We've never really talked about > > cmdline editing in the powerpc branch but I assume that its a good > > thing(tm). I know I would like to have it so, IMHO, I think we should > > add it (and therefore require extending a property). > > I agree, and it shouldn't be too much work. I'll take a look later this > week, if nobody else has. OK. Mark ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] [LIBXC] add architecture-specific parameter to xc_linux_build()
(I'm not attached to the name "arch_args" in this patch.)
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 fixes in there anyways, so now would be a
good time to pull. :)
.hgignore|8
a/tools/libxc/xc_ppc_linux_build.c | 408 ---
b/tools/libxc/powerpc64/Makefile |1
b/tools/libxc/powerpc64/xc_linux_build.c | 408 +++
tools/libxc/xc_ppc_linux_build.c | 40 +--
xen/arch/powerpc/Makefile|3
xen/arch/powerpc/boot_of.c |8
xen/arch/powerpc/dom0_ops.c | 43 ++-
xen/arch/powerpc/domain.c| 29 +-
xen/arch/powerpc/of_handler/devtree.c|2
xen/arch/powerpc/powerpc64/ppc970.c |7
xen/arch/powerpc/usercopy.c |4
xen/include/asm-powerpc/processor.h |1
13 files changed, 502 insertions(+), 460 deletions(-)
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Date 1155068244 18000
# Node ID e74340460b8cac614ac71d540ca78eb11a0e917f
# Parent 375fb1f773c5ec053d63315e4d942e7d3aeb0cda
[LIBXC] add architecture-specific parameter to xc_linux_build()
On PowerPC, we will pass down the flattened device tree from Python this way.
Other architectures currently leave this unused. Should more than one
parameter be needed in the future, the address of an architecture-specific
structure can be passed instead (i.e. we won't need to add more parameters to
the prototype).
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
diff -r 375fb1f773c5 -r e74340460b8c tools/libxc/powerpc64/xc_linux_build.c
--- a/tools/libxc/powerpc64/xc_linux_build.cTue Aug 08 15:11:25 2006 -0500
+++ b/tools/libxc/powerpc64/xc_linux_build.cTue Aug 08 15:17:24 2006 -0500
@@ -352,7 +352,8 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn)
+ unsigned long *console_mfn,
+ void *devtree)
{
struct domain_setup_info dsi;
xen_pfn_t *page_array = NULL;
diff -r 375fb1f773c5 -r e74340460b8c tools/libxc/xc_linux_build.c
--- a/tools/libxc/xc_linux_build.c Tue Aug 08 15:11:25 2006 -0500
+++ b/tools/libxc/xc_linux_build.c Tue Aug 08 15:17:24 2006 -0500
@@ -1337,7 +1337,8 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn)
+ unsigned long *console_mfn,
+ void *unused)
{
char *image = NULL;
unsigned long image_size;
diff -r 375fb1f773c5 -r e74340460b8c tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.hTue Aug 08 15:11:25 2006 -0500
+++ b/tools/libxc/xenguest.hTue Aug 08 15:17:24 2006 -0500
@@ -55,7 +55,8 @@ int xc_linux_restore(int xc_handle, int
* @parm store_evtchn the store event channel for this domain to use
* @parm store_mfn returned with the mfn of the store page
* @parm console_evtchn the console event channel for this domain to use
- * @parm conole_mfn returned with the mfn of the console page
+ * @parm console_mfn returned with the mfn of the console page
+ * @parm arch_args architecture-specific data
* @return 0 on success, -1 on failure
*/
int xc_linux_build(int xc_handle,
@@ -68,7 +69,8 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn);
+ unsigned long *console_mfn,
+ void *arch_args);
/**
* This function will create a domain for a paravirtualized Linux
diff -r 375fb1f773c5 -r e74340460b8c tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c Tue Aug 08 15:11:25 2006 -0500
+++ b/tools/python/xen/lowlevel/xc/xc.c Tue Aug 08 15:17:24 2006 -0500
@@ -331,25 +331,26 @@ static PyObject *pyxc_linux_build(XcObje
int store_evtchn, console_evtchn;
unsigned long store_mfn = 0;
unsigned long console_mfn = 0;
+void *arch_args = NULL;
static char *kwd_list[] = { "dom", "store_evtchn",
"console_evtchn", "image",
/* optional */
"ramdisk", "cmdline", "flags",
-"features", "arch", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iiis|ssis", kwd_list,
+"features", "arch_args", NULL };
+
+if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iiis|ssiss",
[XenPPC] XenPPC IEEE1275 binding?
I remember seeing some mention of it, but I don't think we currently
have an IEEE1275 binding describing the contents of the /xen node. I'm
currently doing the device tree work to fill that in, and we're going to
replace the start_info struct we're currently using, so now would be a
good time.
This is what we've got at the moment (written by Jimi):
xen {
name = "xen";
start-info = <0 @START_INFO@ 0 1000>;
version = "Xen-3.0-unstable";
reg = <0 @DOMAIN_ID@ 0 0>;
domain-name = "@DOMAIN_NAME@";
console {
name = "console";
interrupts = <@CONSOLE_EVTCHN@ 0>;
};
};
start-info is going away, which means we'll need to add more properties
to replace it... something like this:
xen {
name = "xen";
version = "Xen-3.0-unstable";
reg = <0 @DOMAIN_ID@ 0 0>;
domain-name = "@DOMAIN_NAME@";
shared = <@SHARED_INFO@>;
privileged;
init-domain;
console {
name = "console";
interrupts = <@CONSOLE_EVTCHN@ 0>;
frameno = <@CONSOLE_MFN@>;
};
store {
name = "store";
interrupts = <@STORE_EVTCHN@ 0>;
frameno = <@STORE_MFN@>;
};
};
What are all the extra 0s in there? Why do we want a reg property when
we can use separate explicitly-named properties?
If we can flesh this out a little bit in email, we can start a wiki page
with the info.
--
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: [XenPPC] Fw: latest noHV patches
Hi Mark, I've put up a brief description at http://wiki.xensource.com/xenwiki/XenPPC/NoHV ; feel free to edit and expand if you like. Also, in the future please name patches (i.e. xen-nohv and linux-prlp) with a .diff extension. That makes them much easier to read in email clients and list archives; right now they're treated as binary files. (In fact I didn't realize until recently that those were actually diffs; I thought you were sending out compiled executables.) Thanks! On Tue, 2006-08-08 at 18:38 -0400, Mark F Mergen wrote: > > As requested. > > > > > - Forwarded by Mark F Mergen/Watson/IBM on 08/08/2006 06:05 PM > - > Mark F Mergen/Watson/IBM > > 08/08/2006 04:45 AM > > >To > xen-ppc-devel@lists.xensource.com >cc > > Subject > latest noHV > patches > > > > > > > > Patches for noHV are up-to-date and tested with trees from the > repository as of the date and time of this posting. I can send them > to anyone interested, but probably the only people who have interest > also have access to my tress and can get the patches there. > > The Xen patch is in /a/kix/homes/kix/mergen/xen/xen-nohv/xen-nohv. > The Linux patch is > in /a/kix/homes/kix/mergen/xen/linux/linux-2.6.prlp/linux-prlp. For > Xen you also need the two new files nohv.c and nohv.h which are > in /a/kix/homes/kix/mergen. They need to be placed in your tree in > your analogue of xen/xen-nohv/xen/arch/powerpc/powerpc64/nohv.c and > xen/xen-nohv/xen/include/asm-powerpc/nohv.h. > > Mark Mergen > ___ > 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
[XenPPC] [xenppc-unstable] [LIBXC] move xc_ppc_linux_build.c into a powerpc64 directory
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Node ID 2e0bd1bcc30bddd9db2cb4eb9808db594ecb13e2
# Parent 44dd4a836bfc9fa5ce142d3c39c717c8d6a759ad
[LIBXC] move xc_ppc_linux_build.c into a powerpc64 directory
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
---
tools/libxc/xc_ppc_linux_build.c | 408 -
tools/libxc/powerpc64/Makefile |1
tools/libxc/powerpc64/xc_linux_build.c | 408 +
3 files changed, 409 insertions(+), 408 deletions(-)
diff -r 44dd4a836bfc -r 2e0bd1bcc30b tools/libxc/powerpc64/Makefile
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/tools/libxc/powerpc64/MakefileTue Aug 08 15:11:25 2006 -0500
@@ -0,0 +1,1 @@
+CTRL_SRCS-y += powerpc64/xc_linux_build.c
diff -r 44dd4a836bfc -r 2e0bd1bcc30b tools/libxc/powerpc64/xc_linux_build.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/tools/libxc/powerpc64/xc_linux_build.cTue Aug 08 15:11:25 2006 -0500
@@ -0,0 +1,408 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) IBM Corporation 2006
+ *
+ * Authors: Hollis Blanchard <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+/* XXX 64M hack */
+#define MEMSIZE (64UL << 20)
+#define INITRD_ADDR (24UL << 20)
+
+#define ALIGN_UP(addr,size) (((addr)+((size)-1))&(~((size)-1)))
+
+#define max(x,y) ({ \
+const typeof(x) _x = (x); \
+const typeof(y) _y = (y); \
+(void) (&_x == &_y);\
+_x > _y ? _x : _y; })
+
+static void *load_file(const char *path, unsigned long *filesize)
+{
+void *img;
+ssize_t size;
+int fd;
+
+DPRINTF("load_file(%s)\n", path);
+
+fd = open(path, O_RDONLY);
+if (fd < 0) {
+perror(path);
+return NULL;
+}
+
+size = lseek(fd, 0, SEEK_END);
+if (size < 0) {
+perror(path);
+close(fd);
+return NULL;
+}
+lseek(fd, 0, SEEK_SET);
+
+img = malloc(size);
+if (img == NULL) {
+perror(path);
+close(fd);
+return NULL;
+}
+
+size = read(fd, img, size);
+if (size <= 0) {
+perror(path);
+close(fd);
+free(img);
+return NULL;
+}
+
+if (filesize)
+*filesize = size;
+close(fd);
+return img;
+}
+
+static int init_boot_vcpu(
+int xc_handle,
+int domid,
+struct domain_setup_info *dsi,
+unsigned long dtb,
+unsigned long kaddr)
+{
+vcpu_guest_context_t ctxt;
+int rc;
+
+memset(&ctxt.user_regs, 0x55, sizeof(ctxt.user_regs));
+ctxt.user_regs.pc = dsi->v_kernentry;
+ctxt.user_regs.msr = 0;
+ctxt.user_regs.gprs[1] = 0; /* Linux uses its own stack */
+ctxt.user_regs.gprs[3] = dtb;
+ctxt.user_regs.gprs[4] = kaddr;
+ctxt.user_regs.gprs[5] = 0;
+/* There is a buggy kernel that does not zero the "local_paca", so
+ * we must make sure this register is 0 */
+ctxt.user_regs.gprs[13] = 0;
+
+DPRINTF("xc_vcpu_setvcpucontext:\n"
+ " pc 0x%"PRIx64", msr 0x016%"PRIx64"\n"
+ " r1-5 %016"PRIx64" %016"PRIx64" %016"PRIx64" %016"PRIx64
+ " %016"PRIx64"\n",
+ ctxt.user_regs.pc, ctxt.user_regs.msr,
+ ctxt.user_regs.gprs[1],
+ ctxt.user_regs.gprs[2],
+ ctxt.user_regs.gprs[3],
+ ctxt.user_regs.gprs[4],
+ ctxt.user_regs.gprs[5]);
+rc = xc_vcpu_setcontext(xc_handle, domid, 0, &ctxt);
+if (rc < 0)
+perror("setdomaininfo");
+
+return rc;
+}
+
+static int install_image(
+int xc_handle,
+int domid,
+xen_pfn_t *page_array,
+void *image,
+unsigned long paddr,
+unsigned long size)
+{
+uint8_t *img = image;
+int i;
+int rc = 0;
+
+if (paddr & ~PAGE_MASK) {
+printf("*** unaligned address\n");
+return -1;
+}
+
+for (i = 0; i < size; i += PAGE_SIZE) {
+void *page = img + i;
+xen_pfn_t pfn = (paddr + i) >> PAGE_SHIFT;
+xen_pfn_t mfn = page_array[pfn];
+
+rc = xc_copy_to_domain_page(xc_handle, domid, mfn, page);
+if (rc < 0) {
+
[XenPPC] [xenppc-unstable] [LIBXC] remove relocated file from Makefile
# HG changeset patch # User Hollis Blanchard <[EMAIL PROTECTED]> # Node ID aed85530f3c224821ff3f2b8e4631e56a754729a # Parent c4cd9562b52dc488602025b937c46d154ff4e76d [LIBXC] remove relocated file from Makefile Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]> --- tools/libxc/Makefile |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -r c4cd9562b52d -r aed85530f3c2 tools/libxc/Makefile --- a/tools/libxc/Makefile Tue Aug 08 18:30:11 2006 -0500 +++ b/tools/libxc/Makefile Tue Aug 08 18:37:46 2006 -0500 @@ -29,7 +29,6 @@ GUEST_SRCS-y += xc_load_bin.c GUEST_SRCS-y += xc_load_bin.c GUEST_SRCS-y += xc_load_elf.c GUEST_SRCS-y += xg_private.c -GUEST_SRCS-$(CONFIG_POWERPC) += xc_ppc_linux_build.c GUEST_SRCS-$(CONFIG_X86) += xc_linux_build.c GUEST_SRCS-$(CONFIG_IA64) += xc_linux_build.c GUEST_SRCS-$(CONFIG_MIGRATE) += xc_linux_restore.c xc_linux_save.c @@ -140,3 +139,4 @@ libxenguest.so.$(MAJOR).$(MINOR): $(GUES $(CC) $(CFLAGS) $(LDFLAGS) -Wl,-soname -Wl,libxenguest.so.$(MAJOR) -shared -o $@ $^ -lz -lxenctrl -include $(DEPS) + ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [LIBXC] clean specified files instead of wildcarding
# HG changeset patch # User Hollis Blanchard <[EMAIL PROTECTED]> # Node ID fbf4e91468b00b4343e35ac899fd55c1099dd328 # Parent aed85530f3c224821ff3f2b8e4631e56a754729a [LIBXC] clean specified files instead of wildcarding Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]> --- tools/libxc/Makefile |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff -r aed85530f3c2 -r fbf4e91468b0 tools/libxc/Makefile --- a/tools/libxc/Makefile Tue Aug 08 18:37:46 2006 -0500 +++ b/tools/libxc/Makefile Tue Aug 08 18:54:01 2006 -0500 @@ -99,8 +99,9 @@ TAGS: .PHONY: clean clean: - rm -rf *.a *.so* *.o *.opic *.rpm $(LIB) *~ $(DEPS) xen - rm -rf ia64/*.o ia64/*.opic + rm -rf *.rpm $(LIB) *~ $(DEPS) xen \ +$(CTRL_LIB_OBJS) $(CTRL_PIC_OBJS) \ +$(GUEST_LIB_OBJS) $(GUEST_PIC_OBJS) .PHONY: rpm rpm: build ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [LIBXC] put PowerPC loader in libxenguest, not libxenctrl
# HG changeset patch # User Hollis Blanchard <[EMAIL PROTECTED]> # Node ID f543ea6411bd3f75462001f18b951b145c39e8d4 # Parent fbf4e91468b00b4343e35ac899fd55c1099dd328 [LIBXC] put PowerPC loader in libxenguest, not libxenctrl Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]> --- tools/libxc/powerpc64/Makefile |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -r fbf4e91468b0 -r f543ea6411bd tools/libxc/powerpc64/Makefile --- a/tools/libxc/powerpc64/MakefileTue Aug 08 18:54:01 2006 -0500 +++ b/tools/libxc/powerpc64/MakefileTue Aug 08 19:07:32 2006 -0500 @@ -1,1 +1,1 @@ CTRL_SRCS-y += powerpc64/xc_linux_build. -CTRL_SRCS-y += powerpc64/xc_linux_build.c +GUEST_SRCS-y += powerpc64/xc_linux_build.c ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] XenPPC IEEE1275 binding?
On Aug 8, 2006, at 6:42 PM, Hollis Blanchard wrote:
I remember seeing some mention of it, but I don't think we currently
have an IEEE1275 binding describing the contents of the /xen node.
[...]
start-info is going away, which means we'll need to add more
properties
to replace it... something like this:
xen {
name = "xen";
version = "Xen-3.0-unstable";
Should we have a "compatible" that domain can compare against?
reg = <0 @DOMAIN_ID@ 0 0>;
This could certainly be "domain-id" and be one cell.
I used "reg" because I mistakenly thought is was a mandatory property
and we needed a "unit-id" which makes no sense as you point out below.
It is 2x2 cells because:
/#address-cells: 2
/#size-cells: 2
and they dictate the size of the unit-address.
domain-name = "@DOMAIN_NAME@";
shared = <@SHARED_INFO@>;
This, console and store, and all addresses should be expressed in
bytes and are domain-physical not MFNs so we should label them
correctly. They also need to match /#address-cells and should prolly
have a size.
privileged;
init-domain;
console {
name = "console";
interrupts = <@CONSOLE_EVTCHN@ 0>;
FYI, the second zero here denotes a sense code of 0 indicating
positive edge triggered interrupt
frameno = <@CONSOLE_MFN@>;
Perhaps this should be a "unit address" and be a reg property, that
actually makes sense.
};
store {
name = "store";
interrupts = <@STORE_EVTCHN@ 0>;
frameno = <@STORE_MFN@>;
this could be a "reg"/"unit address" as well.
};
};
What are all the extra 0s in there? Why do we want a reg property when
we can use separate explicitly-named properties?
see above.
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [RFC] consolidated libdt proposal
Pantelis Antoniou wrote: On 08 Αυγ 2006, at 8:37 ΠΜ, Haren Myneni wrote: Hollis Blanchard wrote: On Sun, 2006-08-06 at 19:38 -0500, Hollis Blanchard wrote: Hmm, so we'll have at least three copies of this code: uboot, kernel, and Xen. Would it make sense to put this stuff into a libdt.a? Technically, dtc has a "libdt" already, but it's absurdly incomplete (I don't even know why it's there), so we could just replace it. Mark, I had a look at the code Pantelis wrote for u-boot, and it was pretty easy to adapt to meet Xen's (userspace-based) needs. I've attached my version below (and see ft_setup() at the bottom of the file). Does it meet your requirements for the kernel bootwrapper? One limitation of the attached code is that it doesn't support changing the *size* of properties, though I don't think that would be too difficult to add if needed. Haren, what about using this in kexec-tools? Hollis, Good idea to have this lib. Based on brief look, some of these funcs are also useful for kexec-tools. Yes, as you mentioned, changing the size of properties is important for kexec/kdump. Present flattened device-tree process in kexec-tools: - Kexec-tool reads the /proc/device-tree and sort these entries since we get the different order than the first kernel uses. - creates linux,usable-memory property under /proc/device-tree/ [EMAIL PROTECTED] as appropriate. (for kdump) - Modify the reserve map for RTAS, initrd, TCE and (0- crashkernel- start) - Create initrd properties if not exist in the first kernel as needed - Modify bootargs property Thanks Haren Hi Haren, Mind writing down what your requirements are? Just modifying the size of the properties? Pantelis, Yes, kexec-tool can use the proposed interfaces. kexec-tool requirements: creating the flattened device-tree from scratch based on the first kernel /proc/device-tree While doing this process, should be able to - add new properties (Ex: linux,usable-memory property under /proc/device-tree/[EMAIL PROTECTED]) - Modify properties: size and the value of the property could be changed(Ex: bootargs, not an issue since creating new anyway) Thanks Haren Note that my functions work in a two phases. In the first phase the tree is build with the string table being put at the end of the allocated memory area in a downward motion. When the tree is finalized the string table is memmov'ed to be adjacent to the structure proper. Could you use this two phased approach for you uses? I.e. first work with maximum sized properties and perform a move & fixup stage when finalizing? Regards Pantelis If everybody can use this (I expect small modifications would be needed), I think we should turn it into a library in the dtc source tree. The various projects using it could then include snapshots (to avoid dependencies). In general I'd like to avoid everybody writing and maintaining their own version of this stuff (myself included). - --- / ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [hack] dynamic device tree generation
I just got dynamic device tree stuff working. I mean, it's full of
hacks, but should be enough to get an initrd (which is why I'm posting
it). Patch is below (I'm not even going to check it in to
xenppc-unstable.hg it's so bad).
With it, I get this console output:
xen_start_info at c3ffc000
magic xen-3.0-powerpc64HV
flags 0
shared_info3fff000, c3fff000
store_mfn 3ffe
store_evtchn 1
console_mfn3ffd
console_evtchn 2
Hello World I'm Maple Xen-LPAR!
<- xen_init_early
firmware_features = 0x4a
Using Xen-Maple machine description
...
However, despite many many reinstallations of the tools, my output still
ceases after about a pageful. strace on xenconsoled reveals:
Process 1149 attached - interrupt to quit
*** here I hit "enter" in the "xm console" ***
select(20, [16 18 19], [], NULL, NULL) = 1 (in [19])
read(19, "\r", 80) = 1
mlock(0xffcfa7c0, 136) = 0
ioctl(5, SNDCTL_DSP_RESET, 0xffcfa760) = 0
munlock(0xffcfa7c0, 136)= 0
ioctl(18, EVIOCGKEYCODE or EVIOCSKEYCODE, 0xffcfa8b8) = 0
select(20, [16 18 19], [], NULL, NULL) = 1 (in [18])
read(18, "\0\0\0\n", 4) = 4
write(18, "\0\0\0\n", 4)= 4
select(20, [16 18 19], [], NULL, NULL
Maybe it's not an event channel problem after all, but rather a console
selection problem. Anyways.
diff -r da6be38bfdb1 tools/libxc/powerpc64/Makefile
--- a/tools/libxc/powerpc64/MakefileTue Aug 08 20:57:09 2006 -0500
+++ b/tools/libxc/powerpc64/MakefileTue Aug 08 20:57:24 2006 -0500
@@ -1,1 +1,2 @@ GUEST_SRCS-y += powerpc64/xc_linux_build
GUEST_SRCS-y += powerpc64/xc_linux_build.c
+GUEST_SRCS-y += powerpc64/ft_build.c
diff -r da6be38bfdb1 tools/libxc/powerpc64/xc_linux_build.c
--- a/tools/libxc/powerpc64/xc_linux_build.cTue Aug 08 20:57:09 2006 -0500
+++ b/tools/libxc/powerpc64/xc_linux_build.cTue Aug 08 23:12:20 2006 -0500
@@ -33,9 +33,10 @@
#include
#include
-/* XXX 64M hack */
-#define MEMSIZE (64UL << 20)
+#include "ft_build.h"
+
#define INITRD_ADDR (24UL << 20)
+#define DEVTREE_ADDR (16UL << 20)
#define ALIGN_UP(addr,size) (((addr)+((size)-1))&(~((size)-1)))
@@ -92,8 +93,8 @@ static int init_boot_vcpu(
int xc_handle,
int domid,
struct domain_setup_info *dsi,
-unsigned long dtb,
-unsigned long kaddr)
+unsigned long devtree_addr,
+unsigned long kern_addr)
{
vcpu_guest_context_t ctxt;
int rc;
@@ -102,8 +103,8 @@ static int init_boot_vcpu(
ctxt.user_regs.pc = dsi->v_kernentry;
ctxt.user_regs.msr = 0;
ctxt.user_regs.gprs[1] = 0; /* Linux uses its own stack */
-ctxt.user_regs.gprs[3] = dtb;
-ctxt.user_regs.gprs[4] = kaddr;
+ctxt.user_regs.gprs[3] = devtree_addr;
+ctxt.user_regs.gprs[4] = kern_addr;
ctxt.user_regs.gprs[5] = 0;
/* There is a buggy kernel that does not zero the "local_paca", so
* we must make sure this register is 0 */
@@ -157,30 +158,85 @@ static int install_image(
return rc;
}
-/* XXX be more flexible about placement in memory */
-static int load_dtb(
+static int load_devtree(
int xc_handle,
int domid,
-const char *dtb_path,
-unsigned long dtb_addr,
-struct domain_setup_info *dsi,
-xen_pfn_t *page_array)
-{
-uint8_t *img;
-unsigned long dtb_size;
+xen_pfn_t *page_array,
+void *devtree,
+unsigned long devtree_addr,
+unsigned long initrd_base,
+unsigned long initrd_len,
+start_info_t *si,
+unsigned long si_addr)
+{
+uint32_t start_info[4] = {0, si_addr, 0, 0x1000};
+struct boot_param_header *header;
+uint64_t *prop;
+unsigned int devtree_size;
+unsigned int proplen;
int rc = 0;
-img = load_file(dtb_path, &dtb_size);
-if (img == NULL) {
-rc = -1;
-goto out;
-}
-
-DPRINTF("copying device tree to 0x%lx[0x%lx]\n", dtb_addr, dtb_size);
-rc = install_image(xc_handle, domid, page_array, img, dtb_addr, dtb_size);
-
-out:
-free(img);
+header = devtree;
+devtree_size = header->totalsize;
+
+DPRINTF("adding initrd props\n");
+prop = ft_get_prop(devtree, "/chosen/linux,initrd-start", &proplen);
+if ((prop == NULL) || (proplen != sizeof(*prop))) {
+DPRINTF("couldn't set linux,initrd-start property\n");
+return -1;
+}
+*prop = initrd_base;
+
+prop = ft_get_prop(devtree, "/chosen/linux,initrd-end", &proplen);
+if ((prop == NULL) || (proplen != sizeof(*prop))) {
+DPRINTF("couldn't set linux,initrd-end property\n");
+return -1;
+}
+*prop = initrd_base + initrd_len;
+
+#if 0
+prop = ft_get_prop(devtree, "/xen/console/frameno", &proplen);
+if ((prop == NULL) || (proplen != sizeof(*prop))) {
+DPRINTF("couldn't set /xen/console/frameno property\n");
+return -1;
+}
+*prop = si->console_mfn;
+
+prop = ft_get_prop(devtree, "/xen/console/interrupts", &proplen);
+if
[XenPPC] Re: [Xen-devel] [PATCH] [LIBXC] add architecture-specific parameter to xc_linux_build()
On Tue, 2006-08-08 at 15:28 -0500, Hollis Blanchard wrote:
> diff -r 375fb1f773c5 -r e74340460b8c tools/python/xen/lowlevel/xc/xc.c
> --- a/tools/python/xen/lowlevel/xc/xc.c Tue Aug 08 15:11:25 2006 -0500
> +++ b/tools/python/xen/lowlevel/xc/xc.c Tue Aug 08 15:17:24 2006 -0500
> @@ -331,25 +331,26 @@ static PyObject *pyxc_linux_build(XcObje
> int store_evtchn, console_evtchn;
> unsigned long store_mfn = 0;
> unsigned long console_mfn = 0;
> +void *arch_args = NULL;
>
> static char *kwd_list[] = { "dom", "store_evtchn",
> "console_evtchn", "image",
> /* optional */
> "ramdisk", "cmdline", "flags",
> -"features", "arch", NULL };
> -
> -if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iiis|ssis", kwd_list,
> +"features", "arch_args", NULL };
> +
> +if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iiis|ssiss", kwd_list,
The one complication is that PPC's data structure has NULL characters in
it, which the "s" conversion char doesn't like. Instead you must use
"s#" to get the length as well, except I think it's ok to leave it up to
the architecture to handle the length itself (after all, even an int
that has a NULL byte trips this problem). So here is the updated patch.
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Date 1155068244 18000
# Node ID e74340460b8cac614ac71d540ca78eb11a0e917f
# Parent 375fb1f773c5ec053d63315e4d942e7d3aeb0cda
[LIBXC] add architecture-specific parameter to xc_linux_build()
On PowerPC, we will pass down the flattened device tree from Python this way.
Other architectures currently leave this unused. Should more than one
parameter be needed in the future, the address of an architecture-specific
structure can be passed instead (i.e. we won't need to add more parameters to
the prototype).
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
diff -r 375fb1f773c5 -r e74340460b8c tools/libxc/powerpc64/xc_linux_build.c
--- a/tools/libxc/powerpc64/xc_linux_build.cTue Aug 08 15:11:25 2006 -0500
+++ b/tools/libxc/powerpc64/xc_linux_build.cTue Aug 08 15:17:24 2006 -0500
@@ -352,7 +352,8 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn)
+ unsigned long *console_mfn,
+ void *devtree)
{
struct domain_setup_info dsi;
xen_pfn_t *page_array = NULL;
diff -r 375fb1f773c5 -r e74340460b8c tools/libxc/xc_linux_build.c
--- a/tools/libxc/xc_linux_build.c Tue Aug 08 15:11:25 2006 -0500
+++ b/tools/libxc/xc_linux_build.c Tue Aug 08 15:17:24 2006 -0500
@@ -1337,7 +1337,8 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn)
+ unsigned long *console_mfn,
+ void *unused)
{
char *image = NULL;
unsigned long image_size;
diff -r 375fb1f773c5 -r e74340460b8c tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.hTue Aug 08 15:11:25 2006 -0500
+++ b/tools/libxc/xenguest.hTue Aug 08 15:17:24 2006 -0500
@@ -55,7 +55,8 @@ int xc_linux_restore(int xc_handle, int
* @parm store_evtchn the store event channel for this domain to use
* @parm store_mfn returned with the mfn of the store page
* @parm console_evtchn the console event channel for this domain to use
- * @parm conole_mfn returned with the mfn of the console page
+ * @parm console_mfn returned with the mfn of the console page
+ * @parm arch_args architecture-specific data
* @return 0 on success, -1 on failure
*/
int xc_linux_build(int xc_handle,
@@ -68,7 +69,8 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn);
+ unsigned long *console_mfn,
+ void *arch_args);
/**
* This function will create a domain for a paravirtualized Linux
--- tools/python/xen/lowlevel/xc/xc.c.orig 2006-08-08 23:36:31.0
-0500
+++ tools/python/xen/lowlevel/xc/xc.c 2006-08-08 23:36:34.0 -0500
@@ -331,25 +331,27 @@
int store_evtchn, console_evtchn;
unsigned long store_mfn = 0;
unsigned long console_mfn = 0;
+void *arch_args = NULL;
+int unused;
static char *kwd_list[] = { "dom", "store_evtchn",
"console_evtchn", "image",
/* optional */
"ramdisk", "cmdline", "flags",
-"features", NULL };
+
