search for: pfn_phys

...) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 79bc493..56014d5 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -75,37 +75,6 @@ static unsigned long xen_io_tlb_nslabs; static u64 start_dma_addr; -/* - * Both of these functions should avoid PFN_PHYS because phys_addr_t - * can be 32bit when dma_addr_t is 64bit leading to a loss in - * information if the shift is done before casting to 64bit. - */ -static inline dma_addr_t xen_phys_to_bus(phys_addr_t paddr) -{ - unsigned long bfn = pfn_to_bfn(PFN_DOWN(paddr)); - dma_addr_t dma = (dma_addr_t)bfn...

...n", start, end); /* * RMRR range might have overlap with physical memory range, * clear it first @@ -2760,7 +2751,8 @@ static int __init si_domain_init(int hw) for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) { ret = iommu_domain_identity_map(si_domain, - PFN_PHYS(start_pfn), PFN_PHYS(end_pfn)); + mm_to_dma_pfn(start_pfn), + mm_to_dma_pfn(end_pfn)); if (ret) return ret; } @@ -4593,58 +4585,37 @@ static int intel_iommu_memory_notifier(struct notifier_block *nb, unsigned long val, void *v) { struct memory_notify *mhp = v; - u...

Hi, Anyone has this working? Looks like there is a chicken-and-egg issue with pda setup: * xen_load_gdt() uses multicalls, thus depends on cpu-specific variables (per-cpu mc buffer) which in turn requires pda being setup already. * pda setup can't be done before xen_load_gdt() ... Next question while looking at xen_load_gdt(): why does it use multicalls in the first place?

Hi, Anyone has this working? Looks like there is a chicken-and-egg issue with pda setup: * xen_load_gdt() uses multicalls, thus depends on cpu-specific variables (per-cpu mc buffer) which in turn requires pda being setup already. * pda setup can't be done before xen_load_gdt() ... Next question while looking at xen_load_gdt(): why does it use multicalls in the first place?

...f (rc) { diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index 32e3bc0aa665a..0194bed1a5736 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -726,7 +726,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size, nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn)); ret = add_memory(nid, PFN_PHYS((start_pfn)), - (HA_CHUNK << PAGE_SHIFT)); + (HA_CHUNK << PAGE_SHIFT), 0); if (ret) { pr_err("hot_add memory failed error is %d\n", ret); diff --git a/drivers/s390/char/sclp_cmd.c b/drivers/s390/char/sclp_cmd.c inde...

...f (rc) { diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index 32e3bc0aa665a..3c0d52e244520 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -726,7 +726,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size, nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn)); ret = add_memory(nid, PFN_PHYS((start_pfn)), - (HA_CHUNK << PAGE_SHIFT)); + (HA_CHUNK << PAGE_SHIFT), MHP_NONE); if (ret) { pr_err("hot_add memory failed error is %d\n", ret); diff --git a/drivers/s390/char/sclp_cmd.c b/drivers/s390/char/sclp_cmd...

...,8 +302,20 @@ static void intel_agp_insert_sg_entries( int i, j; for (i = 0, j = pg_start; i < mem->page_count; i++, j++) { + phys_addr_t phys = page_to_phys(mem->pages[i]); + if (xen_pv_domain()) { + phys_addr_t xen_phys = PFN_PHYS(pfn_to_mfn( + page_to_pfn(mem->pages[i]))); + if (xen_phys != phys) { + printk(KERN_ERR "Compile kernel with " \ + "CONFIG_DMAR to get rid of this "...

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Hi all, this patch series introduces support for running Linux on top of Xen inside a virtual machine with virtio devices (nested virt scenario). The problem is that Linux virtio drivers use virt_to_phys to get the guest pseudo-physical addresses to pass to the backend, which doesn't work as expected on Xen. Switching the virtio drivers to the dma APIs (dma_alloc_coherent,

Hi all, this patch series introduces support for running Linux on top of Xen inside a virtual machine with virtio devices (nested virt scenario). The problem is that Linux virtio drivers use virt_to_phys to get the guest pseudo-physical addresses to pass to the backend, which doesn't work as expected on Xen. Switching the virtio drivers to the dma APIs (dma_alloc_coherent,

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

...uot;NUMA: Warning: node %d [mem %#010Lx-%#010Lx] overlaps with itself [mem %#010Lx-%#010Lx]\n", + bi->nid, bi->start, bi->end - 1, + bj->start, bj->end - 1); } /* @@ -364,7 +364,7 @@ static int __init numa_alloc_distance(void) phys = memblock_find_in_range(0, PFN_PHYS(max_pfn_mapped), size, PAGE_SIZE); if (!phys) { - pr_warning("NUMA: Warning: can't allocate distance table!\n"); + pr_warn("NUMA: Warning: can't allocate distance table!\n"); /* don't retry until explicitly reset */ numa_distance = (void *)1LU;...

@Andrew, @Mst, I suggest the whole series (including the virtio-mem change) goes via the -mm tree. Currently, virtio-mem does not really support ZONE_MOVABLE. While it allows to online fully plugged memory blocks to ZONE_MOVABLE, it does not allow to online partially-plugged memory blocks to ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff maintained by me. This should go via the -mm tree. --- When introducing virtio-mem, the semantics of ZONE_MOVABLE were rather unclear, which is why we special-cased ZONE_MOVABLE such that partially plugged blocks would never end up in ZONE_MOVABLE. Now that the semantics are much clearer (and are documented in patch #6),

For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff maintained by me. This should go via the -mm tree. --- When introducing virtio-mem, the semantics of ZONE_MOVABLE were rather unclear, which is why we special-cased ZONE_MOVABLE such that partially plugged blocks would never end up in ZONE_MOVABLE. Now that the semantics are much clearer (and are documented in patch #6),

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where