The only reference of hvm_copy_context_and_params() is in
arch/x86/mm/mem_sharing.c, so it shall be wrapped with CONFIG_MEM_SHARING.
Otherwise it will become unreachable when MEM_SHARING=n, and hence violating
Misra rule 2.1.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Grygorii Strashko <grygorii_strashko@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Since commit b992273472 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
HVM Intel VT-x support can be disabled, but it still keeps VMX
code partially built-in. Particularly in HVM code there are two places:
1) hvm/dom0_build.c
dom0_construct_pvh()->pvh_populate_p2m()
...
if ( cpu_has_vmx && paging_mode_hap(d) && !vmx_unrestricted_guest(v) )
{
...
[unreachable for !cpu_has_vmx case]
rc = pvh_setup_vmx_realmode_helpers(d);
pvh_setup_vmx_realmode_helpers() allocates memory and configures
HVM_PARAM_VM86_TSS_SIZED
HVM_PARAM_IDENT_PT
2) hvm/hvm.c
hvm_set_param()
...
case HVM_PARAM_IDENT_PT:
if ( !paging_mode_hap(d) || !cpu_has_vmx )
{
d->arch.hvm.params[index] = value;
break;
}
[unreachable for !cpu_has_vmx case]
...
Hence HVM_PARAM_IDENT_PT/HVM_PARAM_VM86_TSS_SIZED are used only by VMX code
above code become unreachable in !cpu_has_vmx case and can be optimazed
when !CONFIG_INTEL_VMX.
Replace "cpu_has_vmx" with using_vmx() to account !CONFIG_INTEL_VMX and allow
compiler DCE to optimize code.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Use an existing macro instead of open-coding the operation and flags
handling, just like we already do in x86_emul_rmw(). While possibly
yielding slightly larger compiled code, it's easier to maintain this
way.
Note that the setting of dst.orig_val was already redundant with that
done ahead of the main switch() (where DST_MEM is handled), the latest
as of 4e59f578cb ("x86emul: simplify SHLD/SHRD handling").
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
MISRA C Rule 11.3 prohibits casting between pointer-to-object types that
are different types. The original code used a macro 'NextMemoryDescriptor()'
that performed a non-compliant cast from 'UINT8*' to 'EFI_MEMORY_DESCRIPTOR*'.
Change 'efi_process_memory_map_bootinfo()' function parameter from
'EFI_MEMORY_DESCRIPTOR *' to 'void *' for the memory map parameter. Replace
usage of 'NextMemoryDescriptor()' macro with compliant pointer arithmetic
on 'void *', followed by a single compliant cast to 'EFI_MEMORY_DESCRIPTOR *'.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
The function 'check_partial_fdt()' performs an explicit check for the FDT
magic number (FDT_MAGIC) before calling 'fdt_check_header(). This check is
redundant, because 'fdt_check_header()' includes checking the magic number.
Remove the redundant check to simplify the code and rely on the library
function to perform header validation.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
The current implementation of 'free_init_memory()' fills the freed '__init'
and '__initdata' memory regions with a faulting instruction before unmapping
and returning them to the heap. However, after unmapping, any access to this
region will result in a page fault, making the instruction fill redundant.
Replace the instruction fill with a call to 'memset()', zeroing the entire
region before it is unmapped and returned to the allocator.
Additionally, this change resolves a violation of MISRA C:2012 Rule 11.3
(cast between pointer to object type and pointer to a different object type),
caused by performing a cast from a 'char *' to a 'uint32_t *' pointer to
write instructions directly into memory, which is not compliant with MISRA
guidelines.
No functional changes.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
When stopping a core cpu_gic_callback is called in non-alloc
context, which causes xfree in release_irq to fail an assert.
To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
v3->v4:
* make irqactions static
* collect RBs
v2->v3:
* no changes
v1->v2:
* use percpu actions
When stopping a core deinit_timer_interrupt is called in non-alloc
context, which causes xfree in release_irq to fail an assert.
To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
v3->v4:
* make irqactions static
* collect RBs
v2->v3:
* no changes
v1->v2:
* use percpu actions
Remove the redundant local 'DTB_MAGIC' definition and replace its usage
with the canonical 'FDT_MAGIC' from 'libfdt'.
Amends: 66edeb2e39 (arm: copy DTB appended to zImage)
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Much like done later in the function, syscall and hypercall vectors can
have their bits set without use of LOCKed accesses.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Many *.c files are symlinked while building, so along with generated *.h
files they ought to be removed. Conversely $(TARGET) doesn't need removing
twice.
Fixes: cb4fcf70b2 ("x86emul: parallelize SIMD test code building")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
buildmakevars2shellvars is used nowhere, so remove it.
Amends: 1eb944f650 ("tools: remove qemu-traditional")
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The LAML field should follow the TCG PC Client Platform Firmware Profile
Specification Version. Version 1.06 Revision 52 says:
'The TCG ACPI specification uses the field name "Log Area Minimum
Length", but the field value is the actual log area length reserved by
Platform Firmware, not a lower bound.'
Remove the now-unused TPM_LOG_AREA_MINIMUM_SIZE.
No functional change.
Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
Acked-by: Jan Beulich <jbeulich@suse.com>
io_apic.c has a lot of ad-hoc for(;;) and while(1) loops for iterating
over irq_pin_list entries. Replace them with a standardized
for loop using pin_list_next() to advance entry.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
These files 'docs/misc/kconfig{,-language}.txt' were deleted, but
references are still present in Xen. Remove them to clean-up.
Fixes: 044503f61c ("docs: Delete kconfig docs to fix licensing violation")
Fixes: f80fe2b34f ("xen: Update Kconfig to Linux v5.4")
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
int64_aligned_t and uint64_aligned_t need to be exposed when the GNU C compiler
is in use.
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
According to the commit b66e28226d ("x86/mem_sharing: gate enabling on
cpu_has_vmx") the Xen memory sharing support is only possible on platforms
with "Intel VT-x" (INTEL_VMX=y) enabled.
The same commit is also added runtime check for "cpu_has_vmx" in
mem_sharing_control() which blocks access to XENMEM_sharing_ops if
!cpu_has_vmx.
Hence add dependency from INTEL_VMX for MEM_SHARING Kconfig option.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This macro was there when ia64 was a thing, nowaday, this macro isn't meaningful
anymore and is actually a slightly disguised nr_ioapic_entries array access.
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Mirroring the cleanup to rdmsr(), do the same to wrmsr(). It now has the same
API as wrmsrl(), but we'll want to drop that wrapper in due course.
It's telling that almost all remaining users pass in 0. Most are converted
directly to WRMSRNS, but a few are not.
MSR_VIRT_SPEC_CTRL is unconditionally intercepted and is orders of magnitude
more expensive than just serialising. In disable_lapic_nmi_watchdog(), the P4
case won't run on hardware which has anything more than plain WRMSR.
For CTR_WRITE() in op_model_athlon.c there is a logical change in behaviour,
but it's fixing a bug. Peformance counters typically get written to -(count)
as they generate an interrupt on overflow. The performance counters even in
the K8 were 48 bits wide, and this wrmsr() not being a wrmsrl() appears to
have been an oversight in commit b5103d692a ("x86 oprofile: use
rdmsrl/wrmsrl") which converted all other users, and appears to be the last
time there was an attempt to unify the MSR APIs.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
We want a consistent MSR API, and these want to be named rdmsr() and wrmsr(),
but not with their current APIs. The current rdmsr() flavours writing to
their parameters by name makes code that reads like invalid C, and is
unergonomic to use in lots of cases.
Change the API, and update the callers all in one go. Where appropriate,
update the write side to wrmsrns() as per the recommendation.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Use define X86_MODE_64BIT instead of constant in hvm_hypercall() for "mode"
conditional check to improve code readability.
Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Acked-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>
The latest oxenstored from Xapi-project fails to start up:
launch-xenstore[1201]: Starting /usr/sbin/oxenstored...
launch-xenstore[1222]: Fatal error: exception
Dynlink.Error (Dynlink.Cannot_open_dll "Dynlink.Error (Dynlink.Cannot_open_dll
\"Failure(\\\"/usr/libexec/xen//ocaml/xsd_glue/xenctrl_plugin/domain_getinfo_v1.cmxs:
undefined symbol: xc_domain_getinfo_single\\\")\")")
This is because domain_getinfo_v1.cmxs isn't dynamically linked correctly.
Fill in the correct variable, and remove the xen prefix from xenctrl.
Reported-by: Edwin Török <edwin.torok@citrix.com>
Suggested-by: Edwin Török <edwin.torok@citrix.com>
Fixes: a6576011a4 ("ocaml/libs: Implement a dynamically-loaded plugin for Xenctrl.domain_getinfo")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Shawn is no longer with Raptor Engineering. For now, add myself as PPC64
reviewer.
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
symbols-dummy.c and the generated .xen-syms.?.S may place their symbols in
different sections: Like for all C files, -fdata-sections may be in effect
there. As a result, besides these symbols moving, there may then also be
different amounts of "end" symbols inserted between them. While the
movement is likely not problematic, the change in table size is - linking
passes 2 and 3 want no address (and hence no size) changes between them.
As, at least right now, the "end" symbols are useful only for code, limit
their emission accordingly. When data symbols are emitted (i.e. when
LIVEPATCH=y), this obviously also has a positive effect on overall table
size (I'm seeing almost 600 entries going away in the build I'm looking
at).
Fixes: d3b637fba3 ("symbols: arrange to know where functions end")
Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Tested-by: Roger Pau Monné <roger.pau@citrix.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
With large NR_CPUS on-stack cpumask_t variables are problematic. Now that
the IRQ handler can't be invoked in a nested manner anymore, we can
instead use a per-CPU variable. While we can't use scratch_cpumask in code
invoked from IRQ handlers, simply amend that one with a HPET-special form.
(Note that only one of the two IRQ handling functions can come into play
at any one time.)
Fixes: 996576b965 ("xen: allow up to 16383 cpus")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Release-Acked-By: Oleksii Kurochko<oleksii.kurochko@gmail.com>
When Entrysign has been mitigated in firwmare, it is believed to be safe to
rely on the CPU patchloader again. This avoids us needing to maintain the
digest table for all new microcode indefinitely.
Relax the digest check when firmware looks to be up to date, and leave behind
a clear message when not.
When the Zen6 (also Fam1ah processors) model numbers are known, they'll want
excluding from the range.
This is best-effort only. If a malicious microcode has been loaded prior to
Xen running, then all bets are off.
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>
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>
For Zen3-5 microcode blobs signed with the updated signature scheme, the
checksum field has been reused to be a min_revision field, referring to the
microcode revision which fixed Entrysign (SB-7033, CVE-2024-36347).
Cross-check this when trying to load microcode, but allow --force to override
it. If the signature scheme is genuinely different, a #GP will occur.
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>
EIO is not the only error that ucode_ops.apply_microcode() can produce.
EINVAL, EEXISTS and ENXIO can be generated too, each of which mean that Xen is
unhappy in some way with the proposed blob.
Some of these can be bypassed with --force, which will cause the parallel load
to be attempted.
Fixes: 5ed12565aa ("microcode: rendezvous CPUs in NMI handler and load ucode")
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>
This change enables compatibility for measuring code coverage
with Clang versions 11 through 20 by supporting their respective raw
profile formats.
1- Added support for LLVM raw profile versions 5, 6, 7, 8, 9, and 10.
2- Initialized llvm_profile_header for all versions based on llvm source
code in compiler-rt/include/profile/InstrProfData.inc for each version.
3- We tested this patch for all Clang versions from 11 through 20
on x86 platform.
4- Fixed linking warnings related to LLVM profile sections in x86.
Signed-off-by: Saman Dehghan <samaan.dehghan@gmail.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Tested-by: Wentao Zhang <wentaoz5@illinois.edu>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
If a SR-IOV card presents an I/O space inside a BAR the
code will continue to loop on the same card.
This is due to the missing increment of the cycle variable.
Fixes: a1a6d59862 ("pci: split code to size BARs from pci_add_device")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Using dynamically allocated / maintained vectors has several downsides:
- possible nesting of IRQs due to the effects of IRQ migration,
- reduction of vectors available for devices,
- IRQs not moving as intended if there's shortage of vectors,
- higher runtime overhead.
As the vector also doesn't need to be of any priority (first and foremost
it really shouldn't be of higher or same priority as the timer IRQ, as
that raises TIMER_SOFTIRQ anyway), simply use the lowest one above the
legacy range. The vector needs reserving early, until it is known whether
it actually is used. If it isn't, it's made available for general use.
With a fixed vector, less updating is now necessary in
set_channel_irq_affinity(); in particular channels don't need transiently
masking anymore, as the necessary update is now atomic. To fully leverage
this, however, we want to stop using hpet_msi_set_affinity() there. With
the transient masking dropped, we're no longer at risk of missing events.
AMD interrupt remapping code so far didn't "return" a consistent MSI
address when translating an MSI message. Clear respective fields there, to
keep the related assertion in set_channel_irq_affinity() from triggering.
Fixes: 996576b965 ("xen: allow up to 16383 cpus")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Keeping channels enabled when they're unused is only causing problems:
Extra interrupts harm performance, and extra nested interrupts could even
have caused worse problems. However, on all Intel hardware I looked at
closely, a 0->1 transition of the enable bit causes an immediate IRQ.
Hence disabling channels isn't a good idea there. Set a "long" timeout
instead.
Along with that also "clear" the channel's "next event", for it to be
properly written by whatever the next user is going to want (possibly
avoiding too early an IRQ).
Further, along the same lines, don't enable channels early when starting
up an IRQ. This doesn't need to happen earlier than from
set_channel_irq_affinity() (once a channel goes into use the very first
time). This eliminates a single instance of
(XEN) [VT-D]INTR-REMAP: Request device [0000:00:1f.0] fault index 0
(XEN) [VT-D]INTR-REMAP: reason 25 - Blocked a compatibility format interrupt request
during boot. (Why exactly there's only one instance, when we use multiple
counters and hence multiple IRQs, I can't tell. My understanding would be
that this was due to __hpet_setup_msi_irq() being called only after
request_irq() [and hence the .startup handler], yet that should have
affected all channels.)
Fixes: 3ba523ff95 ("CPUIDLE: enable MSI capable HPET for timer broadcast")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
The earlier change wasn't correct as far as shim-exclusive mode goes:
Shadow mode is still to be enabled permitted there, yet the generic
paging-log-dirty (and more generally domctl) part of the code still is
unwanted (and cannot be used anyway, as domctl_lock_acquire() isn't
available).
Fixes: 2ae8a68df2 ("x86/mm: correct PG_log_dirty definition")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Release-Acked-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
If not available, fallback to using YAJL.
The code is using json_c_visit() which was introduced in 0.13.
json_object_new_null() and json_object_new_uint64() where added to
0.14. And the last one json_object_new_array_ext() was introduced in
0.15.
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Penny Zheng