As supported by the printk() (deliberately made visible in context by
also correcting a mis-indented return statement), "above 4GiB" is meant
here. Avoid comparison with a constant to "escape" Misra rule 7.2
complaints. (Note however that even up-to-date Linux, which is where we
"inherited" this code from, still uses the very same off-by-1 check.)
Fixes: 94ea0622c5 ("x86-64/mmcfg: relax base address restriction")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
While the referenced commit came without any update to the public header
(which doesn't clarify how the upper address bits are used), the
intention looks to have been that bits 12..19 and 40..63 form the pIRQ.
Negative values simply make no sense, and pirq_info() also generally
wants invoking with an unsigned (and not just positive) value.
Since the line was pointed out by Eclair, address Misra rule 7.2 at the
same time, by adding the missing U suffix.
Fixes: 88fccdd11c ("xen: event channel remapping for emulated MSIs")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Some of them aren't liked by Misra rule 7.2; rather than fixing them,
drop the affected ones and a few more that aren't used (anymore). (Note
that e.g. some MSR_K7_* are applicable on K8 and newer as well, so need
retaining.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
There are no callers, and the non-stub implementation is #if 0'd out, with the
internal trying to perform an AML invocation.
There's no plausible way that code is getting un-#if 0'd, so drop it.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule 7.4:
A string literal shall not be assigned to an object unless the object's type
is "pointer to const-qualified char".
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Typedef-ing a naked pointer like this is an anti-pattern which is best
avoided. Furthermore, it's problematic to pass a string literal in a mutable
type. Delete the type entirely, and replace it with a plain 'const char *'.
This highlights two further bugs. acpi_get_table() already had a mismatch in
types between it's declaration and definition, and we have declarations for
acpi_get_handle() and acpi_get_table_header() but no definition at all, nor
any callers.
This fixes violations of MISRA Rule 7.4:
A string literal shall not be assigned to an object unless the object's type
is "pointer to const-qualified char".
and of Rule 8.3:
All declarations of an object or function shall use the same names and type
qualifiers.
and of Rule 8.6:
An identifier with external linkage shall have exactly one external
definition.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule 7.4:
A string literal shall not be assigned to an object unless the object's type
is "pointer to const-qualified char".
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule 7.4:
A string literal shall not be assigned to an object unless the object's type
is "pointer to const-qualified char".
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <jgrall@amazon.com>
The current logic to init the local APIC and the IO-APIC does init the
local APIC LVTERR/ESR before doing any sanitization on the IO-APIC pin
configuration. It's already noted on enable_IO_APIC() that Xen
shouldn't trust the IO-APIC being empty at bootup.
At XenServer we have a system where the IO-APIC 0 is handed to Xen
with pin 0 unmasked, set to Fixed delivery mode, edge triggered and
with a vector of 0 (all fields of the RTE are zeroed). Once the local
APIC LVTERR/ESR is enabled periodic injections from such pin cause the
local APIC to in turn inject periodic error vectors:
APIC error on CPU0: 00(40), Received illegal vector
APIC error on CPU0: 40(40), Received illegal vector
APIC error on CPU0: 40(40), Received illegal vector
APIC error on CPU0: 40(40), Received illegal vector
APIC error on CPU0: 40(40), Received illegal vector
APIC error on CPU0: 40(40), Received illegal vector
That prevents Xen from booting.
Move the masking of the IO-APIC pins ahead of the setup of the local
APIC. This has the side effect of also moving the detection of the
pin where the i8259 is connected, as such detection must be done
before masking any pins.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Change parameter names in function definitions to match the
corresponding delcarations thus fixing violations of MISRA C:2012
Rule 8.3 ("All declarations of an object or function shall use the same
names and type qualifiers").
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
[jb: while there also add const to amd_mcheck_init()]
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 and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
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>
At the moment, we limit the allocation size when creating a domU dtb to
4KB, which is not enough when using a passthrough dtb with several nodes.
Improve the handling by accounting for a dtb bootmodule (if present)
size separately, while keeping 4KB for the Xen generated nodes (still
plenty of space for new nodes). Also, cap the allocation size to 2MB,
which is the max dtb size allowed.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Fix the error path in domain_handle_dtb_bootmodule(), so that the memory
previously mapped is unmapped before returning the error code. This is
because the function shall not make assumptions on the way of handling
its error code in the callers. Today we call panic in case of domU
creation failure, so having memory not unmapped is not a bug, but it can
change.
Similarly, fix prepare_dtb_domU() so that the memory allocated is freed
before returning the error code from domain_handle_dtb_bootmodule().
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
With enabling both CONFIG_UBSAN and CONFIG_IPMMU_VMSA I have got the following
splat when an IOMMU driver tried to setup page tables:
(XEN) ipmmu: /soc/iommu@e67b0000: d1: Set IPMMU context 1 (pgd 0x77fe90000)
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in drivers/passthrough/arm/ipmmu-vmsa.c:558:51
(XEN) left shift of 1048575 by 12 places cannot be represented in type 'int'
(XEN) Xen WARN at common/ubsan/ubsan.c:172
(XEN) ---[ Xen-4.18-unstable arm64 debug=y ubsan=y Tainted: S ]----
...
This points to shifted constant in IMTTLBR0_TTBR_MASK. Fix that by adding
missing 'U' to it.
This should also address MISRA Rule 7.2:
A "u" or "U" suffix shall be applied to all integer constants that
are represented in an unsigned type.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
When mapping BARs for vPCI, it's valid for a BAR mfn_t start to equal the BAR
mfn_t end (i.e. start == end) since end is inclusive. However, pci_check_bar()
currently returns false in this case, which results in Xen not mapping the BAR
in the guest 2nd stage page tables. In this example boot log, Linux has mapped
the BARs in the 1st stage, but since Xen did not map them in the 2nd stage,
Linux encounters a data abort and panics:
[ 2.593300] pci 0000:00:00.0: BAR 0: assigned [mem 0x50008000-0x50008fff]
[ 2.593682] pci 0000:00:00.0: BAR 2: assigned [mem 0x50009000-0x50009fff]
[ 2.594066] pci 0000:00:00.0: BAR 4: assigned [mem 0x5000a000-0x5000afff]
...
[ 2.810502] virtio-pci 0000:00:00.0: enabling device (0000 -> 0002)
(XEN) 0000:00:00.0: not mapping BAR [50008, 50008] invalid position
(XEN) 0000:00:00.0: not mapping BAR [50009, 50009] invalid position
(XEN) 0000:00:00.0: not mapping BAR [5000a, 5000a] invalid position
[ 2.817502] virtio-pci 0000:00:00.0: virtio_pci: leaving for legacy driver
[ 2.817853] virtio-pci 0000:00:00.0: enabling bus mastering
(XEN) arch/arm/traps.c:1992:d0v0 HSR=0x00000093010045 pc=0xffff8000089507d4 gva=0xffff80000c46d012 gpa=0x00000050008012
[ 2.818397] Unable to handle kernel ttbr address size fault at virtual address ffff80000c46d012
...
Adjust the end physical address e to account for the full page when converting
from mfn, at which point s and e cannot be equal, so drop the equality check in
the condition.
Note that adjusting e to account for the full page also increases the accuracy
of the subsequent is_bar_valid check.
Fixes: cc80e2bab0 ("xen/pci: replace call to is_memory_hole to pci_check_bar")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Rahul Singh <rahul.singh@arm.com>
Tested-by: Rahul Singh <rahul.singh@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Fix the right border of the silicon-errata.txt table
Fixes: 1814a626fb ("xen/arm: Update silicon-errata.txt with the Neovers AT erratum")
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
ARRAY_SIZE() makes future maintainance easier and thus less likely for
bugs to occur.
Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This takes care of the issue of APIC errors tending to occur on multiple
cores at once. In turn this tends to causes the error messages to be
merged together, making understanding them difficult.
Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Rather than adding ", " with each printf(), simply include them in the
string initially. This allows converting to strlcat() or other methods
which strictly concatenate, rather than formatting.
Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
In the file 'xen/common/xmalloc_tlsf.c' is not clear how
the commented-out code should interact with the previous statement.
To resolve the MISRA violation generated by the nested comment
a #if .. #endif block with an explanatory comment substitutes
the earlier construct.
In the file 'xen/include/xen/atomic.h' the nested comment has been removed,
since the code sample is already explained by the preceding comment.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
`Tag_cons` is `0` and is meant to be used as the tag argument for
`caml_alloc`/`caml_alloc_small` when constructing a non-empty list.
The empty list is `Val_emptylist` instead, which is really just `Val_int(0)`.
Assigning `0` to a list value like this is equivalent to assigning the naked
pointer `NULL` to the field. Naked pointers are not valid in OCaml 5, however
even in OCaml <5.x any attempt to iterate on the list will lead to a segfault.
The list currently only has an opaque type, so no code would have reason to
iterate on it currently, but we shouldn't construct invalid OCaml values that
might lead to a crash when exploring the type.
`Val_emptylist` is available since OCaml 3.01 as a constant.
Fixes: e5ac68a011 ("x86/hvm: Revert per-domain APIC acceleration support")
Signed-off-by: Edwin Török <edwin.torok@cloud.com>
Acked-by: Christian Lindig <christian.lindig@cloud.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.
Fot the sake of uniformity, the following changes are made:
- add the 'U' suffix to all integer constants before the
'?' operator in 'bitops.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>
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 all first macro's arguments in 'cper.h'
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 and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
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: Tamas K Lengyel <tamas@tklengyel.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 integer constants before the '?' operator
Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com>
Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
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 and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
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 all first macro's arguments in 'boot.c'
- add the 'U' suffix near '0x3fffffff' in 'runtime.c'
Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com>
Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.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 and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com>
Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
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 and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
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 and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
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 and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
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>
This being x86-only right now, and its x86 bits being heavily outdated,
let's no longer enable this by default.
While there also adjust the "help" keyword spelling.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
This document specifies the C language dialect used by Xen and
the assumptions Xen makes on the translation toolchain.
Signed-off-by: Roberto Bagnara <roberto.bagnara@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The headline of MISRA C:2012 Rule 8.3 states that:
"All declarations of an object or function shall use the same names and
type qualifiers".
Change parameter names to meet the following requirements:
1) keep consistency between declarations and the corresponding
definitions thus fixing violations of the Rule 8.3;
2) use the globally-adopted shorthands (e.g., 's' to denote a 'state');
3) keep adjacent declarations consistent with respect to the parameter
names that are used.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Rule 9.4 is non-controversial and we have no violations.
Rule 7.4 is considered a good idea with the caveat that assigning a
string literal to const void is allowed. I added a note to specify it.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Commit 9473d9a241 set the ASK mode without checking if there was a
`vga` option provided in the command line. This breaks existing
behavior, so exit early without changes if `vga` is not present in the
command line.
Fixes: 9473d9a241 ('cmdline: parse multiple instances of the vga option')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Fix invalidate_all_domain_pages() to only attempt to flush the domains
that have IOMMU enabled, otherwise the flush is pointless.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Parse all instances of the vga= option on the command line, in order
to always enforce the last selection on the command line.
Note that it's not safe to parse just the last occurrence of the vga=
option, as then a command line with `vga=current vga=keep` would
result in current being ignored.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Only initialize StdOut if the current StdOut mode is unusable. This
avoids forcefully switching StdOut to the maximum supported
resolution, and thus very likely changing the GOP mode without having
first parsed the command line options.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Introduce support for passing the command line to the efi_multiboot2()
helper, and parse the vga= option if present.
Add support for the 'gfx' and 'current' vga options, ignore the 'keep'
option, and print a warning message about other options not being
currently implemented.
Note that the multboot2 command line string must always be
zero-terminated according to the multiboot2 specification, and hence
there's no need to pass the string size to efi_multiboot2().
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
talloc_vasprintf() has a va_list type parameter, so this type needs to
be defined (independent of the particular libc implementation).
Fixes: 63b6419d2a ("tools/xenstore: split out rest of live update control code")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
microcode_update_one() currently assumes all microcode handlers are set or
none are. That won't be the case in a future patch, as apply_microcode()
may not be set while the others are. Hence, this patch allows reading the
microcode revision even if updating it is unavailable.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Xen uses the stdint types. Rearrange the types headers to define the
compatibility __{u,s}$N types in terms of the stdint types, not the other way
around.
All supported compilers on architectures other than x86 support the stdint
__*_TYPE__ macros. Move these into a new xen/stdint.h to avoid them being
duplicated in each architecture. For the very old x86 compilers, synthesize
suitable types using GCC internals.
This cleanup has the side effect of removing all use of the undocumented
__signed__ GCC keyword. This is a vestigial remnant of `gcc -traditional`
mode for dialetcs of C prior to the introduction of the signed keyword.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
We're about to rearrange the common and arch types.h split. While most
users already include <xen/types.h>, a few do not and some files fail to
compile as a result.
Almost all logic is going to have types very early in the include chain. Drop
the include entirely from C files, and swap to the common types.h in headers.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
It was previously noted that CALL/BUG is a weird combination, but there is
good reason to use this pattern.
Introduce an explicit tailcall macro make it clearer in context.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
On Arm, it is not possible to use ACPI without UEFI. In fact disabling
UEFI but not ACPI will lead to a compilation error:
ld: prelink.o: in function `acpi_os_get_root_pointer':
/builds/xen-project/people/andyhhp/xen/xen/drivers/acpi/osl.c:73:
undefined reference to `efi'
/builds/xen-project/people/andyhhp/xen/xen/drivers/acpi/osl.c:73:(.init.text+0x8ac0):
relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against
undefined symbol `efi'
So make the dependency clear in the Kconfig.
This was spotted by the randconfig build in gitlab CI.
Fixes: 12314be574 ("xen/arm: make ARM_EFI selectable for Arm64")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
In the file `xen/drivers/passthrough/arm/smmu-v3.c' there are a few occurrences
of nested '//' character sequences inside C-style comment blocks, which violate
Rule 3.1.
The patch aims to resolve those by replacing the nested comments with
equivalent constructs that do not violate the rule.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Rahul Singh <rahul.singh@arm.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Jan Beulich
Andrew Cooper
Roger Pau Monné
Federico Serafini
Gianluca Luparini
Michal Orzel
Oleksandr Tyshchenko
Stewart Hildebrand
Luca Fancellu
Elliott Mitchell
Nicola Vetrini
Edwin Török
Stefano Stabellini
Roberto Bagnara
Alejandro Vallejo
Julien Grall