similar to: Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps

In commit cd9151e2: xen/balloon: set a mapping for ballooned out pages we have the ballooned out page''s mapping set to a scratch page. That commit also sets the P2M entry of ballooned out page to the scratch page''s MFN. This is necessary for PV guest but not for HVM guest. On the other hand, setting the P2M entry would trigger BUG_ON in __set_phys_to_machine. The correct thing

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 all, this patch series enables xen-swiotlb on arm and arm64. It has been heavily reworked compared to the previous versions in order to achieve better performances and to address review comments. We are not using dma_mark_clean to ensure coherency anymore. We call the platform implementation of map_page and unmap_page. We assume that dom0 has been mapped 1:1 (physical address == machine

(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override during mapping") The grant mapping API does m2p_override unnecessarily: only gntdev needs it, for blkback and future netback patches it just cause a lock contention, as those pages never go to userspace. Therefore this series does the following: - the bulk of the original function (everything after the mapping

(This is a continuation of "[PATCH v9] xen/grant-table: Avoid m2p_override during mapping") The grant mapping API does m2p_override unnecessarily: only gntdev needs it, for blkback and future netback patches it just cause a lock contention, as those pages never go to userspace. Therefore this series does the following: - the bulk of the original function (everything after the mapping

It was decided during xen patch review that xen map the iomem transparently, so remove xen_set_clr_mmio_pvh_pte() and the sub hypercall PHYSDEVOP_map_iomem. --- arch/x86/xen/mmu.c | 14 -------------- arch/x86/xen/setup.c | 16 ++++------------ include/xen/interface/physdev.h | 10 ---------- 3 files changed, 4 insertions(+), 36 deletions(-) diff --git

This is my current set of updates to Xen for 2.6.24. This is largely a bugfix set, and a couple of them are also relevent to 2.6.23. These are in the pre-x86 merge form; I'll update them once the merge goes into git. Quick overview: - remove some dead code in arch/i386/mm/init.c - clean up some duplicate includes - when sending an IPI, yield the vcpu if the destination doesn't have

This is my current set of updates to Xen for 2.6.24. This is largely a bugfix set, and a couple of them are also relevent to 2.6.23. These are in the pre-x86 merge form; I'll update them once the merge goes into git. Quick overview: - remove some dead code in arch/i386/mm/init.c - clean up some duplicate includes - when sending an IPI, yield the vcpu if the destination doesn't have

This is my current set of updates to Xen for 2.6.24. This is largely a bugfix set, and a couple of them are also relevent to 2.6.23. These are in the pre-x86 merge form; I'll update them once the merge goes into git. Quick overview: - remove some dead code in arch/i386/mm/init.c - clean up some duplicate includes - when sending an IPI, yield the vcpu if the destination doesn't have

Hi Jeremy. According to your suggestion, I recreated patches for Ingo's x86.git tree. And this patch series includes Eddie's modification. Please review and forward them. (or push back to respin.) Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux

Hi Jeremy. According to your suggestion, I recreated patches for Ingo's x86.git tree. And this patch series includes Eddie's modification. Please review and forward them. (or push back to respin.) Recently the xen-ia64 community started to make efforts to merge xen/ia64 Linux to upstream. The first step is to merge up domU portion. This patchset is preliminary for xen/ia64 domU linux

Hi, we have some problems with acpidump running on Xen Dom0. On 64 bit Dom0 it will trigger the OOM killer, on 32 bit Dom0s it will cause a kernel crash. The hypervisor does not matter, I tried 4.1.3-rc2 as well as various unstable versions including 25467, also 32-bit versions of 4.1. The Dom0 kernels were always PVOPS versions, the problems starts with 3.2-rc1~194 and is still in 3.5.0-rc3.

Hi linux/ia64 developers. Few days before Eddie posted the mail for Linux/IA64 paravirtualization. But only a few responded partially because there was no reviewable patches. Here is the patches for xen/ia64 Linux paravirtualization. The goal is to merge IA64 xen Linux paravirtualization for both domU and dom0 eventually. However the first step is to merge domU portion. As you can see from the

Hi, V6: The only change from V5 is in patch #6: - changed comment to reflect autoxlate - removed a redundant ASSERT - reworked logic a bit so that get_page_from_gfn() is called with NULL for p2m type as before. arm has ASSERT wanting it to be NULL. Tim: patch 4 needs your approval. Daniel: patch 5 needs your approval. These patches implement PVH dom0. Patches 1 and 2

Hi, I am bit confused about the do_update_va_mapping call that dom0 makes in xen_ident_map_ISA() to map ffff8800000a0000 to mfn a0. The mfn belongs to DOMID_IO. Before the mfn is mapped, the l1 entry is not empty: 0000000139d08500: 00100001380a0027 After the mapping: 0000000139d08500: 00100000000a0467 as expected. However, the mfn 1380a0 still seems to belong to dom0. Shouldn''t

This series implements ballooning for Xen on ARM and builds and Mukesh''s PVH privcmd stuff to implement foreign page mapping on ARM, replacing the old "HACK: initial (very hacky) XENMAPSPACE_gmfn_foreign" patch. The baseline is a bit complex, it is basically Stefano''s xenarm-forlinus branch (commit bbd6eb29214e) merged with Konrad''s linux-next-pvh branch

Hi, all Page offline can be used by many purpose, like memory offline, memory power management, proactive action when multiple CE error happen to one page etc. In virtualization environment without guest offline support, we think offline a page usually means replace the old page with a new one transparently to guest. Currently we are trying to add page offline support in Xen environment .

This patch is cleaned up of the patch which was sent as http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00324.html # HG changeset patch # User yamahata@valinux.co.jp # Date 1181545986 -32400 # Node ID 69e2dd4e06c405a92717c5f1818f5096e1dc0bcd # Parent d5e0eb7dd069c0ffc1854da81aa143ccfb0ad66e make dma address conversion logic of gnttab dma arch specific. gnttab_dma_map_page() and

Hi guys, During my refresh to latest linux, I noticed, direct mapping of all non-RAM pages in xen_set_identity_and_release(). I currently don''t map all at front, but as needed looking at the PAGE_IO bit in the pte. One result of that is minor change to common code macro: __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE) to to __set_fixmap(idx, phys, PAGE_KERNEL_IO_NOCACHE)

Assumes hypervisor interface headers have been sync-ed after the hypervisor side patch was applied. As usual, written and tested on 2.6.27.3 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-10-24/arch/i386/mm/highmem-xen.c =================================================================== ---