linux-stable.git/drivers/xen, branch v4.9.44

Xen: ARM: Zero reserved fields of xatp before making hypervisor call

2017-08-07T01:59:47+00:00

[ Upstream commit 0b47a6bd1150f4846b1d61925a4cc5a96593a541 ]

Ensure all reserved fields of xatp are zero before making
hypervisor call to XEN in xen_map_device_mmio().
xenmem_add_to_physmap_one() in XEN fails the mapping request if
extra.res reserved field in xatp is not zero for XENMAPSPACE_dev_mmio
request.

Signed-off-by: Jiandi An 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen/scsiback: Fix a TMR related use-after-free

2017-07-27T22:07:59+00:00

commit 9f4ab18ac51dc87345a9cbd2527e6acf7a0a9335 upstream.

scsiback_release_cmd() must not dereference se_cmd->se_tmr_req
because that memory is freed by target_free_cmd_mem() before
scsiback_release_cmd() is called. Fix this use-after-free by
inlining struct scsiback_tmr into struct vscsibk_pend.

Signed-off-by: Bart Van Assche 
Reviewed-by: Juergen Gross 
Cc: Christoph Hellwig 
Cc: Hannes Reinecke 
Cc: David Disseldorp 
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

swiotlb-xen: update dev_addr after swapping pages

2017-07-05T12:40:22+00:00

[ Upstream commit f1225ee4c8fcf09afaa199b8b1f0450f38b8cd11 ]

In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
page is not suitable, we swap it for another page from the swiotlb
pool.

In these cases, we don't update the previously calculated dma address
for the page before calling xen_dma_map_page. Thus, we end up calling
xen_dma_map_page passing the wrong dev_addr, resulting in
xen_dma_map_page mistakenly assuming that the page is foreign when it is
local.

Fix the bug by updating dev_addr appropriately.

This change has no effect on x86, because xen_dma_map_page is a stub
there.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Pooya Keshavarzi 
Tested-by: Pooya Keshavarzi 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen/privcmd: Support correctly 64KB page granularity when mapping memory

2017-06-14T13:05:58+00:00

commit 753c09b5652bb4fe53e2db648002ec64b32b8827 upstream.

Commit 5995a68 "xen/privcmd: Add support for Linux 64KB page granularity" did
not go far enough to support 64KB in mmap_batch_fn.

The variable 'nr' is the number of 4KB chunk to map. However, when Linux
is using 64KB page granularity the array of pages (vma->vm_private_data)
contain one page per 64KB. Fix it by incrementing st->index correctly.

Furthermore, st->va is not correctly incremented as PAGE_SIZE !=
XEN_PAGE_SIZE.

Fixes: 5995a68 ("xen/privcmd: Add support for Linux 64KB page granularity")
Reported-by: Feng Kan 
Signed-off-by: Julien Grall 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman

xen: Revert commits da72ff5bfcb0 and 72a9b186292d

2017-05-14T12:00:22+00:00

commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream.

Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741)
established that commit 72a9b186292d ("xen: Remove event channel
notification through Xen PCI platform device") (and thus commit
da72ff5bfcb0 ("partially revert "xen: Remove event channel
notification through Xen PCI platform device"")) are unnecessary and,
in fact, prevent HVM guests from booting on Xen releases prior to 4.0

Therefore we revert both of those commits.

The summary of that discussion is below:

  Here is the brief summary of the current situation:

  Before the offending commit (72a9b186292):

  1) INTx does not work because of the reset_watches path.
  2) The reset_watches path is only taken if you have Xen > 4.0
  3) The Linux Kernel by default will use vector inject if the hypervisor
     support. So even INTx does not work no body running the kernel with
     Xen > 4.0 would notice. Unless he explicitly disabled this feature
     either in the kernel or in Xen (and this can only be disabled by
     modifying the code, not user-supported way to do it).

  After the offending commit (+ partial revert):

  1) INTx is no longer support for HVM (only for PV guests).
  2) Any HVM guest The kernel will not boot on Xen < 4.0 which does
     not have vector injection support. Since the only other mode
     supported is INTx which.

  So based on this summary, I think before commit (72a9b186292) we were
  in much better position from a user point of view.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
Cc: Boris Ostrovsky 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x86@kernel.org
Cc: Konrad Rzeszutek Wilk 
Cc: Bjorn Helgaas 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Vitaly Kuznetsov 
Cc: Paul Gortmaker 
Cc: Ross Lagerwall 
Cc: xen-devel@lists.xenproject.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: Anthony Liguori 
Cc: KarimAllah Ahmed 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman

xen/acpi: upload PM state from init-domain to Xen

2017-03-30T07:41:26+00:00

commit 1914f0cd203c941bba72f9452c8290324f1ef3dc upstream.

This was broken in commit cd979883b9ed ("xen/acpi-processor:
fix enabling interrupts on syscore_resume"). do_suspend (from
xen/manage.c) and thus xen_resume_notifier never get called on
the initial-domain at resume (it is if running as guest.)

The rationale for the breaking change was that upload_pm_data()
potentially does blocking work in syscore_resume(). This patch
addresses the original issue by scheduling upload_pm_data() to
execute in workqueue context.

Cc: Stanislaw Gruszka 
Based-on-patch-by: Konrad Wilk 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Stanislaw Gruszka 
Signed-off-by: Ankur Arora 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

swiotlb: Convert swiotlb_force from int to enum

2017-01-26T07:24:44+00:00

commit ae7871be189cb41184f1e05742b4a99e2c59774d upstream.

Convert the flag swiotlb_force from an int to an enum, to prepare for
the advent of more possible values.

Suggested-by: Konrad Rzeszutek Wilk 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

2017-01-06T09:40:17+00:00

commit 30faaafdfa0c754c91bac60f216c9f34a2bfdf7e upstream.

Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
NUMA balancing") set VM_IO flag to prevent grant maps from being
subjected to NUMA balancing.

It was discovered recently that this flag causes get_user_pages() to
always fail with -EFAULT.

check_vma_flags
__get_user_pages
__get_user_pages_locked
__get_user_pages_unlocked
get_user_pages_fast
iov_iter_get_pages
dio_refill_pages
do_direct_IO
do_blockdev_direct_IO
do_blockdev_direct_IO
ext4_direct_IO_read
generic_file_read_iter
aio_run_iocb

(which can happen if guest's vdisk has direct-io-safe option).

To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
NUMA balancing just as VM_IO does and has no effect on
check_vma_flags().


Reported-by: Olaf Hering 
Suggested-by: Hugh Dickins 
Signed-off-by: Boris Ostrovsky 
Acked-by: Hugh Dickins 
Tested-by: Olaf Hering 
Signed-off-by: Juergen Gross 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'for-linus-4.9-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2016-10-25T02:52:24+00:00

Pull xen fixes from David Vrabel:

 - advertise control feature flags in xenstore

 - fix x86 build when XEN_PVHVM is disabled

* tag 'for-linus-4.9-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xenbus: check return value of xenbus_scanf()
  xenbus: prefer list_for_each()
  x86: xen: move cpu_up functions out of ifdef
  xenbus: advertise control feature flags

xenbus: check return value of xenbus_scanf()

2016-10-24T15:08:21+00:00

Don't ignore errors here: Set backend state to unknown when
unsuccessful.

Signed-off-by: Jan Beulich 
Signed-off-by: David Vrabel