search for: xc_dom_image

...oot protocol requires that %esi point to the boot_params block on entry. Unfortunately this conflicts with the normal Xen boot protocol, which starts with %esi pointing to a struct start_info. In order to implement this, I've had to muck up Gerd's nice clean layering a little bit. struct xc_dom_image now has a bootparams_pfn, which is set by the bzImage loader. Then, when xc_dom_x86 sees that its non-NULL when setting up the initial vcpu state, it points %esi that rather than start_info (and the boot_params contains a pointer to start_info). Fortunately, the embedded ELF file makes it easy to...

...oot protocol requires that %esi point to the boot_params block on entry. Unfortunately this conflicts with the normal Xen boot protocol, which starts with %esi pointing to a struct start_info. In order to implement this, I've had to muck up Gerd's nice clean layering a little bit. struct xc_dom_image now has a bootparams_pfn, which is set by the bzImage loader. Then, when xc_dom_x86 sees that its non-NULL when setting up the initial vcpu state, it points %esi that rather than start_info (and the boot_params contains a pointer to start_info). Fortunately, the embedded ELF file makes it easy to...

...oot protocol requires that %esi point to the boot_params block on entry. Unfortunately this conflicts with the normal Xen boot protocol, which starts with %esi pointing to a struct start_info. In order to implement this, I've had to muck up Gerd's nice clean layering a little bit. struct xc_dom_image now has a bootparams_pfn, which is set by the bzImage loader. Then, when xc_dom_x86 sees that its non-NULL when setting up the initial vcpu state, it points %esi that rather than start_info (and the boot_params contains a pointer to start_info). Fortunately, the embedded ELF file makes it easy to...

