The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type.
For the sake of uniformity, the following change is made:
- add the 'U' suffix to switch cases in 'cpuid.c'
Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com>
Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type.
For the sake of uniformity, the following change is made:
- add 'U' suffixes to 'mask16' in 'stdvga.c'
Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com>
Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type.
For the sake of uniformity, the following changes are made:
- add the 'U' suffix to macros near
'CPU_BASED_ACTIVATE_SECONDARY_CONTROLS' and
'SECONDARY_EXEC_NOTIFY_VM_EXITING' macros in 'vmcs.h'
- add the 'U' suffix to macros near 'INTR_INFO_VALID_MASK'
macro in 'vmx.h'
Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com>
Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It is very helpful to see domain id why analyzing xenstored
traces. Especially when you are trying to understand which exactly
domain performs an action.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
[jgrall: Use %u rather than %d]
Signed-off-by: Julien Grall <jgrall@amazon.com>
On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 cores),
the physical memory regions are:
DRAM memory regions:
Node[0] Region[0]: 0x000080000000 - 0x0000ffffffff
Node[0] Region[1]: 0x080000000000 - 0x08007fffffff
Node[0] Region[2]: 0x080100000000 - 0x0807ffffffff
The UEFI loads Xen hypervisor and DTB into the high memory, the kernel
and ramdisk images are loaded into the low memory space:
(XEN) MODULE[0]: 00000807f6df0000 - 00000807f6f3e000 Xen
(XEN) MODULE[1]: 00000807f8054000 - 00000807f8056000 Device Tree
(XEN) MODULE[2]: 00000000fa834000 - 00000000fc5de1d5 Ramdisk
(XEN) MODULE[3]: 00000000fc5df000 - 00000000ffb3f810 Kernel
In this case, the Xen binary is loaded above 8TB, which exceeds the
maximum supported identity map space of 2TB in Xen. Consequently, the
system fails to boot.
This patch enlarges identity map space to 10TB, allowing module loading
within the range of [0x0 .. 0x000009ff_ffff_ffff].
Fixes: 1c78d76b67 ("xen/arm64: mm: Introduce helpers to prepare/enable/disable")
Reported-by: Alexey Klimov <alexey.klimov@linaro.org>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Tested-by: Henry Wang <Henry.Wang@arm.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Xen maps the virtual memory space starting from L0 slot 4, so it's open
coded for macros with the offset '4'.
For more readable, add a new macro XEN_VM_MAPPING which defines the
start slot for Xen virtual memory mapping, and all virtual memory
regions are defined based on it.
Acked-by: Julien Grall <jgrall@amazon.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
The documentation change was meant to be part of 9b807e23e7
("xen/arm32: head: Replace load_paddr with adr_l when they are
equivalent") but was missed when preparing to commit.
So add it separately.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Before the MMU is turned on, PC uses physical address. Thus, one can use adr_l
instead of load_paddr to obtain the physical address of a symbol.
The only exception (for this replacement) is create_table_entry() which is
called before and after MMU is turned on.
Also, in lookup_processor_type() "r10" is no longer used. The reason being
__lookup_processor_type uses adr_l (thus r10 is no longer used to obtain the
physical address offset). Consequently, there is no need to save/restore r10.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
[jgrall: Reword comment on top of __lookup_processor_type]
Signed-off-by: Julien Grall <jgrall@amazon.com>
The macro load_paddr() requires to know the offset between the
physical location of Xen and the virtual location.
When using the MPU, x20 will always be 0. Rather than wasting
a register for a compile-time constant value, it would be best if
we can avoid using load_paddr() altogether in the common head.S code.
The current use of load_paddr() are equivalent to adr_l() because
the MMU is off.
All the use of load_paddr() in arm64/head.S are now replaced with
adr_l(). With that, load_paddr() can now be moved in arm64/mmu/head.S.
For now, x20 is still unconditionally set. But this could change
in the future if needed.
Signed-off-by: Julien Grall <julien@xen.org>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Currently, Xen doesn't check the status property of memory/reserved
memory nodes, which may lead to the following issues:
- If a memory node has a status "disabled" it implies that it should
not be used. Xen does not handle the status property for the memory
node and ends up using it.
- If a reserved memory node has a status "disabled", it means that this
region is no longer reserved and can be used, but the "disabled"
status is not handled by Xen.
Xen passes the intact device tree binding of the reserved memory nodes
to Dom0 and creates a memory node to cover reserved regions. Disabled
reserved memory nodes are ignored by the Dom0 Linux kernel, thus the
Dom0 Linux kernel will continue to allocate pages from such a region.
On the other hand, since the disabled status is not handled by Xen,
the disabled reserved memory regions are excluded from the page
management in Xen which results in Xen being unable to obtain the
corresponding MFN, in the end, Xen reports error like:
(XEN) arch/arm/p2m.c:2202: d0v0: Failing to acquire the MFN 0x1a02dc
This patch introduces a function device_tree_node_is_available(). If it
detects a memory node is not enabled, Xen will not add the memory region
into the memory lists. In the end, this avoids to generate the memory
node for the disabled memory regions sent to the kernel and the kernel
cannot use the disabled memory nodes any longer.
Since this patch adds checking device node's status in the
device_tree_get_meminfo() function, except it checks for memory nodes
and reserved memory nodes, it also supports status for static memory
and static heap.
Suggested-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
The purpose of this macro is to encapsulate the well-known expression
'x & -x' that in 2's complement architectures on unsigned integers will
give a mask where only the least significant nonzero bit of 'x' is set,
or 0 if none are set.
A deviation for ECLAIR is also introduced.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Add missing parameter names. While there also switch a type name. No
functional change.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Add 21.1 and 21.2, with a longer comment to explain how strategy with
leading underscores and why we think we are safe today.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Add MISRA C Rules 11.1, 11.2, 11.3, 11.6 as discussed.
Explicitly add in the notes that conversions to integer types are
permitted if the destination type has enough bits to hold the entire
value. GCC gives enough guarantees in terms of preserving the bit
content in such situations.
Also allow for bool conversions (e.g. to check if a function point is
valid).
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
As of d58a509e01 ("build,x86: remove the need for build32.mk") we
don't need to use non-standard #include forms anymore in the sources for
the boot code helper blobs. The only place where this kind of #include
needs to remain (for the time being) is mkelf32.c.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
These macros were hiding that the ops are not zero-initialized by the
toolstack. This is needlessly opaque for something so simple, so this patch
removes them and replaces them with explicit zero-initialising versions.
The patch also removes PHYSDEV_OP from there, as that seems to be an old
dead macro.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Before speculation defences, some paths in Xen could genuinely get away with
being IRQs-on at entry. But XPTI invalidated this property on most paths, and
attempting to maintain it on the remaining paths was a mistake.
Fast forward, and DO_SPEC_CTRL_COND_IBPB (protection for AMD BTC/SRSO) is not
IRQ-safe, running with IRQs enabled in some cases. The other actions taken on
these paths happen to be IRQ-safe.
Make entry_int82() and int80_direct_trap() unconditionally Interrupt Gates
rather than Trap Gates. Remove the conditional re-adjustment of
int80_direct_trap() in smp_prepare_cpus(), and have entry_int82() explicitly
enable interrupts when safe to do so.
In smp_prepare_cpus(), with the conditional re-adjustment removed, the
clearing of pv_cr3 is the only remaining action gated on XPTI, and it is out
of place anyway, repeating work already done by smp_prepare_boot_cpu(). Drop
the entire if() condition to avoid leaving an incorrect vestigial remnant.
Also drop comments which make incorrect statements about when its safe to
enable interrupts.
This is XSA-446 / CVE-2023-46836
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
The current setup of the quarantine page tables assumes that the quarantine
domain (dom_io) has been initialized with an address width of
DEFAULT_DOMAIN_ADDRESS_WIDTH (48).
However dom_io being a PV domain gets the AMD-Vi IOMMU page tables levels based
on the maximum (hot pluggable) RAM address, and hence on systems with no RAM
above the 512GB mark only 3 page-table levels are configured in the IOMMU.
On systems without RAM above the 512GB boundary amd_iommu_quarantine_init()
will setup page tables for the scratch page with 4 levels, while the IOMMU will
be configured to use 3 levels only. The page destined to be used as level 1,
and to contain a directory of PTEs ends up being the address in a PTE itself,
and thus level 1 page becomes the leaf page. Without the level mismatch it's
level 0 page that should be the leaf page instead.
The level 1 page won't be used as such, and hence it's not possible to use it
to gain access to other memory on the system. However that page is not cleared
in amd_iommu_quarantine_init() as part of re-initialization of the device
quarantine page tables, and hence data on the level 1 page can be leaked
between device usages.
Fix this by making sure the paging levels setup by amd_iommu_quarantine_init()
match the number configured on the IOMMUs.
Note that IVMD regions are not affected by this issue, as those areas are
mapped taking the configured paging levels into account.
This is XSA-445 / CVE-2023-46835
Fixes: ea38867831 ('x86 / iommu: set up a scratch page in the quarantine domain')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
sphinx-build reports:
docs/designs/launch/hyperlaunch.rst: WARNING: document isn't included in any toctree
docs/designs/launch/hyperlaunch-devicetree.rst: WARNING: document isn't included in any toctree
docs/misc/xen-makefiles/makefiles.rst: WARNING: document isn't included in any toctree
docs/misra/C-language-toolchain.rst: WARNING: document isn't included in any toctree
docs/misra/C-runtime-failures.rst: WARNING: document isn't included in any toctree
docs/misra/documenting-violations.rst: WARNING: document isn't included in any toctree
docs/misra/exclude-list.rst: WARNING: document isn't included in any toctree
docs/misra/xen-static-analysis.rst: WARNING: document isn't included in any toctree
Create an up-to-date index.rst in misra/ create an "unsorted docs" section at
the top level to contain everything else. They can be re-filed at a later
date.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
sphinx-build reports:
docs/misra/exclude-list.rst:47: WARNING: Unexpected indentation.
docs/misra/exclude-list.rst:50: WARNING: Inline emphasis start-string without end-string.
Nested lists require newlines as delimiters, and * either needs escaping, or
put in a literal block.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
sphinx-build reports:
docs/designs/launch/hyperlaunch.rst:111: WARNING: Title underline too short.
docs/designs/launch/hyperlaunch.rst:203: WARNING: Unexpected indentation.
docs/designs/launch/hyperlaunch.rst:216: WARNING: Unexpected indentation.
Nested lists require newlines as delimiters.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
These 3 Kconfig docs were imported from Linux erroneously. They are
GPL-2.0-only in Linux, but have no SPDX tag and were placed in such a way to
be included by the blanket statement saying that all RST files are CC-BY-4.0.
We should not be carrying a shadow copy of these docs. They aren't even wired
into our Sphinx docs, and anyone wanting to refer to Kconfig docs is going to
look at the Linux docs anyway. These, and more docs can be found at:
https://www.kernel.org/doc/html/latest/kbuild/
which also have corrections vs the snapshot we took.
Fixes: f80fe2b34f ("xen: Update Kconfig to Linux v5.4")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Two files are missing SDPX tags, but are covered by the blanketing license
statement in docs/README.sources saying that RST files are CC-BY-4.0
Fixes: 3c911be55f ("docs/misra: document the C dialect and translation toolchain assumptions.")
Fixes: 7211904e09 ("docs/misra: add documentation skeleton for MISRA C:2012 Dir 4.1")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Make function definitions and declarations consistent.
No functional change.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Add missing parameter names and make function declarations and
definitions consistent.
No functional change.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Adjust line to use a hard tab and align using spaces afterwards, instead of
using all spaces.
Fixes: fc3090a47b ('x86/boot: Clear XD_DISABLE from the early boot path')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Platforms which doesn't have HAS_PCI enabled it is needed to
have <asm/pci.h>, which contains only an empty definition of
struct arch_pci_dev (except Arm, it introduces several Arm-specific
functions ).
Also, for architectures (such as PPC or RISC-V) on initial
stages of adding support, it is needed to generate <asm/pci.h>
for only define the mentioned above arch_pci_dev structure.
For the Arm-only stubs (mentioned in <asm/pci.h> for disabled
HAS_PCI and Arm-specific) will be needed
to add <asm/pci.h> directly alongside <xen/pci.h>. Only to
<arm/domain.c> <asm/pci.h> was added.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Much like the other PIC ports, Dom0 has no business touching these. Even
our own uses are somewhat questionable, as the corresponding IO-APIC
code in Linux is enclosed in a CONFIG_EISA conditional; I don't think
there are any x86-64 EISA systems.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Currently exclude-list.json is used by the xen-analysis tool to
remove from the report (cppcheck for now) violations from the
files listed in it, however that list can be used by different
users that might want to exclude some of the files from their
computation for many reasons.
So add a new field that can be part of each entry to link
the tool supposed to consider that exclusion.
Update exclusion_file_list.py to implement the logic and update
the documentation to reflect this change.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Rework the exclusion_file_list.py code to have the function
load_exclusion_file_list() detached from the xen-analysis.py tool,
in a way so that other modules can use the function.
The xen-analysis tool and in particular its module cppcheck_analysis.py
will use a new function cppcheck_exclusion_file_list().
No functional changes are intended.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Make function definitions and declarations consistent. Use "ptr" as
const void* parameter to match the definitions on x86.
No functional change.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
[stefano: drop blank, improve commit message]
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
At the moment, in order to use a different defconfig target than default,
one needs to specify KBUILD_DEFCONFIG=<target> on the command line.
Switch to weak assignment, so that it can be also obtained from
environment similar to other KCONFIG/KBUILD variables.
This change will activate the use of KBUILD_DEFCONFIG variable in CI
build jobs that so far would have had no effect if they didn't match the
default anyway.
Note, that we will deviate from Linux in this regard.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
[stefano: adjust commit message]
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The 'break' the XEN_DOMCTL_set_address_size is unreachable and tools
like Eclair will report as a violation of Misra Rule 2.1.
Furthermore, the nested switch is not very easy to read. So move
out the nested switch in a separate function to improve the
readability and hopefully address the MISRA violation.
Reported-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
To avoid potentially dangerous sign conversions in bitmap_switch, all
the callers of the bitmap_switch macro (which are all within bitmap.h)
should pass an unsigned int as first parameter.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>