Leo Yan [Mon, 24 Jul 2023 08:52:11 +0000 (16:52 +0800)]
docs: Correct name for xen-command-line.pandoc
In the commit d661611d08 ("docs/markdown: Switch to using pandoc, and
fix underscore escaping"), the documentation suffix was changed from
".markdown" to ".pandoc"; however, the reference was missed to update.
This patch updates the documentation name to xen-command-line.pandoc.
Fixes: d661611d08 ("docs/markdown: Switch to using pandoc, and fix underscore escaping") Signed-off-by: Leo Yan <leo.yan@linaro.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
xen/cpu: change parameter name in __cpu_up() declaration
Change parameter name from 'cpunum' to 'cpu' to keep consistency with
the name used in the corresponding definitions thus addressing a
violation of MISRA C:2012 Rule 8.3: "All declarations of an object or
function shall use the same names and type qualifiers".
No functional changes.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Rule 1.1 is uncontroversial and we are already following it.
Rule 5.6 has been deemed a good rule to have by the MISRA C group.
However, we do have a significant amount of violations that will take
time to resolve and might require partial deviations in the form of
in-code comments or MISRA C scanners special configurations (ECLAIR).
For new code, we want this rule to generally apply hence the addition to
docs/misra/rules.rst.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 22 May 2023 22:03:00 +0000 (23:03 +0100)]
x86/amd: Mitigations for Zenbleed
Zenbleed is a malfunction on AMD Zen2 uarch parts which results in corruption
of the vector registers. An attacker can trigger this bug deliberately in
order to access stale data in the physical vector register file. This can
include data from sibling threads, or a higher-privilege context.
Microcode is the preferred mitigation but in the case that's not available use
the chickenbit as instructed by AMD. Re-evaluate the mitigation on late
microcode load too.
This is XSA-433 / CVE-2023-20593.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Update ppc64/head.S to set up an initial boot stack, zero the .bss
section, and jump to C. The required setup is done using 32-bit
immediate address loads for now, but they will be changed to
TOC-relative loads once the position-independent code model is enabled.
Additionally, move the cpu0_boot_stack declaration to setup.c and change
STACK_ORDER from 2 to 0. For now, ppc64 is using 64k pages and thus the
larger STACK_ORDER is unnecessary.
Finally, refactor the endian fixup trampoline into its own macro, since it
will need to be used in multiple places, including every time we make a
call into firmware.
Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com> Acked-by: Jan Beulich <jbeulich@suse.com>
common: Move a few more standalone macros from xen/lib.h to xen/macros.h
Move a few more macros which have no dependencies on other headers from
xen/lib.h to xen/macros.h. Notably, this includes BUILD_BUG_ON* and
ARRAY_SIZE.
Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86/cpu-policy: address violations of MISRA C:2012 Rule 8.3 on parameter names
Change parameter names in function declarations to be consistent with
the ones used in the correponding definitions, thus addressing
violations of MISRA C:2012 Rule 8.3: "All declarations of an object or
function shall use the same names and type qualifiers".
libxl: arm: Add grant_usage parameter for virtio devices
Currently, the grant mapping related device tree properties are added if
the backend domain is not Dom0. While Dom0 is privileged and can do
foreign mapping for the entire guest memory, it is still desired for
Dom0 to access guest's memory via grant mappings and hence map only what
is required.
This commit adds the "grant_usage" parameter for virtio devices, which
provides better control over the functionality.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: George Dunlap <george.dunlap@cloud.com>
The fix for XSA-417 had a bug: domain_alloc_permrefs() will not return
a negative value in case of an error, but a plain errno value.
Note this is not considered to be a security issue, as the only case
where domain_alloc_permrefs() will return an error is a failed memory
allocation. As a guest should not be able to drive Xenstore out of
memory, this is NOT a problem a guest can trigger at will.
x86/mtrr: address violations of MISRA C:2012 Rule 8.3 on parameter types
Change parameter types of function declarations to be consistent with
the ones used in the corresponding definitions,
thus addressing violations of MISRA C:2012 Rule 8.3 ("All declarations
of an object or function shall use the same names and type qualifiers").
No functional changes.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
x86/HVM: address violations of MISRA C:2012 Rules 8.2 and 8.3
Give a name to unnamed parameters thus addressing violations of
MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
named parameters").
Keep consistency between parameter names and types used in function
declarations and the ones used in the corresponding function
definitions, thus addressing violations of MISRA C:2012 Rule 8.3
("All declarations of an object or function shall use the same names
and type qualifiers").
No functional changes.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Fri, 21 Jul 2023 06:31:09 +0000 (08:31 +0200)]
x86/vRTC: move and tidy convert_hour() and {to,from}_bcd()
This is to avoid the need for forward declarations, which in turn
addresses a violation of MISRA C:2012 Rule 8.3 ("All declarations of an
object or function shall use the same names and type qualifiers").
While doing so,
- drop inline (leaving the decision to the compiler),
- add const,
- add unsigned,
- correct style.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
MISRA C:2012 Rule 4.1 has the following headline:
"Octal and hexadecimal escape sequences shall be terminated."
The string literals modified by this patch contain octal or
hexadecimal escape sequences that are neither terminated by the
end of the literal, nor by the beginning of another escape sequence.
Therefore, such unterminated sequences have been split into a
separate literal as a way to comply with the rule and preserve the
semantics of the code.
Adds a BUILD_BUG_ON() to assert the dependency on 4k pages in the FF-A
mediator since the current implementation only works if Xen page size is
the same as the FFA page size.
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com>
xen/arm: add TEE teardown to arch_domain_teardown()
Adds a progress state for tee_domain_teardown() to be called from
arch_domain_teardown(). tee_domain_teardown() calls the new callback
domain_teardown() in struct tee_mediator_ops.
Note that the OP-TEE mediator should be updated in a future patch to use
the new teardown facility, that is not done here.
Co-developed-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
x86/HVM/emul: address violations of MISRA C:2012 Rules 8.2 and 8.3
Give a name to unnamed parameters thus addressing violations of
MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
named parameters").
Keep consistency between parameter names used in function declarations
and names used in the corresponding function definitions thus addressing
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> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul@xen.org>
x86: change parameter name of hvm_monitor_msr() declaration
Change the parameter name of hvm_monitor_msr() declaration from
'value' to 'new_value' to match the corresponding defintion.
This fixes a violation 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> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/misra: diff-report.py: fix function invocation
Fix the invocation of invoke_command() that takes an optional
parameter for the exception type, but in the code the error
message template was passed instead, so fix it passing a new
exception type.
xen/misra: diff-report.py: Fix UnifiedFormatParser change line registration
Fix the line number on the registration of a 'remove' change type when
consecutive 'remove' changes are registered.
Currently the algorithm registers consecutive 'remove' changes at the same
line it encounter the first one, 'add' changes type are not affected by the
bug.
Jan Beulich [Wed, 19 Jul 2023 08:22:56 +0000 (10:22 +0200)]
x86: fix early boot output
Loading the VGA base address involves sym_esi(), i.e. %esi still needs
to hold the relocation base address. Therefore the address of the
message to output cannot be "passed" in %esi. Put the message offset in
%ecx instead, adding it into %esi _after_ its last use as base address.
Fixes: b28044226e1c ("x86: make Xen early boot code relocatable") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
mm/pdx: Mark pdx hole description globals readonly after boot
They define where the compressible area of valid mfns is, and all of them
are populated on boot (with the exception of max_pdx, that's updated on
memory hotplug).
No functional change.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
mm/pdx: Add comments throughout the codebase for pdx
Document the behaviour of the pdx machinery in Xen. Some logic is fairly
opaque and hard to follow without it being documented anywhere. This
explains the rationale behind compression and its relationship to
frametable indexing and directmap management.
While modifying the file:
* Convert u64 -> uint64_t
* Remove extern keyword from function prototypes
No functional change.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Tue, 18 Jul 2023 10:39:29 +0000 (12:39 +0200)]
x86/ACPI: correct off-by-1 in SGI MMCFG check
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: 94ea0622c5b8 ("x86-64/mmcfg: relax base address restriction") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Tue, 18 Jul 2023 10:39:00 +0000 (12:39 +0200)]
x86/HVM: adjust pIRQ calculation in hvm_inject_msi()
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: 88fccdd11ca0 ("xen: event channel remapping for emulated MSIs") Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Tue, 18 Jul 2023 10:37:57 +0000 (12:37 +0200)]
x86: drop old (32-bit-only) MSR definitions
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>
Andrew Cooper [Fri, 14 Jul 2023 12:28:24 +0000 (13:28 +0100)]
xen/ACPI: Remove the acpi_string type
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>
x86/ioapic: sanitize IO-APIC pins before enabling lapic LVTERR/ESR
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>
x86/mce: change parameter names in function definitions to match the corresponding declarations
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.
Michal Orzel [Tue, 11 Jul 2023 08:29:31 +0000 (10:29 +0200)]
xen/arm: Account for domU dtb bootmodule size separately
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.
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().
iommu/ipmmu-vmsa: Add missing 'U' in IMTTLBR0_TTBR_MASK for shifted constant
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.
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: cc80e2bab0d0 ("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>
x86/APIC: modify error_interrupt() to output using single printk()
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>
x86/APIC: include full string with error_interrupt() error messages
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.
Edwin Török [Thu, 13 Jul 2023 08:30:01 +0000 (09:30 +0100)]
ocaml/libs/xc: Fix NULL dereference with physinfo_arch_caps()
`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: e5ac68a0110c ("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'
ACPI/APEI: fix violations of MISRA C:2012 Rule 7.2
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'
x86/monitor: fix violations of MISRA C:2012 Rule 7.2
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>
xen/public: fix violations of MISRA C:2012 Rule 7.2
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
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.
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'
xen/device-tree: fix violations of MISRA C:2012 Rule 7.2
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.
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.
AMD/IOMMU: fix violations of MISRA C:2012 Rule 7.2
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.
x86/cpufreq: fix violations of MISRA C:2012 Rule 7.2
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.
x86/emul: fix violations of MISRA C:2012 Rule 8.3 on parameter names
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.
Commit 9473d9a24182 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: 9473d9a24182 ('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>
cmdline: parse multiple instances of the vga option
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>
multiboot2: do not set StdOut mode unconditionally
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>
multiboot2: parse vga= option when setting GOP mode
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>
Jan Beulich [Thu, 6 Jul 2023 07:06:27 +0000 (09:06 +0200)]
xenstore: talloc.h needs to include stdarg.h
talloc_vasprintf() has a va_list type parameter, so this type needs to
be defined (independent of the particular libc implementation).
Fixes: 63b6419d2a2d ("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>
x86/microcode: Allow reading microcode revision even if it can't be updated
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>
Andrew Cooper [Wed, 21 Jun 2023 20:44:37 +0000 (21:44 +0100)]
xen/types: Rework stdint vs __{u,s}$N types
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>
Andrew Cooper [Mon, 26 Jun 2023 15:36:36 +0000 (16:36 +0100)]
treewide: Avoid including asm/types.h
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>
Andrew Cooper [Wed, 21 Jun 2023 20:36:54 +0000 (21:36 +0100)]
xen/types: Drop #ifdefary for __{SIZE,PTRDIFF}_TYPE__
All supported compilers have these types.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.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: 12314be5749e ("xen/arm: make ARM_EFI selectable for Arm64") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Nicola Vetrini [Thu, 29 Jun 2023 10:06:16 +0000 (12:06 +0200)]
xen/arm: smmuv3: fix violations of MISRA C:2012 Rule 3.1
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.
xen/include: avoid using a compiler extension for BUILD_BUG_ON_ZERO
Redefine BUILD_BUG_ON_ZERO to avoid using a compiler extension
that gives an acceptable semantics to C99 undefined behavior 58
("A structure or union is defined as containing no named members
(6.7.2.1)").
The first definition includes an additional named field of type
char.
The chosen ill-formed construct for the second definition is a struct
with a named bitfield of width 0 when the condition is true,
which prevents the UB without using the compiler extension while keeping
the semantic of the construct.
The choice of the bitwise AND operation to bring the result to 0
when cond is false boils down to possibly better portability.
Anthony PERARD [Wed, 5 Jul 2023 06:25:03 +0000 (08:25 +0200)]
build: define ARCH and SRCARCH later
Defining ARCH and SRCARCH later in xen/Makefile allows to switch to
immediate evaluation variable type.
ARCH and SRCARCH depend on value defined in Config.mk and aren't used
for e.g. TARGET_SUBARCH or TARGET_ARCH, and not before they're needed in
a sub-make or a rule.
This will help reduce the number of times the shell rune is been
run.
With GNU make 4.4, the number of execution of the command present in
these $(shell ) increased greatly. This is probably because as of make
4.4, exported variable are also added to the environment of $(shell )
construct.
Also, `make -d` shows a lot of these:
Makefile:39: not recursively expanding SRCARCH to export to shell function
Makefile:38: not recursively expanding ARCH to export to shell function
Reported-by: Jason Andryuk <jandryuk@gmail.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Tested-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen/riscv: move extern of cpu0_boot_stack to header
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Jan Beulich [Wed, 5 Jul 2023 06:17:13 +0000 (08:17 +0200)]
libelf: make L1_MFN_VALID note known
We still don't use it (in the tool stack), and its values (plural) also
aren't fetched correctly, but it is odd to continue to see the
hypervisor log "ELF: note: unknown (0xd)" when loading a Linux Dom0.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <jgrall@amazon.com>
Wei Chen [Mon, 26 Jun 2023 03:33:53 +0000 (11:33 +0800)]
xen/arm: make ARM_EFI selectable for Arm64
Currently, ARM_EFI will mandatorily selected by Arm64.
Even if the user knows for sure that their images will not
start in the EFI environment, they can't disable the EFI
support for Arm64. This means there will be about 3K lines
unused code in their images.
So in this patch, we make ARM_EFI selectable for Arm64, and
based on that, we can use CONFIG_ARM_EFI to gate the EFI
specific code in head.S for those images that will not be
booted in EFI environment.
Wei Chen [Mon, 26 Jun 2023 03:33:52 +0000 (11:33 +0800)]
xen/arm: remove xen_phys_start and xenheap_phys_end from config.h
These two variables are stale variables, they only have declarations
in config.h, they don't have any definition and no any code is using
these two variables. So in this patch, we remove them from config.h.
Henry Wang [Thu, 29 Jun 2023 22:18:00 +0000 (06:18 +0800)]
xen/arm: vgic: Add missing 'U' in VGIC_ICFG_MASK for shifted constant
With UBSAN on some arm64 platforms, e.g. FVP_Base_RevC-2xAEMvA, the
following splat will be printed while Dom0 is booting:
```
(XEN) ==================================================================
(XEN) UBSAN: Undefined behaviour in arch/arm/vgic.c:372:15
(XEN) left shift of 1 by 31 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 Not tainted ]----
```
This is because there is a device node in the device tree with 0xf
as the interrupts property. Example of the device tree node is shown
below:
```
ethernet@202000000 {
compatible = "smsc,lan91c111";
reg = <0x2 0x2000000 0x10000>;
interrupts = <0xf>;
};
```
and this value is passed to vgic_get_virq_type() as "index" then "intr"
in VGIC_ICFG_MASK.
Add the missing 'U' in VGIC_ICFG_MASK as a fix, and this should also
addressing 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: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Hongda Deng <hongda.deng@arm.com>
Luca Fancellu [Thu, 8 Jun 2023 13:59:13 +0000 (14:59 +0100)]
tools/python: Fix memory leak on error path
Commit 56a7aaa16bfe introduced a memory leak on the error path for a
Py_BuildValue built object that on some newly introduced error path
has not the correct reference count handling, fix that by decrementing
the refcount in these path.
Fixes: 56a7aaa16bfe ("tools: add physinfo arch_capabilities handling for Arm") Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Luca Fancellu [Thu, 8 Jun 2023 13:59:12 +0000 (14:59 +0100)]
tools: Fix ifdef for aarch64 that should include also arm
Commit 56a7aaa16bfe introduced some SVE related code that is protected by
'#if defined(__aarch64__)', the issue is that this doesn't take into
consideration when the toolstack is compiled for an arm32 Dom0 running on
an arm64 platform, it should be able to create SVE enabled guests but with
the current code it's not.
So fix the issue by compiling the code when the toolstack is compiled for
both arm32 and arm64.
Fixes: 56a7aaa16bfe ("tools: add physinfo arch_capabilities handling for Arm") Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
Note that second sentence is not part of the newer Armv8 spec. But the
interpretation is not much different.
The updated entry will not be used until xen_pt_update() completes.
So rather than adding the ISB after write_pte() in create_xen_table()
and xen_pt-update_entry(), add it in xen_pt_update().
Also document the reasoning of the deferral after each write_pte() calls.
Fixes: 07d11f63d03e ("xen/arm: mm: Avoid flushing the TLBs when mapping are inserted") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
Note that second sentence is not part of the newer Armv8 spec. But the
interpretation is not much different.
As the entry created by arch_pmap_map() will be used soon after
pmap_map() returns, we want to ensure the DSB in write_pte() has
completed. So add an ISB.
Fixes: 4f17357b52f6 ("xen/arm: add Persistent Map (PMAP) infrastructure") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
xen/arm: page: Consolidate write_pte() and clarify the documentation
The implementation of write_pte() is pretty much the same on arm32
and arm64. So it would be good to consolidate it as this would help
to clarify the requirements when using the helper.
Take the opportunity to switch from assembly to call macros. Note there
is a difference on arm32 because the option was not specified. But this
meant 'sy' (system wide).
Futhermore, the requirements for the ISB is incomplete. Per the Arm Arm,
(Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12), DSB will only
affect explicit accesses. So an ISB is necessary after DSB to ensure
the completion. Having an ISB after each update to the page-tables is
probably too much, so let the caller add the instruction when it is
convenient.
Lastly, the barrier in write_pte() may be too restrictive but I haven't
yet find the proper section(s) in the Arm Arm.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
----
I am a bit split on whether we should add an ISB in write_pte(). It
would make easier for the developper, but would likely force a pipeline
flush too often.
It might also be possible to drop the ISB (and even DSB) when updating
stage-2 PTE (Linux already does it, see 120798d2e7d1). But I am not sure
this is worth it in Xen.
xen/arm64: head: Add missing isb in setup_fixmap()
On older version of the Arm Arm (ARM DDI 0487E.a, B2-125) there were
the following paragraph:
"DMB and DSB instructions affect reads and writes to the memory system
generated by Load/Store instructions and data or unified cache
maintenance instructions being executed by the PE. Instruction fetches
or accesses caused by a hardware translation table access are not
explicit accesses."
Newer revision (e.g. ARM DDI 0487J.a) doesn't have the second sentence
(it might be somewhere else in the Arm Arm). But the interpretation is
not much different.
In setup_fixmap(), we write the fixmap area and may be used soon after,
for instance, to write to the UART. IOW, there could be hardware
translation table access. So we need to ensure the 'dsb' has completed
before continuing. Therefore add an 'isb'.
Fixes: 2b11c3646105 ("xen/arm64: head: Remove 1:1 mapping as soon as it is not used") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
xen/arm32: head: Add mising isb in switch_to_runtime_mapping()
Per the Arm Arm (ARM DDI 0406C.d A3.8.3):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
The function switch_to_runtime_mapping() is responsible to map the
Xen at its runtime address if we were using the temporary area before
jumping returning using a runtime address. So we need to ensure the
'dsb' has completed before continuing. Therefore add an 'isb'.
Fixes: fbd9b5fb4c26 ("xen/arm32: head: Remove restriction where to load Xen") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
projects / people / aperard / xen-unstable.git / log