kernel.git/include/xen/xen.h, branch linux-5.19.y

xen: don't require virtio with grants for non-PV guests

2022-08-17T13:15:41Z

[ Upstream commit 251e90e7e346a23742b90e2c4db19d322e071d99 ] Commit fa1f57421e0b ("xen/virtio: Enable restricted memory access using Xen grant mappings") introduced a new requirement for using virtio devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM feature. This is an undue requirement for non-PV guests, as those can be operated with existing backends without any problem, as long as those backends are running in dom0. Per default allow virtio devices without grant support for non-PV guests. On Arm require VIRTIO_F_ACCESS_PLATFORM for devices having been listed in the device tree to use grants. Add a new config item to always force use of grants for virtio. Fixes: fa1f57421e0b ("xen/virtio: Enable restricted memory access using Xen grant mappings") Reported-by: Viresh Kumar Signed-off-by: Juergen Gross Reviewed-by: Oleksandr Tyshchenko Tested-by: Oleksandr Tyshchenko # Arm64 guest using Xen Reviewed-by: Stefano Stabellini Link: https://lore.kernel.org/r/20220622063838.8854-4-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

virtio: replace restricted mem access flag with callback

2022-08-17T13:15:41Z

[ Upstream commit a603002eea8213eec5211be5a85db8340aea06d0 ] Instead of having a global flag to require restricted memory access for all virtio devices, introduce a callback which can select that requirement on a per-device basis. For convenience add a common function returning always true, which can be used for use cases like SEV. Per default use a callback always returning false. As the callback needs to be set in early init code already, add a virtio anchor which is builtin in case virtio is enabled. Signed-off-by: Juergen Gross Tested-by: Oleksandr Tyshchenko # Arm64 guest using Xen Reviewed-by: Stefano Stabellini Link: https://lore.kernel.org/r/20220622063838.8854-2-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

xen/virtio: Enable restricted memory access using Xen grant mappings

2022-06-06T14:07:30Z

In order to support virtio in Xen guests add a config option XEN_VIRTIO enabling the user to specify whether in all Xen guests virtio should be able to access memory via Xen grant mappings only on the host side. Also set PLATFORM_VIRTIO_RESTRICTED_MEM_ACCESS feature from the guest initialization code on Arm and x86 if CONFIG_XEN_VIRTIO is enabled. Signed-off-by: Juergen Gross Signed-off-by: Oleksandr Tyshchenko Reviewed-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/1654197833-25362-5-git-send-email-olekstysh@gmail.com Signed-off-by: Juergen Gross

xen/unpopulated-alloc: Add mechanism to use Xen resource

2022-01-06T08:53:38Z

The main reason of this change is that unpopulated-alloc code cannot be used in its current form on Arm, but there is a desire to reuse it to avoid wasting real RAM pages for the grant/foreign mappings. The problem is that system "iomem_resource" is used for the address space allocation, but the really unallocated space can't be figured out precisely by the domain on Arm without hypervisor involvement. For example, not all device I/O regions are known by the time domain starts creating grant/foreign mappings. And following the advise from "iomem_resource" we might end up reusing these regions by a mistake. So, the hypervisor which maintains the P2M for the domain is in the best position to provide unused regions of guest physical address space which could be safely used to create grant/foreign mappings. Introduce new helper arch_xen_unpopulated_init() which purpose is to create specific Xen resource based on the memory regions provided by the hypervisor to be used as unused space for Xen scratch pages. If arch doesn't define arch_xen_unpopulated_init() the default "iomem_resource" will be used. Update the arguments list of allocate_resource() in fill_list() to always allocate a region from the hotpluggable range (maximum possible addressable physical memory range for which the linear mapping could be created). If arch doesn't define arch_get_mappable_range() the default range (0,-1) will be used. The behaviour on x86 won't be changed by current patch as both arch_xen_unpopulated_init() and arch_get_mappable_range() are not implemented for it. Also fallback to allocate xenballooned pages (balloon out RAM pages) if we do not have any suitable resource to work with (target_resource is invalid) and as the result we won't be able to provide unpopulated pages on a request. Signed-off-by: Oleksandr Tyshchenko Reviewed-by: Stefano Stabellini Link: https://lore.kernel.org/r/1639080336-26573-5-git-send-email-olekstysh@gmail.com Signed-off-by: Juergen Gross

xen/balloon: Bring alloc(free)_xenballooned_pages helpers back

2022-01-06T08:53:35Z

This patch rolls back some of the changes introduced by commit 121f2faca2c0a "xen/balloon: rename alloc/free_xenballooned_pages" in order to make possible to still allocate xenballooned pages if CONFIG_XEN_UNPOPULATED_ALLOC is enabled. On Arm the unpopulated pages will be allocated on top of extended regions provided by Xen via device-tree (the subsequent patches will add required bits to support unpopulated-alloc feature on Arm). The problem is that extended regions feature has been introduced into Xen quite recently (during 4.16 release cycle). So this effectively means that Linux must only use unpopulated-alloc on Arm if it is running on "new Xen" which advertises these regions. But, it will only be known after parsing the "hypervisor" node at boot time, so before doing that we cannot assume anything. In order to keep working if CONFIG_XEN_UNPOPULATED_ALLOC is enabled and the extended regions are not advertised (Linux is running on "old Xen", etc) we need the fallback to alloc_xenballooned_pages(). This way we wouldn't reduce the amount of memory usable (wasting RAM pages) for any of the external mappings anymore (and eliminate XSA-300) with "new Xen", but would be still functional ballooning out RAM pages with "old Xen". Also rename alloc(free)_xenballooned_pages to xen_alloc(free)_ballooned_pages and make xen_alloc(free)_unpopulated_pages static inline in xen.h if CONFIG_XEN_UNPOPULATED_ALLOC is disabled. Signed-off-by: Oleksandr Tyshchenko Reviewed-by: Stefano Stabellini Link: https://lore.kernel.org/r/1639080336-26573-4-git-send-email-olekstysh@gmail.com Signed-off-by: Juergen Gross

