It's possible for libxl__json_object_to_json_object() to not set the passed
jso_out parameter, hence initialize it in libxl__json_object_to_json() to
avoid freeing an uninitialized pointer in case of failure.
Reported by XenServer internal Coverity instance.
Fixes: 75fa670e58 ("libxl: Convert libxl__json_object_to_json() to json_object")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
It's possible for json_tokener_parse_verbose() to return NULL and leave the
error parameter unset. Initialize the error variable at definition to an
existing error token to make sure it's not uninitialized in case of
failure.
Reported by XenServer internal Coverity instance.
Fixes: 7e95dab9eb ("libxl: Convert libxl__json_parse() to use json-c")
Fixes: f6c6f2679d ("libxl: Convert libxl__object_to_json() to json-c")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
When the fixes commit re-arranged the code, it made edd=off jump to the
mbr code instead of returning from the function. Previously edd_done
was immediately before ret and skipped the MBR check.
Replace edd_done with .Ledd_mbr_sig for the start of the MBR checking,
and replace .Ledd_mbr_sig_skip with .Ledd_done to exit from the function.
edd=off jumps to .Ledd_done to return from the function, and internal
jumps go to .Ledd_mbr_sig to check edd=skipmbr.
Fixes: 5ec164fd61 ("x86/boot: re-arrange how/when we do disk I/O")
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko<oleksii.kurochko@gmail.com>
Commit 59a1d6d3ea introduced Shim's LoadImage protocol and unloads the
image after loading it (for verification purposes) regardless of the
returned status. The protocol API implies this is the correct behaviour
but we should add a check to protect against the unlikely case this
frees any memory in use.
Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
The function returning zero is an error indication; we shouldn't try to
map MFN 0 and then treat that page as a context table.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Split out AMD SVM and AMD IOMMU, and add myself as a reviewer. Jan,
Andrew and Roger are set as maintainers as they were for the X86 entry.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
I've had the luck to come across a PCI card that exposes a MSI-X capability
where the BIR of the vector and PBA tables points at a BAR that has 0 size.
This doesn't play nice with the code in vpci_make_msix_hole(), as it would
still use the address of such empty BAR (0) and attempt to carve a hole in
the p2m. This leads to errors like the one below being reported by Xen:
d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area
And the device left unable to enable memory decoding due to the failure
reported by vpci_make_msix_hole().
Introduce checking in init_msix() to ensure the BARs containing the MSI-X
tables are usable. This requires checking that the BIR points to a
non-empty BAR, and the offset and size of the MSI-X tables can fit in the
target BAR.
This fixes booting PVH dom0 on Supermicro AS -2126HS-TN servers with AMD
EPYC 9965 processors. The broken device is:
22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)
There are multiple of those integrated controllers in the system, all
broken in the same way.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Released-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
The default shell in FreeBSD is plain sh, which doesn't support the usage
of the '|&' operator:
./automation/scripts/console.exp |& sed 's/\r\+$//'
/tmp/scripts34c427adc6599db29cb91221a0939d85.sh: 16: Syntax error: "&" unexpected
Fix this by using a redirection of stderr into stdout, and then a pipe.
Fixes: a406195c15 ("automation: call expect script with redirected standard error")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
FreeBSD QEMU build requires libinotify, otherwise the build fails with:
./qemu-xen-dir-remote/meson.build:2535:15: ERROR: C shared or static library 'inotify' not found
Install the package and add the /usr/local include and libs paths
explicitly as QEMU configure options.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
- libxl changes:
While doing so, we rename all "*_gen_json" function to "*_gen_jso" as
they have different prototype. All the function pointer are been cast
to (libxl__gen_json_callback) by "gentypes.py" when generating
"*_to_json()" functions.
We also introduce a few more "*_gen_jso" functions for "int" and
"bool" because we can't use json_object_*() functions from json-c
directly like it's done with yajl.
To make the generation of _libxl_types*json.[ch] with both YAJL and
json-c we add "--libjsonc" to gentypes.py so it can generate
functions/types for both.
Also introducing "jsonc_json_gen_fn" in the IDL, to be able to point
to a different function when using json-c.
Also, don't export any of the new *_gen_jso() function, at the cost of
having "_hidden" macro in semi-public headers.
- xl changes:
Also, rework the implementation of printf_info() in `xl` to avoid
using libxl_domain_config_gen_json() which isn't available without
YAJL. The implementation using "json_object" call
libxl_domain_config_to_json() which generate a plain string of JSON,
which we parse to add it to our own json; this avoid a dependency on
the json library used by libxl.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Convert yajl_gen to json_object from lib json-c.
And make use of it in qmp_prepare_cmd(), which can be compiled with
either lib.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
This reuse the "json_callback_*" implemented for the yajl parser as
they don't really need to be changed. It's just awkward to have to
cast between `unsigned char` and `char.`
Replace few strncpy() by memcpy() to let the compiler know we want to
copy the string without the terminating nul, as we are adding it just
after.
Also, it should be possible to keep using YAJL parser when json-c
library isn't available.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
To replace yajl.
Introduce XEN_JSON_LIBS variable, to be able to remove "-lyajl" later.
As a first step, the variable will have both or only -lyajl. Then
commit "configure: Use json-c by default, fallback to yajl" will make
a change to only have one or the other once the code is ready to build
with only json-c.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Declarations of xc_dom_console_init() and
xc_dom_console_set_disconnected() in libxenguest.h don't match their
implementation in the library.
Under arm32, xen_pfn_t is a uint64_t and wider than unsigned long.
Use xen_pfn_t for GFNs in the library to fix that. At the same time
change the parameter name of the implementation to console_gfn,
matching the interface declaration in the header and reality (it is
a GFN, not a PFN).
Fixes: b6fc307b0b ("libs/guest: Set console as disconnected on resume")
Fixes: 971b7d5ecb ("libs/guest: Set console page to disconnected")
Reported-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Julien Grall <jgrall@amazon.com>
There is currently an asymmetry between HVM where the page is cleared
and PV where the contents are restored.
Add xc_dom_console_set_disconnected() to only set the connection flag
for PV guests.
xenconsoled is responsible for setting the console connected when it
attaches.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Initialize xencons_interface's connection field to
XENCONSOLE_DISCONNECTED. xenconsoled will mark the page as connected
when it establishes the connection.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
With hyperlaunch, a domU can start before its console ring is connected
by xenconsoled. With nothing emptying the ring, it can quickly fill
during boot. In domU_write_console(), __write_console() returns 0 when
the ring is full. This loops spins until xenconsoled starts emptying
the ring:
while (len) {
ssize_t sent = __write_console(cons, data, len);
if (sent < 0)
return sent;
data += sent;
len -= sent;
if (unlikely(len))
HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
}
The goal of this patch is to add a way for the frontend to know when a
console is connected. This patch adds a new flag to the end of the
console ring structure. It is used for the backend to indicate that it
has connected and started servicing the page.
The two values are
XENCONSOLE_DISCONNECTED 1
XENCONSOLE_CONNECTED 0
XENCONSOLE_DISCONNECTED indicates to the guest that ring is
disconnected, so it will not be serviced. The guest can avoid writing
into it in that case. A domU can use console hypercalls and only
transition to the ring when it is connected and won't fill and block.
Once the backend (xenconsoled) maps and starts servicing the
console, the flag will be set to XENCONSOLE_CONNECTED (0) to indicate
the backend state to the frontend.
The connected value as 0 will be match the default of a zero-ed console
page. Hyperlaunch can set the flag to XENCONSOLE_DISCONNECTED and let
xenconsoled set to XENCONSOLE_CONNECTED.
Old domU hvc_xen drivers won't check the flag.
New domU hvc_xen running on a new xen/xenconsoled will work properly.
New domU hvc_xen on old xen/xenconsoled should only see a 0 for the flag
and behave as if connected.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
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>
Reading from the E9 port if the emergency console is active should return
0xe9 according to the documentation from Bochs:
https://bochs.sourceforge.io/doc/docbook/user/bochsrc.html
See `port_e9_hack` section description.
Fix Xen so it also returns the port address. OSes can use it to detect
whether the emergency console is available or not.
Fixes: d1bd157fbc ("Big merge the HVM full-virtualisation abstractions.")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.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>
Right now on migrate/resume, all guest memory is allocated with 4k
small pages. This was an intended oversight in the original Migration
v2 implementation.
With some test memory program stressing TLB (many small random memory
accesses) superpages can show a 15% performance improvement.
On the first memory iteration the sender is currently sending memory
in 4MB aligned chunks of GFN space which allows the receiver to
allocate most pages as 2MB superpages instead of single 4KB pages.
This change does not handle 1GB superpages as this will require
changes to the migration protocol.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Move the SCI (System Control and Management Interface) resource cleanup
earlier in the domain_relinquish_resources() sequence to ensure proper
cleanup ordering during domain destruction.
The SCI cleanup is now performed before TEE (Trusted Execution Environment)
cleanup rather than after P2M mapping cleanup. This reordering ensures that
SCI resources are properly released before other subsystems that might
depend on them are torn down.
This change addresses potential resource cleanup dependencies where SCI
resources need to be released before P2M mappings are cleaned up, preventing
potential issues during domain destruction on ARM platforms with SCI support.
Fixes: e2cc10867b ("xen/arm: add generic SCI subsystem")
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Otherwise the check for the SS feature in
check_memory_type_self_snoop_errata() fails unconditionally, which leads to
X86_FEATURE_XEN_SELFSNOOP never being set.
We could also avoid this by not doing the reset_cpuinfo() for the BSP in
identify_cpu(), because SS detection uses boot_cpu_data. However that
creates an imbalance on the state of the BSP versus the APs in the
identify_cpu() code.
I've opted for the less controversial solution of populating FEATURESET_1d
in generic_identify(), as the value is already there. The same is done for
the AMD faulting probe code. While there also populate the FEATURESET_1c
element, as the value is in context.
Fixes: f2663ca2e5 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Commit 59a1d6d3ea replaced the Verify status check with
!EFI_ERROR(...), this changed the behaviour to consider any warnings
(EFI_WARN_) to be considered a successful verification.
This commit reverts that behaviour change.
Fixes: 59a1d6d3ea ("efi: Support using Shim's LoadImage protocol")
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.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>
HWP and amd-cppc-epp are both governor-less driver, so we introduce
"is_governor_less" flag and cpufreq_is_governorless() to help bypass
governor-related info on dealing with cpufreq para.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
We extract cppc info from "struct xen_get_cpufreq_para", where it acts as
a member of union, and share the space with governor info.
However, it may fail in amd-cppc passive mode, in which governor info and
CPPC info could co-exist, and both need to be printed together via xenpm tool.
If we tried to still put it in "struct xen_get_cpufreq_para" (e.g. just move
out of union), "struct xen_get_cpufreq_para" will enlarge too much to further
make xen_sysctl.u exceed 128 bytes.
So we introduce a new sub-field GET_CPUFREQ_CPPC to dedicatedly acquire
CPPC-related para, and make get-cpufreq-para invoke GET_CPUFREQ_CPPC
if available.
New helpers print_cppc_para() and get_cpufreq_cppc() are introduced to
extract CPPC-related parameters process from cpufreq para.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com> # hypervisor
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
Even if Xen governor is not used in amd-cppc active mode, we could
somehow deduce which performance policy (CPUFREQ_POLICY_xxx) user wants to
apply through which governor they choose, such as:
If user chooses performance governor, they want maximum performance, then
the policy shall be CPUFREQ_POLICY_PERFORMANCE
If user chooses powersave governor, they want the least power consumption,
then the policy shall be CPUFREQ_POLICY_POWERSAVE
Function cpufreq_policy_from_governor() is responsible for above transition,
and it shall be also effective when users setting new governor through xenpm.
Userspace is a forbidden choice, and if users specify such option, we shall
not only give warning message to suggest using "xenpm set-cpufreq-cppc", but
also error out.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.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>
amd-cppc is the AMD CPU performance scaling driver that introduces a
new CPU frequency control mechanism. The new mechanism is based on
Collaborative Processor Performance Control (CPPC) which is a finer grain
frequency management than legacy ACPI hardware P-States.
Current AMD CPU platforms are using the ACPI P-states driver to
manage CPU frequency and clocks with switching only in 3 P-states, while the
new amd-cppc allows a more flexible, low-latency interface for Xen
to directly communicate the performance hints to hardware.
"amd-cppc" driver is responsible for implementing CPPC in passive mode, which
still leverages Xen governors such as *ondemand*, *performance*, etc, to
calculate the performance hints. In the future, we will introduce an advanced
active mode to enable autonomous performence level selection.
Field epp, energy performance preference, which only has meaning when active
mode is enabled and will be introduced later in details, so we read
pre-defined BIOS value for it in passive mode.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Right now, no matter for code construction or hardware restriction, HW_ALL
shall be the only expected values in _PSD for AMD CPPC mode
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
PVH guests have no DM, so this causes the guest to fetch the online CPU
bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.
Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
the GPE handler in addition to anything ACPI CPU hotplug related.
This shrinks PVH's DSDT substantially and prevents spuriously executing
a large amount of AML with no purpose at all.
Fixes: 062975dc9441("acpi: PVH guests need _E02 method")
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Live update is now working with the PVH variant of xenstore-stubdom.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Remove redundant domid_free() call in the XEN_DOMCTL_createdomain error
handling path to prevent a double-free condition.
When domain_create() fails, it internally calls _domain_destroy() during
its cleanup routine, which already invokes domid_free() to release the
allocated domain ID. The additional domid_free() call in the domctl error
path creates a double-free scenario, triggering an assertion failure in
domid.c:
Assertion 'rc' failed at common/domid.c:84
The domain creation flow is:
1. domid_alloc() allocates a domain ID
2. domain_create() is called with the allocated ID
3. If domain_create() fails:
a) domain_create() calls _domain_destroy() internally
b) _domain_destroy() calls domid_free() to release the ID
c) domctl incorrectly calls domid_free() again
This double-free violates the domain ID management invariants and causes
system instability. The fix ensures domid_free() is called exactly once
per allocated domain ID, maintaining proper resource cleanup
semantics.
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Fixes: 2d50650607 ("xen/domain: unify domain ID allocation")
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Roger Pau Monne