Make it explicit that for watching the @releaseDomain/<domid> special
node, the XENSTORE_SERVER_FEATURE_WATCHDEPTH is needed.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Lazy FPU avoids some work during a context switch but pushes more
expensive costs elsewhere:
* For a workload running some Windows VMs, I measured about 83% of
context switches out had used the FPU so most of the time the FPU
save/restore is not avoided, just delayed.
* A key difference between 32-bit and 64-bit OSes is that %xmm is in the
base featureset for 64-bit and thus gets ubiquitous use in userspace.
This is likely why we hit 83%.
* Setting/clearing the cr0.TS bit is serializing and reportedly slower
than the processor optimized xsave/restore.
* Linux uses PKRU so a partial xsave/restore is performed on each
context switch anyway, followed by a second xsave/restore at some
point during execution. This interferes with the 'modified'
optimisation that hardware uses to try and reduce the cost of the
following XSAVE.
There is no measurable performance benefit for using lazy FPU and it
adds unwanted complexity so remove the option and always use eager-fpu.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The controls for cpu-bugs were ultimately not taken. As the paths are
documented fully below, pick only a small subset for the example. Include
cpupool/ as it exists now.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Add a new "xenstore_quota" domain config parameter for setting the
Xenstore quota of a new domain via a list of <quota>=<val> items.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
The "-h" parameter is missing in the man pages of the xenstore-*
programs.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
... seeing as I've had to thoroughly reverse engineer it for FRED and make
tweaks in places.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Multiple downstream distros have tried passing discrete CPIO archives and
tripped over this not working. It turns out to be easy to support, so do so.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Teddy Astie <teddy.astie@vates.tech>
Legacy PCI devices don't have any extended config space. Reading any part
thereof may return all ones or other arbitrary data, e.g. in some cases
base config space contents repeatedly.
Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our
determination of device type; in particular some comments are taken
verbatim from there. Like with Linux'es CONFIG_PCI_QUIRKS, only the alias
detection logic is covered by the new "pci=no-quirks". The singular access
at PCI_CFG_SPACE_SIZE is left unconditional.
For Misra's sake the PCI_X_STATUS_533HMZ definition also needs amending.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
parse_ucode() is abnormal compared to similar parsing elsewhere in Xen.
Invert the ucode_mod_forced check with respect to the "scan" and integer
handling, so we can warn the user when we've elected to ignore the parameters,
and yield -EINVAL for any unrecognised list element.
Rewrite the ucode= command line docs for clarity.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
It's only used for microcode loading on x86. By lib-ifying it, it will be
discarded automatically by the linker when CONFIG_MICROCODE_LOADING=n.
Update the path in exclude-list.json, as the code is still not clean.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Amend docs to reflect ucode= command/stanza depend on MICROCODE_LOADING
being set.
The new MICROCODE_OP() is a conditional setter for the microcode_ops
struct. By using IS_ENABLED() there rather than ifdef we allow DCE to
remove all statics no longer used when microcode loading is disabled
without tagging them with __maybe_unused.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
We'd rather have the full spelling in Kconfig. Adjusts every other
reference to the name too.
Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
In macros it is common to declare local variables using typeof(param) in order
to ensure that side effects are only evaluated once. A consequence of this is
double textural expansion of the parameter, which can get out of hand very
quickly with nested macros.
In C23, the auto keyword has been repurposed to perform type inference.
A GCC extension, __auto_type, is now available in the new toolchain baseline
and avoids the double textural expansion.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
The most recent xenoprof change was 300ef0cb4f ("x86: Add Xenoprofile
support for AMD Family16h") in 2013, despite there being 42 changes worth of
other cleanup/rearranging since then.
Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove
opcontrol and the GUI and processor models dependent on it") in 2014, as part
of releasing version 1.0 and switching over to using operf based on the Linux
perf_event subsystem. Linux's version of this patch was merged in commit
24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021.
Drop xenoprof and all supporting infrastructure, including the hypercall, the
XSM hook and flask vectors which lose their only caller, and even shrinks
struct domain by one pointer which wasn't properly excluded in
!CONFIG_XENOPROF builds.
Retain the public xenoprof.h header as it is ABI, but note that the
functionality is removed.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
xen/drivers/passthrough/arm/ipmmu-vmsa.c contains a git:// URL in a block
comment. This is also not an example of commented out code, so shouldn't be
considered a R3.1 violation.
Extend the regex to include git://, and swap hyperlink for URL in the
associated documentation to be more precise.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
There is consensus towards using more binary literals in Xen,
so they are enabled both for X86_64 and ARM64.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
..., thus allowing them to become static. There's nothing x86-specific
about these functions anyway.
Since only the "iommu_inclusive_mapping" parameter declaration would be
left in the file, move that as well. There's nothing VT-d specific about
it (anymore?): "dom0-iommu=map-inclusive" is similarly generic, and
documentation also doesn't say anything.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
MISRA C Rule 17.1 prohibits the use of the features that support
variadic functions. Make the deviation already in place for controlled
use of such features more general, relying on the presence of the
`format' attribute on the function declaration.
Add attributes where missing in order to avoid special-casing
certain functions that use variadic arguments.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Current implementation is based on x86's way to allocate VMIDs:
VMIDs partition the physical TLB. In the current implementation VMIDs are
introduced to reduce the number of TLB flushes. Each time a guest-physical
address space changes, instead of flushing the TLB, a new VMID is
assigned. This reduces the number of TLB flushes to at most 1/#VMIDs.
The biggest advantage is that hot parts of the hypervisor's code and data
retain in the TLB.
VMIDs are a hart-local resource. As preemption of VMIDs is not possible,
VMIDs are assigned in a round-robin scheme. To minimize the overhead of
VMID invalidation, at the time of a TLB flush, VMIDs are tagged with a
64-bit generation. Only on a generation overflow the code needs to
invalidate all VMID information stored at the VCPUs with are run on the
specific physical processor. When this overflow appears VMID usage is
disabled to retain correctness.
Only minor changes are made compared to the x86 implementation.
These include using RISC-V-specific terminology, adding a check to ensure
the type used for storing the VMID has enough bits to hold VMIDLEN,
and introducing a new function vmidlen_detect() to clarify the VMIDLEN
value, rename stuff connected to VMID enable/disable to "VMID use
enable/disable".
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Similar to the ARM64 compiler, the same assumptions can be made about
the X86_64 toolchain.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type."
This deviation from Rule 11.1 relies on both ABI definitions and compiler
implementations supported by Xen. The System V x86_64 ABI and the AArch64
ELF ABI define consistent and compatible representations (i.e., having
the same size and memory layout) for (void *), unsigned long, and function
pointers, enabling safe conversions between these types without data loss
or corruption. Additionally, GCC and Clang, faithfully implement the ABI
specifications, ensuring that the generated machine code conforms to these
guarantees. Developers must note that this behavior is not universal and
depends on platform-specific ABIs and compiler implementations.
Configure Eclair to avoid reporting violations for conversions from
unsigned long or (void *) to a function pointer.
Add a compile-time assertion into the file 'xen/common/version.c' to
confirm this conversion compatibility across X86 and ARM platforms
(assuming this file is common for them).
References:
- System V x86_64 ABI: https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build
- AArch64 ELF ABI: https://github.com/ARM-software/abi-aa/releases
- GCC: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
- Clang: https://clang.llvm.org/docs/CrossCompilation.html
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
[stefano: remove special powerpc check]
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
As noted in the command line documentation, these are both deprecated since
Xen 4.7 (2016), and are not fully effective on AMD CPUs starting from 2011.
Not realised at the time of writing the docs was that their use is also
incompatible with certain errata workarounds which edit the CPUID MSRs after
the levelling defaults are calculated.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Use the apply-build-vars make macro to replace the @xxx@ markers in
*.in files only at build time.
This allows to change the affected document files without having to
run "configure" for making the change effective.
While at it add the generated files to the distclean make target.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The stimer enlightment was removed from the defaults list in commit
e83077a3d1 ("libxl: don't enable synthetic timers by default") but the
corresponding docs change was not made. Removing from docs as enabling the
enlightenment will hang Windows 10 guests.
Fixes: e83077a3d1 ("libxl: don't enable synthetic timers by default")
Signed-off-by: James Dingwall <james@dingwall.me.uk>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
After initial publication, the SB-7033 / CVE-2024-36347 bulletin was updated
to list Zen5 CPUs as vulnerable. Use Fam1ah as an upper bound, and adjust the
command line documentation.
When the Zen6 (also Fam1ah processors) model numbers are known, they'll want
excluding from the range.
Fixes: 630e8875ab ("x86/ucode: Perform extra SHA2 checks on AMD Fam17h/19h microcode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Add man page documentation for the new '-p/--pcpus' flag that displays
physical CPU utilization metrics. This provides hypervisor-level CPU
usage insights alongside existing domain statistics.
Changes include:
- Add '-p' flag to SYNOPSIS section
- Document '--pcpus' option with description
- Maintain consistency with existing documentation style
Signed-off-by: Jahan Murudi <jahan.murudi.zg@renesas.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
We have written the requirements for some of the commands of the XEN_VERSION
hypercall.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Other projects have long switched to xz and/or lzip.
Tidy things some as well: With the removal of qemu from the tarball,
intermediately extracting the tarball again has become wasteful. Drop
that. Invoke compressors using asynchronous lists, to reduce overall
latency. Drop the -v option from the (previously implicit) gzip
invocation.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Tested-by: Julien Grall <jgrall@amazon.com>
amd-cppc has 2 operation modes: autonomous (active) mode and
non-autonomous (passive) mode.
In active mode, we don't need Xen governor to calculate and tune the cpu
frequency, while hardware built-in CPPC power algorithm will calculate the
runtime workload and adjust cores frequency automatically according to the
power supply, thermal, core voltage and some other hardware conditions.
In active mode, CPPC ignores requests done in the desired performance field,
and takes into account only the values set to the minimum performance, maximum
performance, and energy performance preference registers.
A new field EPP (energy performance preference), in CPPC request register, is
introduced. It will be used in the CCLK DPM controller to drive the frequency
that a core is going to operate during short periods of activity, called
minimum active frequency, It could contatin a range of values from 0 to 0xff.
An EPP of zero sets the min active frequency to maximum frequency, while
an EPP of 0xff sets the min active frequency to approxiately Idle frequency.
We implement a new AMD CPU frequency driver `amd-cppc-epp` for active mode.
It requires `active` tag in Xen cmdline for users to explicitly select active
mode.
In driver `active-cppc-epp`, ->setpolicy() is hooked, not the ->target(), as
it does not depend on xen governor to do performance tuning.
We also introduce a new field "policy" (CPUFREQ_POLICY_xxx) to represent
performance policy. Right now, it supports three values:
CPUFREQ_POLICY_PERFORMANCE as maximum performance, CPUFREQ_POLICY_POWERSAVE
as the least power consumption, and CPUFREQ_POLICY_ONDEMAND as no preference,
just corresponding to "performance", "powersave" and "ondemand" Xen governor,
which benefit users from re-using "governor" in Xen cmdline to deliver
which performance policy they want to apply.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Since eSPI support has been introduced, update the documentation with
the appropriate description.
Signed-off-by: Leonid Komarianskyi <leonid_komarianskyi@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
The commit 3e322bef8b ("xen/arm: firmware: Add SCMI over SMC calls
handling layer") introduces simple driver which forwards SCMI over SMC
calls from hwdom/dom0 to EL3 firmware (TF-A) with a single SCMI OSPM agent
support. While it is working gracefully for hwdom/dom0 use case it doesn't
cover "thin Dom0 with guest domain, which serves as Driver domain"
use-case. In this case HW need to be enable in Driver domain and dom0 is
performing only control functions.
The EL3 SCMI firmware (TF-A) with a single SCMI OSPM agent support is
pretty generic case for the default vendors SDK and new platforms.
This patch enables passthrough of SCMI SMC single agent interface to the
one guest domain serving as Driver domain.
Configure Dom0 to enable SCMI passthrough:
- dom0: add scmi-smc-passthrough to the Xen Command Line
Enabled SCMI passthrough for guest using toolstack in the following way:
- domD: xl.cfg add "arm_sci" option as below
arm_sci = "type=scmi_smc"
- domD: xl.cfg enable access to the "arm,scmi-shmem"
iomem = [
"47ff0,1@22001",
]
- domD: add SCMI nodes to the Driver domain partial device tree as in the
below example:
passthrough {
scmi_shm_0: sram@22001000 {
compatible = "arm,scmi-shmem";
reg = <0x0 0x22001000 0x0 0x1000>;
};
firmware {
compatible = "simple-bus";
scmi: scmi {
compatible = "arm,scmi-smc";
shmem = <&scmi_shm_0>;
...
}
}
}
dom0less case configuration:
- add "xen,sci_type" property for required DomU ("xen,domain") node
xen,sci_type="scmi_smc"
- add scmi nodes to the Driver domain partial device tree the same way
as above and enable access to the "arm,scmi-shmem" according to
dom0less documentation. For example:
scmi_shm_0: sram@22001000 {
compatible = "arm,scmi-shmem";
reg = <0x00 0x22001000 0x00 0x1000>;
-> xen,reg = <0x0 0x47ff0000 0x0 0x1000 0x0 0x22001000>;
-> xen,force-assign-without-iommu;
};
The SCMI SMC single agent interface can be enabled for one and only one
domain. In general, the configuration is similar to any other HW
passthrough, except explicitly enabling SCMI with "arm_sci" xl.cfg option.
Note that "arm,scmi-smc" and "arm,scmi-shmem" nodes will be removed from
dom0/hwdom DT when "scmi-smc-passthrough" cmdline parameter was provided.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech> # tools
On rare occasions Fixes: isn't quite appropriate to use, yet another
commit still wants making a connection to in a formalized way. Such could
e.g. happen if a pretty obvious optimization was left out (which isn't a
bug, but still a shortcoming). Formalize Amends: as a tage to use in such
a situation.
Requested-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
... disabled by default. There is a lot of work before FRED can be enabled by
default.
One part of FRED, the LKGS (Load Kernel GS) instruction, is enumerated
separately but expected to be mandatory as FRED disallows the SWAPGS
instruction. Normally, we'd have to check both CPUID bits, but Xen does not
use GS like most other software, and can manage without LKGS.
FRED formally removes the use of Ring1 and Ring2, meaning we cannot run 32bit
PV guests. As already done with CET, disable PV32 if using FRED, except in
shim mode where FRED is disabled by default.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Users need to set "cpufreq=amd-cppc" in xen cmdline to enable amd-cppc driver,
which selects ACPI Collaborative Performance and Power Control (CPPC) on
supported AMD hardware to provide a finer grained frequency control mechanism.
`verbose` option can also be included to support verbose print.
When users setting "cpufreq=amd-cppc", a new amd-cppc driver
shall be registered and used. All hooks for amd-cppc driver are transiently
missing, and we temporarily make registration fail with -EOPNOTSUPP here. It
will be fixed along with the implementation.
New xen-pm internal flag XEN_PROCESSOR_PM_CPPC is introduced, to stand for
cpufreq driver in CPPC mode. We define XEN_PROCESSOR_PM_CPPC 0x100, as it is
the next value to use after 8-bits wide public xen-pm options. We also add
sanity check on compile time. All XEN_PROCESSOR_PM_xxx checking shall be
updated to consider "XEN_PROCESSOR_PM_CPPC" too.
XEN_PROCESSOR_PM_CPPC and XEN_PROCESSOR_PM_PX are firstly set when Xen parsed
relative driver signature from xen cmdline, and will become exclusive after
cpufreq driver registration. It is because that platform could not support
both or mixed mode (CPPC & legacy Px) operations, and only one cpufreq driver
could be registerd in Xen at one time, such as on AMD, it is either amd-cppc
or legacy P-states driver.
Xen rely on XEN_PROCESSOR_PM_CPPC flag to tell current cpufreq driver is in
CPPC mode, and accepts relative hypercall. It will neglect Px request and
yields success.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Fix the following issues:
1. xen/docs/misra/deviations.rst:90: WARNING: Inline interpreted text or
phrase reference start-string without end-string. [docutils]
2. xen/docs/misra/deviations.rst:54: ERROR: Error parsing content block
for the "list-table" directive: uniform two-level bullet list expected,
but row 6 does not contain the same number of items as row 1 (2 vs 3).
* - R2.1
- Calls to the `__builtin_unreachable()` function inside the expansion of
the `ASSERT_UNREACHABLE()` macro may cause a function to be marked as
non-returning. This behavior occurs only in configurations where
assertions are enabled. To address this, the `noreturn` property for
`__builtin_unreachable()` is overridden in these contexts, resulting in
the absence of reports that do not have an impact on safety, despite
being true positives.
Xen expects developers to ensure code remains safe and reliable in builds,
even when debug-only assertions like `ASSERT_UNREACHABLE() are removed.
3. xen/docs/misra/rules.rst:127: WARNING: Inline interpreted text or phrase
reference start-string without end-string. [docutils]
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
In order to be able to use "xl info" before Xenstore has been started
or after it has crashed, hide obtaining the available Xenstore features
behind the new option "-x".
Fixes: ecce7970cf ("tools/xl: add available Xenstore features to xl info output")
Reported-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
MISRA C Rule 5.5 states: "Identifiers shall be distinct from macro names".
Update ECLAIR configuration to deviate clashes: specify the macros that
should be ignored. Update deviations.rst and rules.rst accordingly.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Call stack for dom0less hwdom case (1:1) memory:
create_domUs
|-construct_domU
|-construct_hwdom()
|-allocate_memory_11()
And allocate_memory_11() uses "dom0_mem" as:
min_low_order =
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
In case of dom0less boot the "dom0_mem" is not used and defaulted to 0,
which causes min_low_order to get high value > order and so no allocations
happens from low memory.
Fix it, by using kinfo->unassigned_mem instead of "dom0_mem" which has
correct memory size in both cases: regular dom0 boot and dom0less boot.
Fixes: 52cb53f181 ("xen/arm: dom0less hwdom construction")
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Add a new command line parameter "tee=" to be used to explicitly select
what tee mediator is to be used by Xen and fail if it does not exist
or the probe function for it failed.
Without specifying which tee is to be used, Xen will use the first one
for which the probe function succeeds which depends on the order of the
mediator list which depends on the compiler.
Using the command line argument, it is now possible to explicit request
a specific TEE mediator and panic on boot if it is not available.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Julien Grall <jgrall@amazon.com>
Introduce a command line option to allow disabling PDX compression. The
disabling is done by turning pfn_pdx_add_region() into a no-op, so when
attempting to initialize the selected compression algorithm the array of
ranges to compress is empty.
Signed-off-by: Roger Pau Monné <roger.pau@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The conversion from a function pointer with the 'noreturn' attribute
('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
causes type incompatibility according to MISRA C Rule 11.1, which
forbids conversions between incompatible function pointer types.
The violation occurs at the call site:
smp_call_function(halt_this_cpu, NULL, 0);
where 'halt_this_cpu' with type 'void noreturn (*)(void *)' is passed to
'smp_call_function' expecting function pointer of type 'void (*)(void *)'.
The 'noreturn' attribute does not change the function calling convention
or parameter handling at runtime, making the conversion safe.
For now, configure Eclair to just treat implicit conversions that lose
the "noreturn" attribute on a function 'void (*)(void*)' as safe.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com> # docs
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # ECLAIR
MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
Functions that are non-returning and are not explicitly annotated with
the `noreturn' attribute are considered a violation of this rule.
In certain cases, some functions might be non-returning in specific build
configurations (when assertions are enabled, i.e., when `NDEBUG' is not
defined). This is due to calls to `__builtin_unreachable()' in the
expansion of the macro `ASSERT_UNREACHABLE()'.
Conversely, in builds where `NDEBUG' is defined (assertions are disabled),
the macro `ASSERT_UNREACHABLE()' expands to an empty construct
(`do { } while (0)'), which does not affect the execution flow. This allows
such functions to return normally in such builds, avoiding unreachable code.
To account for that in specific builds, the `noreturn` property of
`__builtin_unreachable()` is overridden in the ECLAIR configuration to
deviate these violations.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Juergen Gross