bootinfo-fdt.c will eventually contain bootfdt helpers that make heavy
use of bootinfo. To simplify git history do the rename here explicitly.
A later patch extracts bootinfo-independent helpers into bootfdt.c.
Doing so here would needlessly pollute the diffs.
Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Part of an unpicking process to extract bootfdt contents independent of
bootinfo to a separate file for x86 to take.
With this, bootfdt.h can be cleanly included from x86. A later patch
extracts the definitions so the functions may be called too.
Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Oleksii Kurochko<oleksii.kurochko@gmail.com> # riscv
Part of an unpicking process to extract bootfdt contents independent of bootinfo
to a separate file for x86 to take.
Move functions required for early FDT parsing from device_tree.h and arm's
setup.h onto bootfdt.h
Declaration motion only. Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Oleksii Kurochko<oleksii.kurochko@gmail.com> # riscv
Create a struct field within kernel_info with the contents common to
kernel_info and boot_domain, and define that field in common code. This
enables x86 to use that field as-is and drop x86's boot_domain.
Note that x86 mutates the module when releasing it, calculating headroom,
etc. So they must be made non-const on move.
Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
These types resemble each other very closely in layout and intent,
and with "struct boot_module" already in common code it makes perfect
sense to merge them. In order to do so, rename identical fields with
conflicting names.
While doing this, s/BOOTMOD_XSM/BOOTMOD_XSM_POLICY/, as it was on x86.
XSM doesn't support external modules, so don't let the name imply it
through ambiguity.
No functional change intended.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
This snapshot is Linux commit db4001f9cc32 ("x86/cpu/vfm: Delete all
the *_FAM6_ CPU #defines"), now that Xen has switched off the old constant
names.
Leave a comment identifying the exact revision Xen is using.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Switch to the new fields and constants.
In mwait_idle_probe(), exit early for non-Intel CPUs. intel_idle_ids[] is a
large (and ever increasing) table and it's not reasonable to scan it for other
vendors, nor is it ideal to be emitting a somewhat-ambiguous error message.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
helper to match a specific stepping, and use it to rework deadline_match[].
Currently, the table is scanned on all systems, even those without the
TSC_DEADLINE feature. Introduce another early exit for that case, which also
removes the need to encode every row in the table with TSC_DEADLINE.
Notably this removes the overloading of driver_data possibly being a function
pointer, and removes the latent bug where the target functions are missing
ENDBR instructions owing to the lack of the cf_check attribute.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Architecturally, stepping is a 4-bit field, so a uint16_t suffices for a
bitmap of steppings.
In order to keep the size of struct x86_cpu_id the same, shrink the vendor and
family fields; there's no need for them to be uint16_t in Xen, and this
matches the size of the fields in cpuinfo_x86.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Xen's use of struct x86_cpu_id is a bit different to Linux's, so we can
simplify the loop termination condition. Leave a comment explaining Xen's
assumptions.
Switch to Xen style, as we've properly deviated from Linux, and switch to the
new vendor/family/model names.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This replaces raw model numbers (and comments in some cases) with names. For
probe_mwait_errata(), merge the comments with the table to make it easier to
see which erratum is which, and drop a stray "Problem" in LNL030.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
mwait-idle's ICPU() is the most convenient place to get started. Introduce
X86_MATCH_CPU() and X86_MATCH_VFM() following their Linux counterparts.
This involves match-cpu.h including more headers, which in turn allows us to
drop a few.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Only 5 files use struct x86_cpu_id, so it should not be in processor.h. This
is in preparation to extend it with VFM support.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In intel.c, drop asm/mwait.h and asm/uaccess.h, neither of which are used.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
NEHALEM_EX is affected by the erratum too.
Change the comment to be the full erratum text, not an interpretation of it.
Fixes: 95807bcae4 ("C6 state with EOI issue fix for some Intel processors")
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The current p2m type-change loop in ept_vcpu_flush_pml_buffer() relies on
each call to p2m_change_type_one() taking the p2m lock, doing the change
and then dropping the lock and flushing the p2m. Instead take the p2m lock
outside of the loop, so that calls to gfn_{,un}lock() inside
p2m_change_type_one() just take the p2m lock recursively, and more
importantly, the flush is deferred until the p2m is unlocked in
ept_vcpu_flush_pml_buffer().
No functional change intended in the end result of
ept_vcpu_flush_pml_buffer(), however a possibly noticeable performance
improvement is expected.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Later patches extract the bindings to a separate file, where that global
won't be available. Make the check when calling the function instead so
the bindings remain agnostic.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
In udelay(), use cpu_relax() directly which, for better or worse, is the
common way to refer to the PAUSE instruction.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This snapshot is prior to Linux commit db4001f9cc32 ("x86/cpu/vfm: Delete all
the *_FAM6_ CPU #defines") at the end of their conversion phase.
In addition to non-FAM6 infixed names, defines are added for the Pentium Pro,
ArrowLake U, and reintroduced the PHI defines which were incorrectly deleted
in the past.
In cpufeature.h, provide VFM_* macros to transform constants to/from the
cpuinfo_x86 representation.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Intel have run out of model space in Family 6 and will start using Family 19
starting with Diamond Rapids. Xen, like Linux, has model checking logic which
will malfunction owing to bad assumptions about the family field.
Reorder the family, vendor and model fields so they can be accessed together
as a single vfm field.
As we're cleaning up the logic, take the opportunity to introduce better
names, dropping the x86 prefix.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
smp_store_cpu_info() doesn't call identify_cpu() again during S3 resume,
hence it is wrong to zap APs' data while bringing them down (and we're
not just parking them there) during suspend.
Fixes: 7126b7f806 ("x86/CPU: re-work populating of cpu_data[]")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
smp_store_cpu_info() doesn't call identify_cpu() again during S3 resume,
hence it is wrong to overwrite APs' data using boot_cpu_data. With
7126b7f806 ("x86/CPU: re-work populating of cpu_data[]") this now
results in a crash, as the cpu_to_socket() use in smp_store_cpu_info()
then obtains a bad socket number, much like was already observed in [1].
[1] https://lists.xen.org/archives/html/xen-devel/2025-06/msg01879.html
Fixes: bb502a8ca5 ("x86: check feature flags after resume")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
The definition of MISRA C Rule 12.2 ("The right hand operand of a shift
operator shall lie in the range zero to one less than the width in bits
of the essential type of the left hand operand") is concerned with the
essential type of an expression, while the C Undefined Behaviour is
related to C standard types, which may be wider but not narrower than
the MISRA C essential type. For this reason, it is safe to consider the
C standard type, rather than the essential type when checking the rule.
To avoid regressions, tag the rule as clean and add it to the
monitored set.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
For the final step of live-update in stubdom, call kexec().
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Add the required configuration settings to enable kexec in the PVH
variant of xenstore-stubdom. This is required to support live update.
Set the number of kexec module pages to 18 in order to support using
the kexec module memory for the stubdom's 9pfs granted pages.
In Xenstore code test the CONFIG_KEXEC setting in order to determine
whether stubdom live update is supported (PV xenstore-stubdom doesn't
have live update support, as it lacks kexec).
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Before CPU identification has run (and it may not have run at all e.g.
when AP bringup failed altogether), cpu_data[].phys_proc_id (which is
what cpu_to_socket() resolves to) can't really be used. The use of
cpu_to_socket()'s result as an array index in cpu_smpboot_free()
therefore needs guarding, as the function will also be invoked upon AP
bringup failure, in which case CPU identification may not have run.
Without "x86/CPU: re-work populating of cpu_data[]" [1] the issue is
less pronounced: The field starts out as zero, then has the BSP value
(likely again zero) copied into it, and it is properly invalidated only
in cpu_smpboot_free(). Still it is clearly wrong to use the BSP's socket
number here.
Making the guard work with and without the above patch applied turns out
interesting: Prior to that patch, the sole invalidation done is that in
cpu_smpboot_free(). Upon a later bringup attempt, the fields invalidated
are overwritten by the BSP values again, though. Hence compare APIC IDs,
as they cannot validly be the same once CPU identification has run.
[1] https://lists.xen.org/archives/html/xen-devel/2024-02/msg00727.html
Fixes: 4824bdfdab ("x86: add socket_cpumask")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
DOM0 could deliever whatever performance statistic (Px, _CPC) it parses, it is
Xen's responsibility to decide which one it shall accept.
Xen rely on XEN_PROCESSOR_PM_xxx flag to tell which mode ( Px or CPPC )
current cpufreq driver supports, and accepts relative info. It will neglect
unsupported-mode request and yields success.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
"ondemand" is more suitable to describe a preset in which epp value is set
with medium(CPPC_ENERGY_PERF_BALANCE), showing no preference over performance or
powersave, minimum with lowest and maximum with highest.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
_PSD info, consisted of "shared_type" and "struct xen_psd_package", will not
only be provided from px-specific "struct xen_processor_performance", but also
in CPPC data.
Two new helper functions are introduced to deal with _PSD. They will later be
re-used for handling the same data for CPPC.
In the meantime, the following style corrections get applied at the same time:
- add extra space before and after bracket of if()
- remove redundant parenthesis
- no need to put brace for printk() at a seperate line
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Right now, only when we failed cpufreq driver registration with -ENODEV, we get
the chance to try the fallback option.
There are two code path erroring out other than -ENODEV in cpufreq driver
registration: one is when the driver itself is broken, like missing mandatory
hooks, cpufreq_register_driver() will fail with -EINVAL, in which we shall
be able to try the fallback option, and the other is -EBUSY due to repeated
registration, in which we shall just exit the loop.
So in conclusion, when error code is -EBUSY or successful return, both
indicating a proper driver is already registered, we shall bail the loop,
other than that, we shall continue to try the fallback option.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Use more explicit goto statements to handle common error code
path instead of a lot of if/else.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Move logic independent of c->apicid's initialization status out of
the if/else, leveraging that cpu_data[] now doesn't start out zero-
initialized. Constify c and have it have an initializer.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Forever since its introduction x86_mc_get_cpu_info() has been checking a
structure field against BAD_APICID which would never have been set to
that particular value. Arrange for this to actually be true ahead of
CPU detection having run, which then also includes pruning after CPU
removal.
For this,
- introduce a new helper function splitting reset logic out of
identify_cpu(), and going slightly farther than the original code to
achieve consistent results,
- introduce a new helper macro for both initializing and resetting
various fields.
For boot_cpu_data this in particular means that cpuid_level will no
longer be set to the bogus value of -1. Even before removal of 32-bit
support we already assumed basic CPUID leaves to be available.
Furthermore make sure initialize_cpu_data() doesn't populate fields with
BSP's values which clearly aren't going to be applicable to APs.
Fixes: e16fc5ba59 ("x86: mce: Provide extended physical CPU info")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
llc_colors_str being outside the main loop makes domains without
explicit coloring inherit the colors of the last colored domain parsed.
Move it inside so that's no longer the case.
Fixes: 5948dc16759c("xen/arm: add support for cache coloring...")
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Rule 10.1: Operands shall not be of an
inappropriate essential type
The following are non-compliant:
- boolean used as a numeric value.
The result of the '__isleap' macro is a boolean.
Suppress analyser tool finding.
The result of 'NOW() > timeout' is a boolean,
which is compared to a numeric value. Fix this.
Regression was introdiced by commit:
be7f047e08 (xen/arm: smmuv3: Replace linux functions with xen functions.)
Remove pointless cast '(const unsigned short int *)'.
The source array and the destination pointer are both of the same type.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Wrap sysctl hypercall def and sysctl.o with CONFIG_SYSCTL, and since
PV_SHIM_EXCLUSIVE needs sorting in the future, we move them out of
PV_SHIM_EXCLUSIVE condition at the same time.
We need to make SYSCTL with prompt back, add help info and set default
value as y. We shall at least provide "# CONFIG_SYSCTL is not set" in preset
configs for PV shim on x86. With that, all dependent option get covered and
could be deleted.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally
equivalent "if !...") in Kconfig file, since negative dependancy will badly
affect allyesconfig. Although "if !PV_SHIM_EXCLUSIVE" for CONFIG_VGA is not
truly a dependency, setting PV_SHIM_EXCLUSIVE y still makes it unconfigurable.
So we remove it here too
Add "#CONFIG_xxx is not set" for above options in presets for x86 PV shim, as
the explicit declaration is to ephasize setting for the shim is different
from the general default.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Function arch_do_sysctl is to perform arch-specific sysctl op.
Some functions, like psr_get_info() for x86, DTB overlay support for arm,
are solely available through sysctl op, then they all shall be wrapped
with CONFIG_SYSCTL
Also, remove all #ifdef CONFIG_SYSCTL-s in arch-specific sysctl.c, as
we put the guardian in Makefile for the whole file.
Since PV_SHIM_EXCLUSIVE needs sorting in the future, we move
obj-$(CONFIG_SYSCTL) += sysctl.o out of PV_SHIM_EXCLUSIVE condition.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com>
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Function sched_adjust_global is designed for XEN_SYSCTL_scheduler_op, so
itself and its calling flow, like .adjust_global, shall all be wrapped.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Stewart Hildebrand <stewart@stew.dk> #a653
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Alejandro Vallejo