search for: p2m_mem_paging_popul

The following two patches are about how to speed up in xenpaging when page in pages. On suse11-64 with 4G memory,if we page out 2G pages,it will cost about 15.5 seconds, but take 2088 seconds to finish paging in.If page-in costs too much time,it will cause unmesurable problems when vm or dom0 access the paged_out page,such as BSOD,crash. What鈥檚 more,the dom0 is always in high I/O pressure.

ging_prep ensures that an mfn is backing the paged-out gfn, and transitions to the next state in the paging state machine for this page. Foreign mappings of the gfn will now succeed. This is the key idea, as it allows the pager to now map the gfn and fill in its contents. Unfortunately, it also allows any other foreign mapper to map the gfn and read its contents. This is particularly dangerous

...e_enabled(v) || (v->arch.hvm_vcpu.guest_efer & EFER_LMA) ) return; if ( cr3 & 0x1fUL ) goto crash; mfn = mfn_x(gfn_to_mfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt)); if ( !p2m_is_ram(p2mt) ) goto crash; + if( p2m_is_paging(p2mt)) + { + p2m_mem_paging_populate(v->domain, cr3 >> PAGE_SHIFT); + do + { + mdelay(1); + try_count ++; + if ( try_count > 65535 ) + { + goto crash; + } + mfn = mfn_x(gfn_to_mfn(v->domain, cr3 >> PAGE_SHIFT,...

The patch ''mem_event: use wait queue when ring is full'' I just sent out makes use of the waitqueue feature. There are two issues I get with the change applied: I think I got the logic right, and in my testing vcpu->pause_count drops to zero in p2m_mem_paging_resume(). But for some reason the vcpu does not make progress after the first wakeup. In my debugging there is one

The following two patches allow the parallel use of memsharing, xenpaging and xen-access by using an independent ring buffer for each feature. Please review. v2: - update mem_event_check_ring arguments, check domain rather than domain_id - check ring_full first because its value was just evaluated - check if ring buffer is initialized before calling mem_access_domctl/mem_paging_domctl

# HG changeset patch # User h00166998@h00166998.china.huawei.com # Date 1328777881 -28800 # Node ID 68eae0b487aef8349f168518f56264ce61afb0a1 # Parent 9f4640e40d4f31563885427a5a8d9eae2e110514 xenpaging:add the dealing of MEM_EVENT_FLAG_EVICT_FAIL request in tools/xenpaging If a page is nominated but not evicted,then dom0 accesses the page,it will change the page''s p2mt to be

# HG changeset patch # User hongkaixing<hongkaixing@huawei.com> # Date 1325149704 -28800 # Node ID 052727b8165ce6e05002184ae894096214c8b537 # Parent 54a5e994a241a506900ee0e197bb42e5f1d8e759 xenpaging:add a new array to speed up page-in in xenpaging This patch adds a new array named page_out_index to reserve the victim''s index. When page in a page,it has to go through a for loop

I ran a bisect to find out when Windows XP 32 bit becomes unusably slow. And I found the changeset that caused it. ========== The problem: ========== Windows 8 64 bit and 32 bit run fast and fine in the newest xen versions. Windows XP 32 bit runs unusably slow in anything new that I built from xen-unstable, but runs fast in 4.1.2 and 4.1.3 stable. While it is running slow, "xm top" or

Patrick, there following patches fix xenpaging for me. Granttable handling is incomplete. If a page is gone, a GNTST_eagain should be returned to the caller to inidcate the hypercall has to be retried after a while, until the page is available again. Please review. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See