The xl subcommands are generic, but only built when
LIBXL_HAVE_NO_SUSPEND_RESUME is false. Currently that is only x86, so
list them there.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
Rule 2.1 states: "A project shall not contain unreachable code".
The placement of the loop after "out_unmap" can be moved earlier
in order to avoid the unconditional return to be marked as a cause of
unreachability for the loop, as this is a consequence of
"__builtin_unreachable" being configured in ECLAIR as being deliberately
unreachable, and therefore not reported as causing the code after the
"out_unmap" label to be unreachable.
Replacing one instance of "goto out_unmap" with the loop avoids
considering the unconditional return at the end of the function as a cause
of unreachability, while preserving the semantics of the function.
No functional change intended.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Fields of anonymous structs/unions may not be part of an initializer for
rather old gcc (4.6 and earlier).
Fixes: 49a068471d ("x86/fpu: Rework fpu_setup_fpu() uses to split it in two")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Move the current setup_frametable_mappings implementation to
arm/mmu under a new file mm.c, this implementation depends on
virtual memory and won't be used as it is for MPU systems.
Take the occasion to fix code style issues related to the line
length.
Moved also frametable_virt_end since it is used only on MMU
systems.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Currently the arm code uses __vmap function in few parts to map
physically contiguous pages, vmap_contig was introduced recently
and does the same because it's a wrapper for __vmap, so use the
latter instead of the direct __vmap function.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Move some extern declarations related to MMU structures and define
from asm/setup.h to asm/mmu/setup.h, in order to increase encapsulation
and allow the MPU part to build, since it has no clue about them.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
When HAS_VMAP is disabled, the xv{malloc,zalloc,...} functions
should fall back to the simple x{malloc,zalloc,...} variant,
implement that because MPU systems won't have virtual memory.
Additionally remove VMAP_VIRT_START from vmap.h guards since
MPU systems won't have it defined.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In Xen, SMMU subsystem is supported for MMU system only. The reason being SMMU
driver uses the same page tables as MMU.
Thus, we make it dependent on CONFIG_MMU.
Signed-off-by: Penny Zheng <Penny.Zheng@arm.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
CONFIG_EARLY_UART_SIZE is introduced to let user provide physical size of
early UART. Unlike MMU where we map a page in the virtual address space,
here we need to know the exact physical size to be mapped.
As VA == PA in case of MPU, the memory layout follows exactly the hardware
configuration. As a consequence, we set EARLY_UART_VIRTUAL_ADDRESS as physical
address.
EARLY_UART_BASE_ADDRESS and EARLY_UART_SIZE should be aligned to the minimum
size of MPU region (ie 64 bits) as per the hardware restrictions. Refer ARM
DDI 0600A.d ID120821 A1.3 "A minimum protection region size of 64 bytes.".
UART is mapped as nGnRE region (as specified by ATTR=100 , refer G1.3.13,
MAIR_EL2, "---0100 Device memory nGnRE"). Also, it is mapped as outer shareable,
RW at EL2 only and execution of instructions from the region is not permitted.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
The xl command doesn't provide suspend/resume, so add them :
xl suspend <Domain>
xl resume <Domain>
This patch follows a discussion on XenDevel: when you want the
virtualized equivalent of "sleep"-ing a host, it's better to
suspend/resume than to pause/unpause a domain.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Suggested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Cyril Rébert (zithro) <slack@rabbit.lu>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Commit a14593e399 extended BOOTINFO_{ACPI,SHMEM}_INIT initializers
list with a new 'type' member but forgot to add trailing commas (they
were present before). This results in a build failure when building
with CONFIG_ACPI=y and CONFIG_STATIC_SHM=y:
./include/xen/bootfdt.h:155:5: error: request for member 'shmem' in something not a structure or union
155 | .shmem.common.max_banks = NR_SHMEM_BANKS, \
| ^
./include/xen/bootfdt.h:168:5: note: in expansion of macro 'BOOTINFO_SHMEM_INIT'
168 | BOOTINFO_SHMEM_INIT \
| ^~~~~~~~~~~~~~~~~~~
common/device-tree/bootinfo.c:22:39: note: in expansion of macro 'BOOTINFO_INIT'
22 | struct bootinfo __initdata bootinfo = BOOTINFO_INIT;
Fixes: a14593e399 ("xen/device-tree: Allow region overlapping with /memreserve/ ranges")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
xc_cpuid_apply_policy() provides compatibility for migration of a pre-4.14 VM
where no CPUID data was provided in the stream.
It guesses the various max-leaf limits, based on what was true at the time of
writing, but this was not correctly adapted when speculative security issues
forced the advertisement of new feature bits. Of note are:
* LFENCE-DISPATCH, in leaf 0x80000021.eax
* BHI-CTRL, in leaf 0x7[2].edx
In both cases, a VM booted on a security-patched Xen 4.13, and then migrated
on to any newer version of Xen on the same or compatible hardware would have
these features stripped back because Xen is still editing the cpu-policy for
sanity behind the back of the toolstack.
For VMs using BHI_DIS_S to mitigate Native-BHI, this resulted in a failure to
restore the guests MSR_SPEC_CTRL setting:
(XEN) HVM d7v0 load MSR 0x48 with value 0x401 failed
(XEN) HVM7 restore: failed to load entry 20/0 rc -6
Fixes: e9b4fe2636 ("x86/cpuid: support LFENCE always serialising CPUID bit")
Fixes: f3709b15fc ("x86/cpuid: Infrastructure for cpuid word 7:2.edx")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Secondary cpus initialization is not yet supported. Thus, we print an
appropriate message and put the secondary cpus in WFE state.
And we introduce to BUILD_BUG_ON to prevent users using from building Xen
on multiprocessor based MPU systems.
In Arm, there is no clean way to disable SMP. As of now, we wish to support
MPU on UNP only. So, we have defined the default range of NR_CPUs to be 1 for
MPU.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
After the regions have been created, now we enable the MPU. For this we disable
the background region so that the new memory map created for the regions take
effect. Also, we treat all RW regions as non executable and the data cache is
enabled.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Define enable_boot_cpu_mm() for the Armv8-R AArch64.
Like boot-time page table in MMU system, we need a boot-time MPU protection
region configuration in MPU system so Xen can fetch code and data from normal
memory.
To do this, Xen maps the following sections of the binary as separate regions
(with permissions) :-
1. Text (Read only at EL2, execution is permitted)
2. RO data (Read only at EL2)
3. RO after init data and RW data (Read/Write at EL2)
4. Init Text (Read only at EL2, execution is permitted)
5. Init data and BSS (Read/Write at EL2)
Before creating a region, we check if the count exceeds the number defined in
MPUIR_EL2. If so, then the boot fails.
Also we check if the region is empty or not. IOW, if the start and end address
are same, we skip mapping the region.
To map a region, Xen uses the PRBAR_EL2, PRLAR_EL2 and PRSELR_EL2 registers.
One can refer to ARM DDI 0600B.a ID062922 G1.3 "General System Control
Registers", to get the definitions of these registers. Also, refer to G1.2
"Accessing MPU memory region registers", the following
```
The MPU provides two register interfaces to program the MPU regions:
- Access to any of the MPU regions via PRSELR_ELx, PRBAR<n>_ELx, and
PRLAR<n>_ELx.
```
We use the above mechanism to create the MPU memory regions.
Also, the compiler needs the flag ("-march=armv8-r") in order to build Xen for
Armv8-R AArch64 MPU based systems. There will be no need for us to explicitly
define MPU specific registers.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
All the code in arch/arm32/lib/ where copied from Linux 3.16
and never re-synced since then.
A few years ago, Linux got rid of __memzero() because the implementation
is very similar to memset(p,0,n) and the current use of __memzero()
interferes with optimization. See full commit message from Linux below.
So it makes sense to get rid of __memzero in Xen as well.
From ff5fdafc9e9702846480e0cea55ba861f72140a2 Mon Sep 17 00:00:00 2001
From: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Fri, 19 Jan 2018 18:17:46 +0100
Subject: [PATCH] ARM: 8745/1: get rid of __memzero()
The __memzero assembly code is almost identical to memset's except for
two orr instructions. The runtime performance of __memset(p, n) and
memset(p, 0, n) is accordingly almost identical.
However, the memset() macro used to guard against a zero length and to
call __memzero at compile time when the fill value is a constant zero
interferes with compiler optimizations.
Arnd found tha the test against a zero length brings up some new
warnings with gcc v8:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82103
And successively rremoving the test against a zero length and the call
to __memzero optimization produces the following kernel sizes for
defconfig with gcc 6:
text data bss dec hex filename
12248142 6278960 413588 18940690 1210312 vmlinux.orig
12244474 6278960 413588 18937022 120f4be vmlinux.no_zero_test
12239160 6278960 413588 18931708 120dffc vmlinux.no_memzero
So it is probably not worth keeping __memzero around given that the
compiler can do a better job at inlining trivial memset(p,0,n) on its
own. And the memset code already handles a zero length just fine.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ff5fdafc9e97
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
The tools infrastructure used to build livepatches for Xen
(livepatch-build-tools) consumes some DWARF debug information present in
xen-syms to generate a livepatch (see livepatch-build script usage of readelf
-wi).
The current Kconfig defaults however will enable LIVEPATCH without DEBUG_INFO
on release builds, thus providing a default Kconfig selection that's not
suitable for livepatch-build-tools even when LIVEPATCH support is enabled,
because it's missing the DWARF debug section.
Fix by defaulting DEBUG_INFO to enabled when LIVEPATCH is.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Consider also "Display controller" an IGD, not only "VGA compatible
controller". Specifically, IGD on Raptor Lake has 0x038000 class, not
0x030000.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Due to presumably a copy-and-paste mistake VPBROADCASTMB2Q was tested
twice instead.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The reg-reg forms should cause #UD; they come into existence only with
APX, where MOVBE also extends BSWAP (for the latter not being "eligible"
to a REX2 prefix).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
When a VM transitioned to LIBXL_SHUTDOWN_REASON_SUSPEND, the xl daemon
was exiting as 0 = DOMAIN_RESTART_NONE "No domain restart".
Later, when the VM actually shutdown, the missing xl daemon meant the
domain wasn't cleaned up properly.
Add a new DOMAIN_RESTART_SUSPENDED to handle the case. The xl daemon
keeps running to react to future shutdown events.
The domain death event needs to be re-enabled to catch subsequent
events. The libxl_evgen_domain_death is moved from death_list to
death_reported, and then it isn't found on subsequent iterations through
death_list. We enable the new event before disabling the old event, to
keep the xenstore watch active. If it is unregistered and
re-registered, it'll fire immediately for our suspended domain which
will end up continuously re-triggering.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Rename the file containing uart_init() to enable reuse across other
architectures that utilize device trees or SPCR tables to locate UART
information.
After locating UART data, {acpi}_device_init() is called to initialize
the UART.
arm_uart_init() is renamed to uart_init() to be reused by other
architectures.
A new configuration option, CONFIG_GENERIC_UART_INIT, is introduced,
currently available only for Arm. Enabling CONFIG_UART_INIT on additional
architectures will require additional functionality, such as device tree
mapping and unflattening, etc.
arm-uart.c is removed from "ARM (W/ VIRTUALIZATION EXTENSIONS) ARCHITECTURE"
section in the MAINTAINERS file, as it is no longer Arm-specific and can
now be maintained by maintainers of other architectures.
Use GENERIC_UART_INIT for CONFIG_ARM by adding `select GENERIC_UART_INIT`
to CONFIG_ARM.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved-memory node, in this case the
current code will stop Xen to boot since it will find that the
latter range is clashing with the already recorded /memreserve/
ranges.
Furthermore, u-boot lists boot modules ranges, such as ramdisk,
in the /memreserve/ part and even in this case this will prevent
Xen to boot since it will see that the module memory range that
it is going to add in 'add_boot_module' clashes with a /memreserve/
range.
When Xen populate the data structure that tracks the memory ranges,
it also adds a memory type described in 'enum membank_type', so
in order to fix this behavior, allow overlapping with the /memreserve/
ranges in the 'check_reserved_regions_overlap' function when a flag
is set.
In order to implement this solution, there is a distinction between
the 'struct membanks *' handled by meminfo_overlap_check(...) that
needs to be done, because the static shared memory banks doesn't have
a usable bank[].type field and so it can't be accessed, hence now
the 'struct membanks_hdr' have a 'enum region_type type' field in order
to be able to identify static shared memory banks in meminfo_overlap_check(...).
While there, set a type for the memory recorded using meminfo_add_bank()
from efi-boot.h.
Fixes: 53dc37829c ("xen/arm: Add DT reserve map regions to bootinfo.reserved_mem")
Reported-by: Shawn Anastasio <sanastasio@raptorengineering.com>
Reported-by: Grygorii Strashko <grygorii_strashko@epam.com>
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
While working on console forwarding for virtual NS8250 I stepped into
flask_domain_alloc_security()
where break statement was missing in default case which violates MISRA
rule 16.4.
Fixed everywhere in hooks.c.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Add a call to end_boot_allocator() in start_xen() to finalize the
boot memory allocator, moving free pages to the domain sub-allocator.
After initializing the memory subsystem, update `system_state` from
`SYS_STATE_early_boot` to `SYS_STATE_boot`, signifying the end of the
early boot phase.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Call vm_init() to initialize the VMAP_DEFAULT virtual range.
To support this, introduce the populate_pt_range() and
arch_vmap_virt_end() functions, which are used by
vm_init()->vm_init_type().
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Introduce the implementation of setup_mm(), which includes:
1. Adding all free regions to the boot allocator, as memory is needed
to allocate page tables used for frame table mapping.
2. Calculating RAM size and the RAM end address.
3. Setting up direct map mappings from each RAM bank and initialize
directmap_virt_start to keep simple VA <-> PA translation and if
RAM_start isn't properly aligned then add an additional alignment
to directmap_virt_start to be properly aligned with RAM
start to use more superpages to reduce pressure on the TLB.
4. Setting up frame table mappings for range [ram_start, ram_end)
and initialize properly frametable_virt_start to have simplified
version of mfn_to_page() and page_to_mfn().
5. Setting up max_page.
Introduce DIRECTMAP_VIRT_END to have a convient way to do some basic
checks of address ranges.
Based on the memory layout mentioned in config.h, DIRECTMAP_SIZE is
expected to be inclusive, i.e., [DIRECTMAP_VIRT_START, DIRECTMAP_VIRT_END].
Therefore, DIRECTMAP_SIZE is updated to reflect this.
Update virt_to_maddr() to use introduced directmap_virt_start and newly
introduced DIRECTMAP_VIRT_END.
Implement maddr_to_virt() function to convert a machine address
to a virtual address. This function is specifically designed to be used
only for the DIRECTMAP region, so a check has been added to ensure that
the address does not exceed DIRECTMAP_VIRT_END.
After the introduction of maddr_to_virt() the following linkage error starts
to occur and to avoid it share_xen_page_with_guest() stub is added:
riscv64-linux-gnu-ld: prelink.o: in function `tasklet_kill':
/build/xen/common/tasklet.c:176: undefined reference to
`share_xen_page_with_guest'
riscv64-linux-gnu-ld: ./.xen-syms.0: hidden symbol `share_xen_page_with_guest'
isn't defined riscv64-linux-gnu-ld: final link failed: bad value
Despite the linkger fingering tasklet.c, it's trace.o which has the undefined
refenrece:
$ find . -name \*.o | while read F; do nm $F | grep share_xen_page_with_guest &&
echo $F; done
U share_xen_page_with_guest
./xen/common/built_in.o
U share_xen_page_with_guest
./xen/common/trace.o
U share_xen_page_with_guest
./xen/prelink.o
Looking at trace.i, there is call of share_xen_page_with_guest() but in case of
when maddr_to_virt() is defined as stub ("BUG_ON(); return NULL;") DCE happens and
the code is just eliminated.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Before starting to alter its properties, restrict the function's
visibility. The only external user is mem-paging, which we can
accommodate by different means.
Also move the function up in its source file, so we won't need to
forward-declare it. Constify its parameter at the same time.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
First instroduce a manifest constant, to avoid open-coding 64 in several
places. Then use this constant to bound the allocation.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
We have libxl_ctxt.page_size for this purpose; use it to eliminate a
latent buffer overrun.
Fixes: 14c0d328da ("libxl/acpi: Build ACPI tables for HVMlite guests")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
The current code in pv_domain_initialise() populates the L3 slot used for the
GDT/LDT, however that's not needed, since the create_perdomain_mapping() in
pv_create_gdt_ldt_l1tab() will already take care of allocating an L2 and
populating the L3 entry if not present.
No functional change intended.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The hardware domain is expected to add a PF first before adding
associated VFs. If adding happens out of order, print a warning and
return an error. Drop the recursive call to pci_add_device().
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In commit 4f78438b45 ("vpci: use per-domain PCI lock to protect vpci
structure") a lock was moved from allocate_and_map_msi_pirq() to the
caller and changed from pcidevs_lock() to read_lock(&d->pci_lock).
However, one call path wasn't updated to reflect the change, leading to
a failed assertion observed under the following conditions:
* PV dom0
* Debug build (CONFIG_DEBUG=y) of Xen
* There is an SR-IOV device in the system with one or more VFs enabled
* Dom0 has loaded the driver for the VF and enabled MSI-X
(XEN) Assertion 'd || pcidevs_locked()' failed at drivers/passthrough/pci.c:535
(XEN) ----[ Xen-4.20-unstable x86_64 debug=y Not tainted ]----
...
(XEN) Xen call trace:
(XEN) [<ffff82d040284da8>] R pci_get_pdev+0x4c/0xab
(XEN) [<ffff82d040344f5c>] F arch/x86/msi.c#read_pci_mem_bar+0x58/0x272
(XEN) [<ffff82d04034530e>] F arch/x86/msi.c#msix_capability_init+0x198/0x755
(XEN) [<ffff82d040345dad>] F arch/x86/msi.c#__pci_enable_msix+0x82/0xe8
(XEN) [<ffff82d0403463e5>] F pci_enable_msi+0x3f/0x78
(XEN) [<ffff82d04034be2b>] F map_domain_pirq+0x2a4/0x6dc
(XEN) [<ffff82d04034d4d5>] F allocate_and_map_msi_pirq+0x103/0x262
(XEN) [<ffff82d04035da5d>] F physdev_map_pirq+0x210/0x259
(XEN) [<ffff82d04035e798>] F do_physdev_op+0x9c3/0x1454
(XEN) [<ffff82d040329475>] F pv_hypercall+0x5ac/0x6af
(XEN) [<ffff82d0402012d3>] F lstar_enter+0x143/0x150
In read_pci_mem_bar(), the VF obtains the struct pci_dev pointer for its
associated PF to access the vf_rlen array. This array is initialized in
pci_add_device() and is only populated in the associated PF's struct
pci_dev.
Access the vf_rlen array via the link to the PF, and remove the
troublesome call to pci_get_pdev().
Fixes: 4f78438b45 ("vpci: use per-domain PCI lock to protect vpci structure")
Reported-by: Teddy Astie <teddy.astie@vates.tech>
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Add links between a VF's struct pci_dev and its associated PF struct
pci_dev.
The hardware domain is expected to remove the associated VFs before
removing the PF. If removal happens out of order, print a warning and
return an error. This means that VFs can only exist with an associated
PF.
Additionally, if the hardware domain attempts to remove a PF with VFs
still present, mark the PF and VFs broken, because Linux Dom0 has been
observed to not respect the error returned.
Move the calls to pci_get_pdev() and pci_add_device() down to avoid
dropping and re-acquiring the pcidevs_lock().
Check !pdev->pf_pdev before adding the VF to the list to guard against
adding it multiple times.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This seems to have been introduced in commit f8beb54e24 ("Disable PIE/SSP
features when building Xen, if GCC supports them.") in 2004.
However, neither GCC nor Clang appear to have ever supported taking the
negated form of -fstack-protector-all, meaning this been useless since its
introduction.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Sphinx 5.0 and newer objects to language = None. Switch to 'en'.
Also update the copyright year. Use %Y to avoid this problem in the future,
and provide compatibility for versions of Sphinx prior to 8.1 which don't
support the syntax.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Sphinx complains:
docs/fusa/index.rst:6: WARNING: toctree contains reference to nonexisting document 'fusa/reqs'
docs/fusa/reqs/index.rst:6: WARNING: toctree contains reference to nonexisting document 'fusa/reqs/market-reqs'
docs/fusa/reqs/index.rst:6: WARNING: toctree contains reference to nonexisting document 'fusa/reqs/product-reqs'
docs/fusa/reqs/index.rst:6: WARNING: toctree contains reference to nonexisting document 'fusa/reqs/design-reqs/arm64'
docs/fusa/index.rst: WARNING: document isn't included in any toctree
docs/fusa/reqs/design-reqs/arm64/generic-timer.rst: WARNING: document isn't included in any toctree
docs/fusa/reqs/design-reqs/arm64/sbsa-uart.rst: WARNING: document isn't included in any toctree
docs/fusa/reqs/index.rst: WARNING: document isn't included in any toctree
docs/fusa/reqs/market-reqs/reqs.rst: WARNING: document isn't included in any toctree
docs/fusa/reqs/product-reqs/arm64/reqs.rst: WARNING: document isn't included in any toctree
Fix the toctrees.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Introduce intc_dt_preinit() in the common codebase, as it is not
architecture-specific and can be reused by both PPC and RISC-V.
This function identifies the node with the interrupt-controller property
in the device tree and calls device_init() to handle architecture-specific
initialization of the interrupt controller.
Make minor adjustments compared to the original ARM implementation of
gic_dt_preinit():
- Remove the local rc variable in gic_dt_preinit() since it is only used once.
- Change the prefix from gic to intc to clarify that the function is not
specific to ARM’s GIC, making it suitable for other architectures as well.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Do not return early in the PVH/HVM case, so that the number of pIRQs is also
printed. While PVH dom0 doesn't have access to the hypercalls to manage pIRQs
itself, nor the knowledge to do so, pIRQs are still used by Xen to map and
bind interrupts to a PVH dom0 behind its back. Hence the pIRQ limit is still
relevant for a PVH dom0.
Fixes: 17f6d398f7 ('cmdline: document and enforce "extra_guest_irqs" upper bounds')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The current calculation of PV dom0 pIRQs uses:
n = min(fls(num_present_cpus()), dom0_max_vcpus());
The usage of fls() is wrong, as num_present_cpus() already returns the number
of present CPUs, not the bitmap mask of CPUs.
Fix by removing the usage of fls().
Fixes: 7e73a6e7f1 ('have architectures specify the number of PIRQs a hardware domain gets')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The arm32 version of init_secondary_pagetables() will soon be re-used
for arm64 as well where the root table starts at level 0 rather than level 1.
So rename 'first' to 'root'.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
for_each_set_bit()'s use of a double for loop had an accidental bug with a
break in the inner loop leading to an infinite outer loop.
Adjust for_each_set_bit() to avoid this behaviour, and add extend
test_for_each_set_bit() with a test case for this.
Fixes: ed26376f20 ("xen/bitops: Introduce for_each_set_bit()")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
There's no point rescanning if we didn't load something new. Take the
opportunity to make the comment a bit more concise.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Following commit cd7cc5320b ("x86/boot: add start and size fields to struct
boot_module"), bootstrap_map*() works as soon as boot_info is populated.
Resolve the TODO, and move microcode loading to be the eariest action after
establishing a console.
A sample boot now looks like:
(XEN) Xen version 4.20-unstable (andrew@eng.citrite.net) (gcc (Debian 12.2.0-14) 12.2.0) debug=y Tue Nov 19 21:44:46 GMT 2024
(XEN) Latest ChangeSet: Wed Dec 6 21:54:55 2023 git:1ab612848a23
(XEN) build-id: 52fe616d1b3a2a2cb44775815507d02cca73315d
(XEN) CPU Vendor: AMD, Family 25 (0x19), Model 1 (0x1), Stepping 1 (raw 00a00f11)
(XEN) BSP microcode revision: 0x0a001137
(XEN) microcode: CPU0 updated from revision 0xa001137 to 0xa0011d5, date = 2024-02-23
(XEN) Bootloader: GRUB 2.06
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Eclair reports a Misra Rule 8.4 violation; that do_mca() can't see it's
declaration. It turns out that this is a consequence of do_mca() being
PV-only, and the declaration being compiled out in !PV builds.
Therefore, arrange for do_mca() to be compiled out in !PV builds. This in
turn requires a number of static functions to become __maybe_unused.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Rebuild rolling release containers when XEN_CI_REBUILD_CONTAINERS is
set. This is to be use with a scheduled pipeline.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This allow to change the registry used for container in a single
place, and could be controlled via other mean.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Jason Andryuk