similar to: memsize for HVM save/restore

[PATCH 6/8] HVM save restore: guest memory handling Signed-off-by: Zhai Edwin <edwin.zhai@intel.com> add support for save/restore HVM guest memory diff -r bb1c450b2739 tools/libxc/xc_hvm_restore.c --- a/tools/libxc/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>

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

The following dump-core patches changes its format into ELF, adds PFN-GMFN table, HVM support, and adds experimental IA64 support. - ELF format Program header and note section are adopted. - HVM domain support To know the memory area to dump, XENMEM_set_memory_map is added. XENMEM_memory_map hypercall is for current domain, so new one is created. and hvm domain builder tell xen its

Hi,all I have tried to passthrough GPU card(Nvidia quadro 4000) on the latest Xen unstable version (QEMU is using Qemu-upsteam-unstable, not traditional Qemu). This issue as below: Windows7 64-bit guest will blue screen when GPU passthrough configure 4g memory,blue screen code is 50, and SUSE 11 64-bit guest will always stay at the grub screen. I noticed that it will relocate RAM that

This patch adds a check to see if v_end in setup_guest() wraps around to 0 and lets the builder exit gracefully when it does. Signed-off-by: Aravindh Puthiyaparambil <aravindh.puthiyaparambil@unisys.com> > -----Original Message----- > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: Thursday, June 01, 2006 6:14 AM > To: Puthiyaparambil, Aravindh > Cc:

Keir, Here''s a first patch to address the issue with rolling over to guest-physical address 0x00000000 when assigning address regions to PCI BARs during HVM boot. For now, this: - Makes the hole bigger: 0xC0000000-0xF5000000. This might be overkill...but it should only matter for 32-bit guest OSes assigned more than 3GB of RAM. - Prevents addresses from above 0xF50000000 from

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.

Good Afternoon, I have the following code, but it seems that something must be doing wrong, because it is giving the results I want. The idea is to create segments while the value of Commutation is less than 1000. for example, from the small set of data below text=" val_user pos v v_star v_end commutation v_source v_destine 1 1 96-96 1173438391 1173438391 0

Where is the code that maps the kernel of a DomU into memory? i.e, when you do a xm create <config file> what code is called to actually map the kernel into memory? Is it a python script or is it re-directed to Dom0 to do? Thanks. -Brian --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.

Where is the code that maps the kernel of a DomU into memory? i.e, when you do a xm create <config file> what code is called to actually map the kernel into memory? Is it a python script or is it re-directed to Dom0 to do? Thanks. -Brian --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.

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

Good Afternoon, ?? I have a small problem with the following code. # The x.sub$Time[[1]] 2006-10-31 19:03:01 EST # when put in variable star give-me star<-x.sub$Time[[1]] print(star) print(x.sub$Time[[1]]) [1] 1 36 32 -........ do not understand why -- View this message in context: http://r.789695.n4.nabble.com/problem-with-data-tp4453510p4453510.html Sent from the R help mailing

This patch series adds the ability to selectively disable the S3 and S4 ACPI power states for HVM guests. Since there is a general move towards retiring the hvm_info_table structure, the first patch moves the acpi_enabled flag out of the hvm_info_table and into a xenstore key (platform/acpi). The second patch then introduces the acpi_s3 and acpi_s4 configuration parameters to the xl config file

The memory permutation cause a slow down in case of a save/restore (bug 1143). It works better when the mixing is done with 2MB chunks. Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi all, I have some puzzle about hvmloader in the path /tools/firmware/, they are: 1: Is hvmloader running in non-root mode? 2: If hvmloader runs in non-root mode, does it have its pagetable? when set GUEST_CR3 in vmcs? 3: How can I find the value of GUEST_RIP in vmcs is set to the entry point of hvmloader,when virtual machine do it first vm entry. Much Thanks! - henanwxr

This patch introduces support for two new parameters in libxl: smbios_firmware=<path_to_smbios_structures_file> acpi_firmware=<path_to_acpi_tables_file> The changes are primarily in the domain building code where the firmware files are read and passed to libxc for loading into the new guest. After the domain building call to libxc, the addresses for the loaded blobs are returned and

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

I?ve got a 512M machine and a 330M ( uncompressed ) initrd image. How can I mount the ramdisk? Normal booting seems to want to copy the entire initrd image into a Ramdisk, thus requiring 2X the memory. So what happens is the kernel boots correctly and I get, RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 330000 blocks [ 1 disk ] into ram disk And then I never see the light of day after

I?ve got a 512M machine and a 330M ( uncompressed ) initrd image. How can I mount the ramdisk? Normal booting seems to want to copy the entire initrd image into a Ramdisk, thus requiring 2X the memory. So what happens is the kernel boots correctly and I get, RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 330000 blocks [ 1 disk ] into ram disk And then I never see the light of day after

Argon2 is the default LUKS Password-Based Key Derivation Function (PBKDF) for some new guests such as RHEL 8.2 and Fedora. It is designed to be "memory hard", meaning that by design it requires large amounts of memory, making it expensive to brute-force. Unfortunately the default for guests which had more than a few GB of RAM at install time is to require about 1 GB of RAM to decrypt