kernel/linux.git/drivers/xen, branch v4.19.16

pvcalls-front: fixes incorrect error handling

2018-12-17T08:24:39+00:00

[ Upstream commit 975ef94a0284648fb0137bd5e949b18cef604e33 ] kfree() is incorrectly used to release the pages allocated by __get_free_page() and __get_free_pages(). Use the matching deallocators i.e., free_page() and free_pages(), respectively. Signed-off-by: Pan Bian Reviewed-by: Stefano Stabellini Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

Revert "xen/balloon: Mark unallocated host memory as UNUSABLE"

2018-12-17T08:24:39+00:00

[ Upstream commit 123664101aa2156d05251704fc63f9bcbf77741a ] This reverts commit b3cf8528bb21febb650a7ecbf080d0647be40b9f. That commit unintentionally broke Xen balloon memory hotplug with "hotplug_unpopulated" set to 1. As long as "System RAM" resource got assigned under a new "Unusable memory" resource in IO/Mem tree any attempt to online this memory would fail due to general kernel restrictions on having "System RAM" resources as 1st level only. The original issue that commit has tried to workaround fa564ad96366 ("x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00-1f, 30-3f, 60-7f)") also got amended by the following 03a551734 ("x86/PCI: Move and shrink AMD 64-bit window to avoid conflict") which made the original fix to Xen ballooning unnecessary. Signed-off-by: Igor Druzhinin Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

xen: xlate_mmu: add missing header to fix 'W=1' warning

2018-12-17T08:24:39+00:00

[ Upstream commit 72791ac854fea36034fa7976b748fde585008e78 ] Add a missing header otherwise compiler warns about missed prototype: drivers/xen/xlate_mmu.c:183:5: warning: no previous prototype for 'xen_xlate_unmap_gfn_range?' [-Wmissing-prototypes] int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma, ^~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Srikanth Boddepalli Reviewed-by: Boris Ostrovsky Reviewed-by: Joey Pabalinas Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

xen/grant-table: Fix incorrect gnttab_dma_free_pages() pr_debug message

2018-11-27T15:13:04+00:00

[ Upstream commit d9cccfa7c4d1d9ef967ec9308df7304a18609b30 ] If a call to xenmem_reservation_increase() in gnttab_dma_free_pages() fails it triggers a message "Failed to decrease reservation..." which should be "Failed to increase reservation..." Fixes: 9bdc7304f536 ('xen/grant-table: Allow allocating buffers suitable for DMA') Reported-by: Ross Philipson Signed-off-by: Liam Merwick Reviewed-by: Mark Kanda Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

xen: remove size limit of privcmd-buf mapping interface

2018-11-13T19:08:52+00:00

commit 3941552aec1e04d63999988a057ae09a1c56ebeb upstream. Currently the size of hypercall buffers allocated via /dev/xen/hypercall is limited to a default of 64 memory pages. For live migration of guests this might be too small as the page dirty bitmask needs to be sized according to the size of the guest. This means migrating a 8GB sized guest is already exhausting the default buffer size for the dirty bitmap. There is no sensible way to set a sane limit, so just remove it completely. The device node's usage is limited to root anyway, so there is no additional DOS scenario added by allowing unlimited buffers. While at it make the error path for the -ENOMEM case a little bit cleaner by setting n_pages to the number of successfully allocated pages instead of the target size. Fixes: c51b3c639e01f2 ("xen: add new hypercall buffer mapping device") Cc: #4.18 Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman

xen/balloon: Support xend-based toolstack

2018-11-13T19:08:40+00:00

commit 3aa6c19d2f38be9c6e9a8ad5fa8e3c9d29ee3c35 upstream. Xend-based toolstacks don't have static-max entry in xenstore. The equivalent node for those toolstacks is memory_static_max. Fixes: 5266b8e4445c (xen: fix booting ballooned down hvm guest) Signed-off-by: Boris Ostrovsky Cc: # 4.13 Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman

xen-swiotlb: use actually allocated size on check physical continuous

2018-11-13T19:08:40+00:00

commit 7250f422da0480d8512b756640f131b9b893ccda upstream. xen_swiotlb_{alloc,free}_coherent() allocate/free memory based on the order of the pages and not size argument (bytes). This is inconsistent with range_straddles_page_boundary and memset which use the 'size' value, which may lead to not exchanging memory with Xen (range_straddles_page_boundary() returned true). And then the call to xen_swiotlb_free_coherent() would actually try to exchange the memory with Xen, leading to the kernel hitting an BUG (as the hypercall returned an error). This patch fixes it by making the 'size' variable be of the same size as the amount of memory allocated. CC: stable@vger.kernel.org Signed-off-by: Joe Jin Cc: Konrad Rzeszutek Wilk Cc: Boris Ostrovsky Cc: Christoph Helwig Cc: Dongli Zhang Cc: John Sobecki Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

xen: issue warning message when out of grant maptrack entries

2018-09-19T15:27:42+00:00

When a driver domain (e.g. dom0) is running out of maptrack entries it can't map any more foreign domain pages. Instead of silently stalling the affected domUs issue a rate limited warning in this case in order to make it easier to detect that situation. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Boris Ostrovsky

xen/gntdev: fix up blockable calls to mn_invl_range_start

2018-09-14T12:52:30+00:00

Patch series "mmu_notifiers follow ups". Tetsuo has noticed some fallouts from 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers"). One of them has been fixed and picked up by AMD/DRM maintainer [1]. XEN issue is fixed by patch 1. I have also clarified expectations about blockable semantic of invalidate_range_end. Finally the last patch removes MMU_INVALIDATE_DOES_NOT_BLOCK which is no longer used nor needed. [1] http://lkml.kernel.org/r/20180824135257.GU29735@dhcp22.suse.cz This patch (of 3): 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers") has introduced blockable parameter to all mmu_notifiers and the notifier has to back off when called in !blockable case and it could block down the road. The above commit implemented that for mn_invl_range_start but both in_range checks are done unconditionally regardless of the blockable mode and as such they would fail all the time for regular calls. Fix this by checking blockable parameter as well. Once we are there we can remove the stale TODO. The lock has to be sleepable because we wait for completion down in gnttab_unmap_refs_sync. Link: http://lkml.kernel.org/r/20180827112623.8992-2-mhocko@kernel.org Fixes: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers") Signed-off-by: Michal Hocko Cc: Boris Ostrovsky Cc: Juergen Gross Cc: David Rientjes Cc: Jerome Glisse Cc: Tetsuo Handa Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky

xen: fix GCC warning and remove duplicate EVTCHN_ROW/EVTCHN_COL usage

2018-09-14T12:51:10+00:00

This patch removes duplicate macro useage in events_base.c. It also fixes gcc warning: variable ‘col’ set but not used [-Wunused-but-set-variable] Signed-off-by: Joshua Abraham Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky