search for: max_mfn

...ibxc/xc_hvm_restore.c Thu Jan 11 21:03:11 2007 +0800 +++ b/tools/libxc/xc_hvm_restore.c Thu Jan 11 21:05:45 2007 +0800 @@ -31,6 +31,40 @@ #include <xen/hvm/ioreq.h> #include <xen/hvm/params.h> #include <xen/hvm/e820.h> + +/* max mfn of the whole machine */ +static unsigned long max_mfn; + +/* virtual starting address of the hypervisor */ +static unsigned long hvirt_start; + +/* #levels of page tables used by the currrent guest */ +static unsigned int pt_levels; + +/* total number of pages used by the current guest */ +static unsigned long max_pfn; + +/* A table mapping each PFN t...

Migrate the last TSC values for more accurate timekeeping during live migration Signed-off-by: Dave Winchell <dwinchell@virtualiron.com> Signed-off-by: Ben Guthro <bguthro@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

I got latest (13601) yesterday evening. This doesn''t seem to work to do Restore (at least of the Windows test-image that I''ve been using for testing previously). The VM restores reasonably OK, but it jumps to an invalid address shortly after restoring, giving a D1 blue-screen error (DRIVER_IRQL_LESS_OR_EQUAL), which turns out to be "page-fault in driver" after I

Last year we had a discussion[1] about how the hypercall ABI unfortunately contains fields that change width between 32- and 64-bit builds. This is a huge problem as we come up on the python management stack for ppc64, since the distributions ship 32-bit python. A 32-bit python/libxc cannot currently manage a 64-bit hypervisor. I had a patch but was unable to test it, and some other things were

...x1 libxl: debug: libxl_domain.c:520:libxl_domain_suspend: Domain 1:ao 0x56303d91b050: inprogress: poller=0x56303d91ab50, flags=i libxl-save-helper: debug: starting save: Success xc: detail: fd 13, dom 1, flags 1, hvm 0 xc: info: Saving domain 1, type x86 PV xc: detail: 64 bits, 4 levels xc: detail: max_mfn 0x1b1ffff xc: detail: p2m list from 0xffffc90000000000 to 0xffffc90000ffffff, root at 0xd9408f xc: detail: max_pfn 0x1fffff, p2m_frames 4096 xencall: error: alloc_pages: mmap failed: Invalid argument xc: error: Unable to allocate memory for dirty bitmaps, batch pfns and deferred pages: Internal err...

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

On Thu, 17 Jan 2013 22:22:47 -0500 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > Jan had some comments about that patch: > > https://patchwork.kernel.org/patch/1745041/ > > Please fix it up so I can put it in the Linux tree. Please see below. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Thanks, Mukesh diff --git a/arch/x86/xen/xen-head.S