xen/balloon: rename alloc/free_xenballooned_pages

2021-11-04T17:59:44Z

alloc_xenballooned_pages() and free_xenballooned_pages() are used as direct replacements of xen_alloc_unpopulated_pages() and xen_free_unpopulated_pages() in case CONFIG_XEN_UNPOPULATED_ALLOC isn't defined. Guard both functions with !CONFIG_XEN_UNPOPULATED_ALLOC and rename them to the xen_*() variants they are replacing. This allows to remove some ifdeffery from the xen.h header file. Adapt the prototype of the functions to match. Signed-off-by: Juergen Gross Link: https://lore.kernel.org/r/20211102092234.17852-1-jgross@suse.com Reviewed-by: Boris Ostrovsky Signed-off-by: Boris Ostrovsky

xen: add helpers to allocate unpopulated memory

2020-09-04T08:00:01Z

To be used in order to create foreign mappings. This is based on the ZONE_DEVICE facility which is used by persistent memory devices in order to create struct pages and kernel virtual mappings for the IOMEM areas of such devices. Note that on kernels without support for ZONE_DEVICE Xen will fallback to use ballooned pages in order to create foreign mappings. The newly added helpers use the same parameters as the existing {alloc/free}_xenballooned_pages functions, which allows for in-place replacement of the callers. Once a memory region has been added to be used as scratch mapping space it will no longer be released, and pages returned are kept in a linked list. This allows to have a buffer of pages and prevents resorting to frequent additions and removals of regions. If enabled (because ZONE_DEVICE is supported) the usage of the new functionality untangles Xen balloon and RAM hotplug from the usage of unpopulated physical memory ranges to map foreign pages, which is the correct thing to do in order to avoid mappings of foreign pages depend on memory hotplug. Note the driver is currently not enabled on Arm platforms because it would interfere with the identity mapping required on some platforms. Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20200901083326.21264-4-roger.pau@citrix.com Signed-off-by: Juergen Gross

block: pass page to xen_biovec_phys_mergeable

2019-04-01T18:11:13Z

xen_biovec_phys_mergeable() only needs .bv_page of the 2nd bio bvec for checking if the two bvecs can be merged, so pass page to xen_biovec_phys_mergeable() directly. No function change. Cc: ris Ostrovsky Cc: Juergen Gross Cc: xen-devel@lists.xenproject.org Cc: Omar Sandoval Cc: Christoph Hellwig Reviewed-by: Christoph Hellwig Reviewed-by: Boris Ostrovsky Signed-off-by: Ming Lei Signed-off-by: Jens Axboe

x86/xen: dont add memory above max allowed allocation

2019-02-18T05:52:51Z

Don't allow memory to be added above the allowed maximum allocation limit set by Xen. Trying to do so would result in cases like the following: [ 584.559652] ------------[ cut here ]------------ [ 584.564897] WARNING: CPU: 2 PID: 1 at ../arch/x86/xen/multicalls.c:129 xen_alloc_pte+0x1c7/0x390() [ 584.575151] Modules linked in: [ 584.578643] Supported: Yes [ 584.581750] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.4.120-92.70-default #1 [ 584.590000] Hardware name: Cisco Systems Inc UCSC-C460-M4/UCSC-C460-M4, BIOS C460M4.4.0.1b.0.0629181419 06/29/2018 [ 584.601862] 0000000000000000 ffffffff813175a0 0000000000000000 ffffffff8184777c [ 584.610200] ffffffff8107f4e1 ffff880487eb7000 ffff8801862b79c0 ffff88048608d290 [ 584.618537] 0000000000487eb7 ffffea0000000201 ffffffff81009de7 ffffffff81068561 [ 584.626876] Call Trace: [ 584.629699] [] dump_trace+0x59/0x340 [ 584.635645] [] show_stack_log_lvl+0xea/0x170 [ 584.642391] [] show_stack+0x21/0x40 [ 584.648238] [] dump_stack+0x5c/0x7c [ 584.654085] [] warn_slowpath_common+0x81/0xb0 [ 584.660932] [] xen_alloc_pte+0x1c7/0x390 [ 584.667289] [] pmd_populate_kernel.constprop.6+0x40/0x80 [ 584.675241] [] phys_pmd_init+0x210/0x255 [ 584.681587] [] phys_pud_init+0x1da/0x247 [ 584.687931] [] kernel_physical_mapping_init+0xf5/0x1d4 [ 584.695682] [] init_memory_mapping+0x18d/0x380 [ 584.702631] [] arch_add_memory+0x59/0xf0 Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Signed-off-by: Juergen Gross

xen/pvh: Move Xen specific PVH VM initialization out of common file

2018-12-13T18:41:49Z

We need to refactor PVH entry code so that support for other hypervisors like Qemu/KVM can be added more easily. This patch moves the small block of code used for initializing Xen PVH virtual machines into the Xen specific file. This initialization is not going to be needed for Qemu/KVM guests. Moving it out of the common file is going to allow us to compile kernels in the future without CONFIG_XEN that are still capable of being booted as a Qemu/KVM guest via the PVH entry point. Signed-off-by: Maran Wilson Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky