kernel.git/arch/arm/xen, branch linux-5.4.y

arm/xen: fix xen_vcpu_info allocation alignment

2023-12-08T07:44:23Z

[ Upstream commit 7bf9a6b46549852a37e6d07e52c601c3c706b562 ] xen_vcpu_info is a percpu area than needs to be mapped by Xen. Currently, it could cross a page boundary resulting in Xen being unable to map it: [ 0.567318] kernel BUG at arch/arm64/xen/../../arm/xen/enlighten.c:164! [ 0.574002] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Fix the issue by using __alloc_percpu and requesting alignment for the memory allocation. Signed-off-by: Stefano Stabellini Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2311221501340.2053963@ubuntu-linux-20-04-desktop Fixes: 24d5373dda7c ("arm/xen: Use alloc_percpu rather than __alloc_percpu") Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

dma-mapping: drop the dev argument to arch_sync_dma_for_*

2023-04-05T09:16:43Z

[ Upstream commit 56e35f9c5b87ec1ae93e483284e189c84388de16 ] These are pure cache maintainance routines, so drop the unused struct device argument. Signed-off-by: Christoph Hellwig Suggested-by: Daniel Vetter Stable-dep-of: ab327f8acdf8 ("mips: bmips: BCM6358: disable RAC flush for TP1") Signed-off-by: Sasha Levin

xen/arm: Fix race in RB-tree based P2M accounting

2022-07-07T15:36:53Z

commit b75cd218274e01d026dc5240e86fdeb44bbed0c8 upstream. During the PV driver life cycle the mappings are added to the RB-tree by set_foreign_p2m_mapping(), which is called from gnttab_map_refs() and are removed by clear_foreign_p2m_mapping() which is called from gnttab_unmap_refs(). As both functions end up calling __set_phys_to_machine_multi() which updates the RB-tree, this function can be called concurrently. There is already a "p2m_lock" to protect against concurrent accesses, but the problem is that the first read of "phys_to_mach.rb_node" in __set_phys_to_machine_multi() is not covered by it, so this might lead to the incorrect mappings update (removing in our case) in RB-tree. In my environment the related issue happens rarely and only when PV net backend is running, the xen_add_phys_to_mach_entry() claims that it cannot add new pfn <-> mfn mapping to the tree since it is already exists which results in a failure when mapping foreign pages. But there might be other bad consequences related to the non-protected root reads such use-after-free, etc. While at it, also fix the similar usage in __pfn_to_mfn(), so initialize "struct rb_node *n" with the "p2m_lock" held in both functions to avoid possible bad consequences. This is CVE-2022-33744 / XSA-406. Signed-off-by: Oleksandr Tyshchenko Reviewed-by: Stefano Stabellini Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman

Xen/gnttab: handle p2m update errors on a per-slot basis

2021-03-07T11:20:49Z

commit 8310b77b48c5558c140e7a57a702e7819e62f04e upstream. Bailing immediately from set_foreign_p2m_mapping() upon a p2m updating error leaves the full batch in an ambiguous state as far as the caller is concerned. Instead flags respective slots as bad, unmapping what was mapped there right away. HYPERVISOR_grant_table_op()'s return value and the individual unmap slots' status fields get used only for a one-time - there's not much we can do in case of a failure. Note that there's no GNTST_enomem or alike, so GNTST_general_error gets used. The map ops' handle fields get overwritten just to be on the safe side. This is part of XSA-367. Cc: Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/96cccf5d-e756-5f53-b91a-ea269bfb9be0@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman

xen/arm: don't ignore return errors from set_phys_to_machine

2021-02-23T14:02:26Z

commit 36bf1dfb8b266e089afa9b7b984217f17027bf35 upstream. set_phys_to_machine can fail due to lack of memory, see the kzalloc call in arch/arm/xen/p2m.c:__set_phys_to_machine_multi. Don't ignore the potential return error in set_foreign_p2m_mapping, returning it to the caller instead. This is part of XSA-361. Signed-off-by: Stefano Stabellini Cc: stable@vger.kernel.org Reviewed-by: Julien Grall Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman

arm/xen: Don't probe xenbus as part of an early initcall

2021-02-17T09:35:14Z

commit c4295ab0b485b8bc50d2264bcae2acd06f25caaf upstream. After Commit 3499ba8198cad ("xen: Fix event channel callback via INTX/GSI"), xenbus_probe() will be called too early on Arm. This will recent to a guest hang during boot. If the hang wasn't there, we would have ended up to call xenbus_probe() twice (the second time is in xenbus_probe_initcall()). We don't need to initialize xenbus_probe() early for Arm guest. Therefore, the call in xen_guest_init() is now removed. After this change, there is no more external caller for xenbus_probe(). So the function is turned to a static one. Interestingly there were two prototypes for it. Cc: stable@vger.kernel.org Fixes: 3499ba8198cad ("xen: Fix event channel callback via INTX/GSI") Reported-by: Ian Jackson Signed-off-by: Julien Grall Reviewed-by: David Woodhouse Reviewed-by: Stefano Stabellini Link: https://lore.kernel.org/r/20210210170654.5377-1-julien@xen.org Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman

xen: Fix event channel callback via INTX/GSI

2021-01-27T10:47:44Z

[ Upstream commit 3499ba8198cad47b731792e5e56b9ec2a78a83a2 ] For a while, event channel notification via the PCI platform device has been broken, because we attempt to communicate with xenstore before we even have notifications working, with the xs_reset_watches() call in xs_init(). We tend to get away with this on Xen versions below 4.0 because we avoid calling xs_reset_watches() anyway, because xenstore might not cope with reading a non-existent key. And newer Xen *does* have the vector callback support, so we rarely fall back to INTX/GSI delivery. To fix it, clean up a bit of the mess of xs_init() and xenbus_probe() startup. Call xs_init() directly from xenbus_init() only in the !XS_HVM case, deferring it to be called from xenbus_probe() in the XS_HVM case instead. Then fix up the invocation of xenbus_probe() to happen either from its device_initcall if the callback is available early enough, or when the callback is finally set up. This means that the hack of calling xenbus_probe() from a workqueue after the first interrupt, or directly from the PCI platform device setup, is no longer needed. Signed-off-by: David Woodhouse Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210113132606.422794-2-dwmw2@infradead.org Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

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

2019-10-04T18:13:09Z

Pull xen fixes and cleanups from Juergen Gross: - a fix in the Xen balloon driver avoiding hitting a BUG_ON() in some cases, plus a follow-on cleanup series for that driver - a patch for introducing non-blocking EFI callbacks in Xen's EFI driver, plu a cleanup patch for Xen EFI handling merging the x86 and ARM arch specific initialization into the Xen EFI driver - a fix of the Xen xenbus driver avoiding a self-deadlock when cleaning up after a user process has died - a fix for Xen on ARM after removal of ZONE_DMA - a cleanup patch for avoiding build warnings for Xen on ARM * tag 'for-linus-5.4-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/xenbus: fix self-deadlock after killing user process xen/efi: have a common runtime setup function arm: xen: mm: use __GPF_DMA32 for arm64 xen/balloon: Clear PG_offline in balloon_retrieve() xen/balloon: Mark pages PG_offline in balloon_append() xen/balloon: Drop __balloon_append() xen/balloon: Set pages PageOffline() in balloon_add_region() ARM: xen: unexport HYPERVISOR_platform_op function xen/efi: Set nonblocking callbacks

xen/efi: have a common runtime setup function

2019-10-02T14:31:07Z

Today the EFI runtime functions are setup in architecture specific code (x86 and arm), with the functions themselves living in drivers/xen as they are not architecture dependent. As the setup is exactly the same for arm and x86 move the setup to drivers/xen, too. This at once removes the need to make the single functions global visible. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich [boris: "Dropped EXPORT_SYMBOL_GPL(xen_efi_runtime_setup)"] Signed-off-by: Boris Ostrovsky

arm: xen: mm: use __GPF_DMA32 for arm64

2019-10-02T01:50:07Z

arm64 shares some code under arch/arm/xen, including mm.c. However ZONE_DMA is removed by commit ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32"). So add a check if CONFIG_ZONE_DMA32 is enabled use __GFP_DMA32. Signed-off-by: Peng Fan Acked-by: Stefano Stabellini Signed-off-by: Stefano Stabellini