...;samuel.thibault@eu.citrix.com> diff -r 14a9a1629590 tools/libxc/xc_dom_boot.c --- a/tools/libxc/xc_dom_boot.c wed aug 27 10:26:50 2008 +0100 +++ b/tools/libxc/xc_dom_boot.c wed aug 27 12:07:28 2008 +0100 @@ -187,7 +187,7 @@ int xc_dom_boot_image(struct xc_dom_imag int xc_dom_boot_image(struct xc_dom_image *dom) { declare_domctl; - void *ctxt; + vcpu_guest_context_any_t ctxt; int rc; xc_dom_printf("%s: called\n", __function__); @@ -245,12 +245,11 @@ int xc_dom_boot_image(struct xc_dom_imag return rc; /* let the vm run */ - ctxt = xc_dom_malloc(dom,...

I''ve addressed all (I think/hope) of the review comments. The main change is to expose the guest virtual platform (e.g. memory layout and interrupt usage etc) to the toolstack via the public interface. This is then used during FDT generation. I have just codified the current defacto standard layout, it''s probably not the best layout but any change can be a separate patch/series.

.../xc_dom_bzimageloader.c b/tools/libxc/xc_dom_bzimageloader.c index 73cfad1..c5737db 100644 --- a/tools/libxc/xc_dom_bzimageloader.c +++ b/tools/libxc/xc_dom_bzimageloader.c @@ -187,11 +187,10 @@ static int xc_try_bzip2_decode( #include <lzma.h> -static int xc_try_lzma_decode( - struct xc_dom_image *dom, void **blob, size_t *size) +static int _xc_try_lzma_decode( + struct xc_dom_image *dom, void **blob, size_t *size, + lzma_stream *stream, lzma_ret ret, const char *what) { - lzma_stream stream = LZMA_STREAM_INIT; - lzma_ret ret; lzma_action action = LZMA_RUN; unsigned c...

...xc/xenguest.h +++ b/tools/libxc/xenguest.h @@ -177,6 +177,13 @@ int xc_dom_linux_build(xc_interface *xch unsigned int console_evtchn, unsigned long *console_mfn); +#ifndef XC_HAVE_DECOMPRESS_LIMITS +#define XC_HAVE_DECOMPRESS_LIMITS +#endif + +int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz); +int xc_dom_ramdisk_max_size(struct xc_dom_image *dom, size_t sz); + /** * This function will create a domain for a paravirtualized Linux * using buffers for kernel and initrd

Biggest change is to switch the new DTB node to /xen-core-devices instead of /xen at Stefano''s request. I also dropped the few patches title HACK etc which weren''t supposed to be there and fixed up some bits and pieces which folks commented on. George, WRT the freeze I think this is functionality which we cannot ship Xen 4.4 without. The impact is entirely constrained to the

...MEM_TYPE_MALLOC_INTERNAL, >> + XC_DOM_MEM_TYPE_MALLOC_EXTERNAL, >> + XC_DOM_MEM_TYPE_MMAP, >> + } type; >> + size_t len; >> unsigned char memory[0]; >> }; >> >> @@ -298,6 +303,7 @@ void xc_dom_log_memory_footprint(struct xc_dom_image *dom); >> /* --- simple memory pool ------------------------------------------ */ >> >> void *xc_dom_malloc(struct xc_dom_image *dom, size_t size); >> +int xc_dom_register_external(struct xc_dom_image *dom, void *ptr, size_t size); >> void *xc_dom_malloc_page_...

...all@linaro.org> --- tools/libxc/xc_dom_arm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index ffe575b..366061d 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -290,6 +290,8 @@ int arch_setup_meminit(struct xc_dom_image *dom) else /* otherwise at top of RAM */ dom->devicetree_seg.vstart = ramend - dtbsize; + dom->devicetree_seg.vstart &= XC_PAGE_MASK; + dom->devicetree_seg.vend = dom->devicetree_seg.vstart + dom->devicetree_size; DOMP...

...ip %zd) looks insane, skip gunzip\n", __FUNCTION__, ziplen, unziplen); return 0; } return unziplen + 16; } The returned unziplen+16 is used for the size of the destination buffer given to inflate. But it is then also written to the kernel_size attribute of the xc_dom_image struct. Hence kernel_size does not contain the uncompressed kernel size but that /plus/ 16. So why do you always add 16 bytes to the *real* uncompressed kernel size?? That doesn''t make much sense to me but I need to know it because it is related to my current work. Thanks in advance....

...xc_dom_arm.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index a40e04d..75a6f1c 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -108,13 +108,15 @@ static int shared_info_arm(struct xc_dom_image *dom, void *ptr) static int vcpu_arm32(struct xc_dom_image *dom, void *ptr) { vcpu_guest_context_t *ctxt = ptr; + uint32_t rambase = dom->rambase_pfn << XC_PAGE_SHIFT; + uint32_t offset = dom->parms.virt_base - rambase; DOMPRINTF_CALLED(dom->xch); /* clear...

Hi, I was wondering if there is any documentation on how to write a bare metal application for Xen. I don''t need to parse the device tree and such yet, a simple booting "Hello World" would be fine :-) We wrote one and when trying to boot we get ( this was an uncompressed binary, no image): libxl: notice: libxl_numa.c:451:libxl__get_numa_candidate: NUMA placement failed,

Linux 3.11 added respective support, so I think we should follow suit. 1: xen: add LZ4 decompression support 2: libxc: add LZ4 decompression support Signed-off-by: Jan Beulich <jbeulich@suse.com>

Here are two patches that let xm create, save and restore extract and preserve elfnotes read by the domain builder. This is handy for a few things. In particular, I''d like it so that xm can decide whether or not guest domains support fast resume (if save fails, or for checkpointing). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

.... And DEFINE_XEN_GUEST_HANDLE(name) will just typedefs ''__guest_handle_name'' to be a pointer to a data type ''name '' . What is the reason for such abstraction? And how this XEN_GUEST_HANDLE different from ''guest_xc'' field of ''struct xc_dom_image'', which gets initialized with xc_handle. I have serached the net extensively for answers, but unable to get any. So any info or pointers would be highly appriciated. Thanks -Sandesh -- View this message in context: http://www.nabble.com/Use-of-XEN_GUEST_HANDLE-tp17357081p17357081.htm...

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.

On Mon, 6 May 2013, Chen Baozi wrote: > On Mar 25, 2013, at 6:00 PM, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com> wrote: > > > On Sun, 24 Mar 2013, Chen Baozi wrote: > >> Hi all, > >> > >> I''m reading Mini-OS''s codes and to estimate the amount of work porting it to > >> ARM (Ian''s GSoC idea this year). >

...32: /* 32 bit guest */ + protocol = XEN_IO_PROTO_ABI_X86_32; + break; + case 64: /* 64 bit guest */ + protocol = XEN_IO_PROTO_ABI_X86_64; + break; + default: + protocol = NULL; + } + + return protocol; +} + static unsigned long nr_page_tables(struct xc_dom_image *dom, xen_vaddr_t start, xen_vaddr_t end, unsigned long bits) diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h index 50853af..2f32151 100644 --- a/tools/libxc/xenctrl.h +++ b/tools/libxc/xenctrl.h @@ -637,6 +637,16 @@ int xc_domain_hvm_setcontext(xc_interface *xch,...

Changes from v3: - mini-os configuration files moved into stubdom/ - mini-os extra console support now a config option - Fewer #ifdefs - grant table setup uses hypercall bounce - Xenstore stub domain syslog support re-enabled Changes from v2: - configuration support added to mini-os build system - add mini-os support for conditionally compiling frontends, xenbus -