[XenPPC] Re: New domain builder in xen-unstable
Keir Fraser wrote:
On 26/1/07 5:04 pm, Hollis Blanchard [EMAIL PROTECTED] wrote:
Not sure what you mean by our own domain builder; we've been
implementing xc_linux_build() for quite a while now (and thus integrated
with xend).
Sorry, I misunderstood. I was seeing all the libelf churn, and I missed
the fact that xc_linux_build() is going away entirely (?).
I'm still not sure what you mean by our own domain builder -- there is
simply no way we're going to add more ifdefs to
tools/libxc/xc_linux_build.c (or equivalent)...
xc_linux_build() is still provided in the 'new world' and is still used by
xend. For ia64/x86 it is now a thin wrapper around Gerd's new
domain-building infrastructure. For ppc you can continue to have your very
own version under libxc/powerpc if you want to, and not use Gerd's new
domain-building infrastructure. But the elf code that you rely on is going
away, so you need to move to using libelf, which I'm sure Gerd can give you
some pointers about.
libelf is used both within the xen kernel (dom0 builder) and the tools.
Have a look at changeset 13618, this does the dom0 builder port for x86
and ia64 (build-tested only), something simliar is needed for the ppc
dom0 builder.
For the tools: You can either switch over the existing ppc builder in
libxc/powerpc/ to use libelf, which likely is simliar to the dom0
builder conversion to libelf.
The other option is to use the new builder code in libxc/xc_dom_*.c.
Some code is already there. The ia64 bits should at least compile, with
luck even work out-of-the-box. The ppc bits I didn't even compile. The
places with architecture-specific code are:
xc_dom_{ia64,powerpc}.c
setup arch-specific structs (start_info, vcpu_context).
xc_dom_boot.c
invoke the hypercalls needed to boot the domain. There are two
functions for architecture-specific code, ppc must hook in the
devtree setup there (if you decide to use the new builder).
The domain builder core code should need no changes in theory ;)
Feel free to ask if there are any questions.
HTH cheers,
Gerd
--
Gerd Hoffmann [EMAIL PROTECTED]
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Xencomm virutal Adress translation question?
On Sun, 2007-01-28 at 10:40 -0500, Jimi Xenidis wrote:
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 contiguous, so it
is tagged as inline and no separate descriptor is necessary and
therefore no allocation (or free) is required, so lets only consider
when allocation is required.
There are two methods to create this desc: (1) _map_early() and (2)
_map().
_map_early() is used when allocation occurs from the stack and the
size of data is known to be a small number (less than 4) pages, this
is helpfull for performance and in cases where the allocator is
unavailable (too early or in interrupt). The descriptor returned
from this call does not require a corresponding free().
BTW: the above paragraph makes me want to rename _map_early() to
_map_auto() or _map_stack() which in an obvious manner explains why
no free() is needed. Hollis?
I already suggested calling it _noalloc().
Now to answer your question:
In the case of _map(), if the data cannot be inlined then a single
kernel page is allocated to describe up to 511 (+-1) pages of data,
this page is known to easily be translated from kernel_virtual to
kernel_physycal using __va() and __pa() function, so there should be
no problem in using:
desc = __pa(alloc_page());
and:
free_page(__va(desc));
BTW: xencomm_pa(), 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(). The free code would need to look like this:
xencomm_free(xc) {
if is_inline(xc)
return
free_page(__va(xc))
}
--
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] Question about netbooting with initrd/initramfs
[EMAIL PROTECTED] wrote on 01/27/2007 11:02:03 PM: On Thu, Jan 25, 2007 at 04:39:39PM -0500, David M Daly wrote: I've been having some trouble netbooting linux on a JS21 with an initramfs Getting a builtin initramfs to work on PPC is tricky. The only way I have found to do it is a fragile two-stage process. Amos, thanks for the recipes. I've been able to get some initramfs functionality working using them, and I was able to netboot it. I assume that you want to build an initramfs necessary and sufficient to run xend and launch a domU, so in the following I describe one technique I want to do two things with the initramfs: 1. Run xend as you suggest 2. Boot a utility image to set some things up for a later boot (flash SLOF, configure HBA/SAN settings). This does not require xend running. I'll post a followup if I get xend working from an initramfs. Thanks again. David Daly Research Staff Member 32-003 IBM T.J. Watson Research Center Yorktown Heights, NY, 10958 (914) 945-1845, T/L 862-1845 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
