search for: mmu_upd

...opulate_physmap_exact. > > xc_domain_populate_physmap_exact is the hypercall that should ask Xen to > > add the missing vram pages in the guest. Maybe this hypercall is failing > > in your case? > > > Hi, > > I continue to invesgate this bug and find hypercall_mmu_update in > qemu_remap_bucket(xc_map_foreign_bulk) is failing: > > do_mmu_update > ->mod_l1_entry > -> if ( !p2m_is_ram(p2mt) || unlikely(mfn == INVALID_MFN) ) > return -EINVAL; > > mfn==INVALID_MFN, because : > > mo...

...caf=80000002, taf=e8000002 (XEN) mm.c:456:d1 Could not get page ref for pfn 0 (XEN) mm.c:2225:d1 Could not get page for normal update New PT could not be mapped R/W. Now I am puzzled what these hypervisor errors mean, and what I could have done wrong? The code in question is the following: mmu_updates[0].ptr = ((pgentry_t)tab[l2_table_offset(pt_page)] & PAGE_MASK) + sizeof(pgentry_t) * l1_table_offset(pt_page); mmu_updates[0].val = ((pgentry_t)pfn_to_mfn(*pt_pfn) << PAGE_SHIFT) | _PAGE_RW | _PAGE_PRESENT; if(HYPERVISOR_mmu_update(mmu_updates, 1,...

...t; > xc_domain_populate_physmap_exact is the hypercall that should ask Xen to >> > add the missing vram pages in the guest. Maybe this hypercall is failing >> > in your case? >> >> >> Hi, >> >>    I continue to invesgate this bug and find hypercall_mmu_update in >> qemu_remap_bucket(xc_map_foreign_bulk) is failing: >> >> do_mmu_update >>       ->mod_l1_entry >>              ->  if ( !p2m_is_ram(p2mt) || unlikely(mfn == INVALID_MFN) ) >>                          return -EINVAL; >> >>    mfn==INVALI...

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native), primarily because of the ptent = ptep_get_and_clear(mm, addr, pte); ptent = pte_modify(ptent, newprot); /* ... */ set_pte_at(mm, addr, pte,

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

Hi all, [ Change since last post: change name to ptep_modify_prot_, on the grounds that it isn't really a general pte-modification interface. ] This little series adds a new transaction-like abstraction for doing RMW updates to a pte, hooks it into paravirt_ops, and then makes use of it in Xen. The basic problem is that mprotect is very slow under Xen (up to 50x slower than native),

...arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -236,7 +236,14 @@ *u = *update; } -void xen_set_pmd(pmd_t *ptr, pmd_t val) +static bool page_pinned(void *ptr) +{ + struct page *page = virt_to_page(ptr); + + return PagePinned(page); +} + +void xen_set_pmd_hyper(pmd_t *ptr, pmd_t val) { struct mmu_update u; @@ -251,6 +258,18 @@ xen_mc_issue(PARAVIRT_LAZY_MMU); preempt_enable(); +} + +void xen_set_pmd(pmd_t *ptr, pmd_t val) +{ + /* If page is not pinned, we can just update the entry + directly */ + if (!page_pinned(ptr)) { + *ptr = val; + return; + } + + xen_set_pmd_hyper(ptr, val);...

While working on a database scaling problem using a SAP database test suite we discovered that these enterprise level large shared memory databases are very heavy users of mprotect(), to the extent that the performance overhead in current Xenolinux impacts scaling beyond a few cpus quite badly. A single cpu run under Xen has a nominal impact, but scaling out to 8 cpus results in a performance of

This patch series contains a set of patches making minios rather easier to use, from an application development point of view. Overview of patches: 1 Command line argument parsing support, from Xen. 2 Weak console handler function. 3 Build system tweaks for application directories. 4 Trailing whitespace cleanup. (because it is very messy) Patch 4 is likely to be more controversial than

This patch pretty prints the hypercall section for $xenperf -f Each hypercall count is tagged by its name. Reference: http://lists.xensource.com/archives/html/xen-ia64-devel/2006-08/msg00261.html Signed-off-by Ken Hironaka <kenny@logos.ic.i.u-tokyo.ac.jp> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

I am learning xen's memory management recently. I find most docs is how to use the hypercall related memory management. Can somesome tell me where is the implementation of the them in the xen source. Or some docs explaining it will be ideal. 年少不惧江湖老，放歌四海任逍遥。未解前路多少事，欲与青天试比高。 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org

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.

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 is mapped at 0 (due to Mini-OS being there): _te...

...arch-x86_64.h" +#elif defined(__ia64__) +#include "arch-ia64.h" +#elif defined(__powerpc__) +#include "arch-powerpc.h" +#else +#error "Unsupported architecture" +#endif + +/* + * HYPERCALLS + */ + +#define __HYPERVISOR_set_trap_table 0 +#define __HYPERVISOR_mmu_update 1 +#define __HYPERVISOR_set_gdt 2 +#define __HYPERVISOR_stack_switch 3 +#define __HYPERVISOR_set_callbacks 4 +#define __HYPERVISOR_fpu_taskswitch 5 +#define __HYPERVISOR_sched_op_compat 6 /* compat since 0x00030101 */ +#define __HYPERVISOR_p...

Hi everyone, I am very excited to see that dom0 pvops is finally coming close to working, so I wanted to give it a try. >From the description it was not clear to me which kernel to chose as base for the patches.hg, so I took the latest (that was ~ 2 weeks ago) kernel on git.kernel.org I could find (post-2.6.28 git tip at that point). I managed to more or less apply all of the patches in the

Hi Andi, This series of patches implements the Xen paravirt-ops interface. It applies to 2.6.21-rc7 + your patches + the last batch of pv_ops patches I posted. This patch generally restricts itself to Xen-specific parts of the tree, though it does make a few small changes elsewhere. These patches include: - some helper routines for allocating address space and walking pagetables - Xen