similar to: doubt on phys_to_machine_mapping

Hi, At x86_64 linux domain, phys_to_machine_mapping, pfn_to_mfn_frame_list_list, and pfn_to_mfn_frame_list should be aligned to pagesize, but it can be misaligned now. If they aren''t aligned to pagesize, it will cause fails while saving the domain. This patch fixed it. regards, Signed-off-by: Kazuo Moriwaka <moriwaka@valinux.co.jp> set phys_to_machine_mapping alignment to

Isn''t the writeable page table support intended only for non-translated domains? If so, shouldn''t fixup_page_fault() check for this, or the setting of the assist bit and the PG_translate be respectively validated? If not, aren''t there bits missing in ptwr_do_page_fault()? Jan _______________________________________________ Xen-devel mailing list

... rather than having a C and an assembly one. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/include/asm-x86/config.h +++ b/xen/include/asm-x86/config.h @@ -112,19 +112,14 @@ extern unsigned char boot_edid_info[128] #define CONFIG_COMPAT 1 +#include <xen/const.h> + #define PML4_ENTRY_BITS 39 -#ifndef __ASSEMBLY__ -#define PML4_ENTRY_BYTES (1UL <<

With all of Xen''s symbols sitting within a 2Gb range on x86-64, they can be referred to by the kallsyms-like offset table using 4- instead of 8-byte slots. The marker table can use 4-byte slots in all cases, just like the table entry counts can (though that''s only a minor improvement). If ia64''s PERCPU_ADDR got moved down to (KERNEL_START + 2Gb - PERCPU_PAGE_SIZE), it

Attached patch makes the balloon driver arch-neutral (compiles on ia64... look ma, no #ifdef''s!). Please apply to xen-unstable. One change should be eyeballed, line 257 in balloon.c, because phys_to_machine_mapping[pfn] is not identical to pfn_to_mfn (different by sign bit, should be OK?) Signed-off by: Dan Magenheimer <dan.magenheimer@hp.com> diff -r 0255f48b757f

Hi, I am trying to release domU pages from page_list and xenpage_list after domU shutdown while retaining the rest of the domain information. To achieve this in __domain_finalise_shutdown i call domain_relinquish_resources. This is failing to release pages from page_list for type PGT_l2_page_tables and crashing dom0. To be specific, while testing on mini-os i saw that when

minios: support COW for a zero page Permits to support sparse data. Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r 27ad7ed41be2 extras/mini-os/arch/x86/mm.c --- a/extras/mini-os/arch/x86/mm.c Fri Jan 18 15:55:13 2008 +0000 +++ b/extras/mini-os/arch/x86/mm.c Fri Jan 18 16:02:32 2008 +0000 @@ -50,6 +50,7 @@ #endif unsigned long *phys_to_machine_mapping; +unsigned

Hi all, When i do ''xm dmesg'' the last statement says "*** Serial input -> DOM0 (type ''CTRL-a'' three times to switch input to Xen)" (i have no clue what''s that supposed to mean??) But when i press ctrl-a three times at the serial console, nothing happens. Iam using minicom to connect to the serial port of xen machine. Once xen

Hi, In many places xen uses "unsigned long" instead of the l*_pgentry_t types to pass around page table entries. Here is a patch which fixes this in a number of places (mostly in shadow mode code). Thats what I''ve trapped in so far, maybe more of these patches follow. Fixing this is needed for adding PAE support to xen. In PAE paging mode the page table entries are 64 bit

Hi, I hope I''m right here. If not then please point me in the right direction. My problem in short: I have problems using (pinning, mmu_update) physical pages from 0x900000 to 0xB1000 usualy. I''m writing my own little amd64 64bit toy kernel (based on Mini-OS as starting point) for xen and I run into problems with the way the start of day sets up the physical pages. My kernel

Checking that multi-page allocations are permitted is unnecessary for PoD population operations. Instead, the (loop invariant) check added for addressing XSA-31 can be moved here. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -99,7 +99,8 @@ static void populate_physmap(struct memo

hi, I am wondering if anybody is doing Xen or Dom0 debugging with gdb here. If yes, could you show me the procedure of doing that? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven''t the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

In dispatch_rw_block_io after a call to HYPERVISOR_grant_table_op, there is the following code which calls fast_flush_area and breaks out of the loop early if one of the handles returned from HYPERVISOR_grant_table_op is negative: for (i = 0; i < nseg; i++) { if (unlikely(map[i].handle < 0)) { DPRINTK("invalid buffer -- could not remap it\n"); fast_flush_area(pending_idx,

With the lake of iommu, dom0 must have a 1:1 memory mapping for all these guest physical address. When the ballon decides to give back a page to the kernel, this page must have the same address as previously. Otherwise, we will loose the 1:1 mapping and will break DMA-capable device. Signed-off-by: Julien Grall <julien.grall@linaro.org> CC: Keir Fraser <keir@xen.org> CC: Jan Beulich

When compiling a 2.6.10-xen0 kernel I get the following error: CC drivers/xen/balloon/balloon.o drivers/xen/balloon/balloon.c: In function `balloon_process'': drivers/xen/balloon/balloon.c:209: error: `phys_to_machine_mapping'' undeclared (first use in this function) drivers/xen/balloon/balloon.c:209: error: (Each undeclared identifier is reported only once

Hi Folks, I want to do the guest physical address (GPA) to host physical address (HPA) conversion for a VT domain in the VT domains itself. So essentially I would like to access the phys_to_machine_mapping table in the V domain. does a VT domain already have access to this table? if not, how can I do this address conversion inside the VT domain? Thanks, Sanjay -- ---------------------- PhD

Hi, I am using centos4 and am trying to build a source kernel dom0 with xen. I cloned a copy of the xen repository and did the following hg clone http://xenbits.xensource.com/xen-2.0.hg cd xen-2.0.hg/xen make dist cd linux-2.6.11-xen0 make ARCH=xen oldconfig make modules make modules_install make install After which point I get the following error : CC drivers/xen/balloon/balloon.o

Xen is compiled with no -O gcc option, meaning no optimization, and the compiler does the safest thing imaginable. This means that if a function, say vmx_world_save(), calls the same inline a bazillion times, the stack will have one block of local variables for each invocation of that function! Xen really should not be doing this. We could either uninline some of these functions, or try gcc -O2

Extend the VMX intercept mechanism to include mmio as well as portio. Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com> Signed-off-by: Xiaofeng Ling <xiaofeng.ling@intel.com> Signed-off-by: Arun Sharma <arun.sharma@intel.com> diff -r febfcd0a1a0a -r 9a43d5c12b95 xen/include/asm-x86/vmx_platform.h --- a/xen/include/asm-x86/vmx_platform.h Thu Jun 30 03:20:48 2005 +++