Add per domain server features, which are initialized by the supported
features at domain introduction, or by live update from the migration
stream. This requires to add the DOMAIN_DATA record to the migration
stream, but for now it will only contain the feature word.
Advertise the Xenstore features to guests by setting the appropriate
bits in the ring page.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Add all the missing migration record structures and defines to the
xenstore_state.h header file.
Update the version of the migration stream to "2". In order to allow
receiving version 1 streams, change the version check of the header
to reject only streams with a version higher than the current known
one.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
In order to prepare xenstored supporting migration stream versions
other than 1, add a parameter to the live update command allowing to
specify the version of the migration stream.
This will allow going back from xenstored using version 2 per default
to a xenstored only accepting version 1.
For now only version 1 is supported.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Add functions for getting and setting Xenstore features to libxenstore:
xs_get_features_supported(): return the features supported by the
running Xenstore implementation as defined in xs_wire.h via the
XENSTORE_SERVER_FEATURE_* macros.
xs_get_features_domain(): return the features offered for a specific
domain.
xs_set_features_domain(): set the features available for a specific
domain.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
ARINC653 specification requires partition scheduling to be deterministic
and periodic over time.
However, the use of current timestamp (now) as the baseline to calculate
next_major_frame and next_switch_time introduces a delay in the start of
major frame at every period, which breaks determinism and periodicity in
partition scheduling.
For example, we observe 3.5 msec of accumulated delay at the 21st major
frame with the following configuration.
Target : qemuarm64
xen version : 4.19 (43aeacff86, x86/IRQ: constrain creator-domain-ID assertion)
dom1 : 10 msec runtime
dom2 : 10 msec runtime
$ a653_sched -p Pool-arinc dom1:10 dom2:10
0.014553536 ---x d?v? runstate_change d1v0 runnable->running //1st major
frame
0.034629712 ---x d?v? runstate_change d1v0 runnable->running //2nd major
frame
<snip>
0.397747008 |||x d?v? runstate_change d1v0 runnable->running //20th
major frame
0.418066096 -||x d?v? runstate_change d1v0 runnable->running //21st
major frame
This is due to an inherent delta between the time value the scheduler timer
is programmed to be fired with and the time value the schedule function
is executed.
Another observation that breaks the deterministic behavior of partition
scheduling is a delayed execution of schedule(); It was called 14 msec
later than programmed.
1.530603952 ---x d?v? runstate_change d1v0 runnable->running
1.564956784 --|x d?v? runstate_change d1v0 runnable->running
Enforce the periodic behavior of partition scheduling by using the value
next_major_frame as the base to calculate the start of major frame and
the next domain switch time.
Per discussion with Nathan Studer, there are odd cases the first minor
frame can be also missed. In that scenario, iterate through the schedule
after resyncing the expected next major frame.
Per suggestion from Stewart Hildebrand, use a modulo operation to
calculate the start of next major frame.
Fixes: 22787f2e10 ("ARINC 653 scheduler")
Suggested-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Suggested-by: Nathan Studer <nathan.studer@dornerworks.com>
Signed-off-by: Anderson Choi <anderson.choi@boeing.com>
Reviewed-by: Stewart Hildebrand <stewart@stew.dk>
Use the more "modern" form, thus doing away with effectively open-coding
xmalloc_array() at the same time. While there is a difference in
generated code, as xmalloc_bytes() forces SMP_CACHE_BYTES alignment, if
code really cared about such higher than default alignment, it should
request so explicitly.
Also clear the pointers when freeing them.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
When a running unit is about to be scheduled out due to a competing unit
with the highest remaining credit, the residual credit of the previous
unit is currently ignored in csched2_runtime() because it hasn't yet
been reinserted into the runqueue.
As a result, two equally weighted, busy units can often each be granted
almost the maximum possible runtime (i.e. consuming CSCHED2_CREDIT_INIT
in one shot) when only those two are active. In broad strokes two units
switch back and forth every 10ms (CSCHED2_MAX_TIMER). In contrast, when
more than two busy units are competing, such coarse runtime allocations
are rarely seen, since at least one active unit remains in the runqueue.
To ensure consistent behavior, have csched2_runtime() take into account
the previous unit's latest credit when it still can/wants to run.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Juergen Gross <jgross@suse.com>
Introduce new CI job to run x86 XTF argo test under QEMU to smoke test argo
feature functionality in upstream CI.
The new job lead time is ~30s, limit max job duration to 60s.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Scratch page quarantining is tied to specific IOMMU implementations, not
architectures, so tie it to AMD_IOMMU and INTEL_IOMMU instead of X86.
Fixes: dd7e55a884 ("iommu: restrict scratch page quarantining to x86")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
When attempting to xl pci-assignable-remove a PCI device, we encounter:
$ xl pci-assignable-remove 00:01.0
(XEN) SMMUv3: <no-node>: not attached to domain 32753
(XEN) d[IO]: deassign (0000:00:01.0) failed (-3)
libxl: error: libxl_pci.c:910:libxl__device_pci_assignable_remove: failed to de-quarantine 0000:00:01.0
When a PCI device is being deassigned from domIO,
arm_smmu_deassign_dev() should return before checking the smmu domain.
Fixes: 63919fc4d1 ("xen/arm: smmuv3: Add PCI devices support for SMMUv3")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
In arm_smmu_deassign_dev(), the return value from to_smmu_domain() is
NULL-checked. However, the implementation of to_smmu_domain() is a
container_of lookup, so the return value is unlikely to ever be NULL. In
case of a NULL argument to to_smmu_domain(), we will attempt to
dereference the non-NULL return value and encounter undefined behavior
and a crash:
$ xl pci-assignable-remove 00:01.0
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in drivers/passthrough/arm/smmu-v3.c:221:9
(XEN) applying non-zero offset ffffffffffffffc0 to null pointer
(XEN) Xen WARN at common/ubsan/ubsan.c:174
(XEN) ----[ Xen-4.21-unstable arm64 debug=y ubsan=y Tainted: C ]----
...
(XEN) Xen call trace:
(XEN) [<00000a0000350b2c>] ubsan.c#ubsan_epilogue+0x14/0xf0 (PC)
(XEN) [<00000a00003523e0>] __ubsan_handle_pointer_overflow+0x94/0x13c (LR)
(XEN) [<00000a00003523e0>] __ubsan_handle_pointer_overflow+0x94/0x13c
(XEN) [<00000a0000392f9c>] smmu-v3.c#to_smmu_domain+0x3c/0x40
(XEN) [<00000a000039e428>] smmu-v3.c#arm_smmu_deassign_dev+0x54/0x43c
(XEN) [<00000a00003a0300>] smmu-v3.c#arm_smmu_reassign_dev+0x74/0xc8
(XEN) [<00000a00003a7040>] pci.c#deassign_device+0x5fc/0xe0c
(XEN) [<00000a00003ade7c>] iommu_do_pci_domctl+0x7b4/0x90c
(XEN) [<00000a00003a34c0>] iommu_do_domctl+0x58/0xf4
(XEN) [<00000a00002ca66c>] do_domctl+0x2690/0x2a04
(XEN) [<00000a0000454d88>] traps.c#do_trap_hypercall+0xcf4/0x15b0
(XEN) [<00000a0000458588>] do_trap_guest_sync+0xa88/0xdd8
(XEN) [<00000a00003f8480>] entry.o#guest_sync_slowpath+0xa8/0xd8
(XEN)
(XEN) ================================================================================
(XEN) Data Abort Trap. Syndrome=0x4
(XEN) Walking Hypervisor VA 0xfffffffffffffff8 on CPU1 via TTBR 0x00000000406d0000
(XEN) 0TH[0x1ff] = 0x0
(XEN) CPU1: Unexpected Trap: Data Abort
(XEN) ----[ Xen-4.21-unstable arm64 debug=y ubsan=y Tainted: C ]----
...
(XEN) Xen call trace:
(XEN) [<00000a000039e494>] smmu-v3.c#arm_smmu_deassign_dev+0xc0/0x43c (PC)
(XEN) [<00000a000039e428>] smmu-v3.c#arm_smmu_deassign_dev+0x54/0x43c (LR)
(XEN) [<00000a00003a0300>] smmu-v3.c#arm_smmu_reassign_dev+0x74/0xc8
(XEN) [<00000a00003a7040>] pci.c#deassign_device+0x5fc/0xe0c
(XEN) [<00000a00003ade7c>] iommu_do_pci_domctl+0x7b4/0x90c
(XEN) [<00000a00003a34c0>] iommu_do_domctl+0x58/0xf4
(XEN) [<00000a00002ca66c>] do_domctl+0x2690/0x2a04
(XEN) [<00000a0000454d88>] traps.c#do_trap_hypercall+0xcf4/0x15b0
(XEN) [<00000a0000458588>] do_trap_guest_sync+0xa88/0xdd8
(XEN) [<00000a00003f8480>] entry.o#guest_sync_slowpath+0xa8/0xd8
Fix by changing to_smmu_domain() to return NULL in case of a NULL
argument.
Fixes: 452ddbe359 ("xen/arm: smmuv3: Add support for SMMUv3 driver")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
Enable the use of IOMMU + PCI in dom0 without having to specify
"pci-passthrough=yes". Due to possible platform specific dependencies
of the PCI host, we rely on dom0 to initialize it and perform
a PCI PHYSDEVOP calls to add each device to SMMU.
Because pci_passthrough is not always enabled on all architectures, add
a new function arch_pci_device_physdevop that checks if we need to enable
a subset of the PCI subsystem related to managing IOMMU configuration
for PCI devices.
Enable pci_init() for initializing Xen's internal PCI subsystem, and
allow PCI PHYSDEV ops when pci-passthrough is disabled.
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
On Arm without pci-passthrough=on Xen does not know anything about
present PCI devices due to PHYSDEVOP_pci_device_add not executing. This
causes PHYSDEVOP_pci_device_reset to fail when trying to find the device
that is being reset and return ENODEV.
Add explicit is_pci_passthrough_enabled check to return a more
meaningful EOPNOTSUPP code.
This change should not affect x86 behavior as pci-passthrough is always
enabled there.
Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
These functions never return to their caller,
causing a violation of MISRA C Rule 2.1:
"A project shall not contain unreachable code".
Add the `noreturn' attribute to fix this.
No functional changes.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> # EFI
Add MISRA C rules to the monitored set.
All these rules are 'accepted' for XEN, have zero or few violations,
and should be enabled for the ECLAIR scan.
Rule 17.2 is enabled to detect accidental direct recursion.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Add CONSOLE_PREFIX symbol to keep the prefix of the hypervisor's diagnostic
messages.
No functional change.
Signed-off-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
All IOMMU_QUARANTINE_* options are exposed on Arm since 163c6b5898
("xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option"). However,
only NONE and BASIC are implemented in any Arm iommu driver since
63919fc4d1 ("xen/arm: smmuv3: Add PCI devices support for SMMUv3") and
ca8f6ffeb6 ("xen/arm: smmuv2: Add PCI devices support for SMMUv2").
SCRATCH_PAGE is not yet implemented in any Arm iommu driver. Restrict
scratch page quarantining to x86 for now.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Clang UBSAN reports:
UBSAN: Undefined behaviour in drivers/char/ns16550.c:124:49
applying non-zero offset 0000000000000001 to null pointer
And
UBSAN: Undefined behaviour in drivers/char/ns16550.c:142:49
applying non-zero offset 0000000000000001 to null pointer
Move calculation of the MMIO address so it's only done if the MMIO is
mapped by Xen, otherwise the address is not consumed anyway because IO port
access is used instead.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The current strtoll() implementation in hvmloader requires hex number to be
prefixed with 0x, otherwise strtoll() won't parse them correctly even when
calling the function with base == 16.
Fix this by not unconditionally setting the base to 10 when the string is
not 0 prefixed, this also allows parsing octal numbers not 0 prefixed.
While there also handle '0X' as a valid hex number prefix, together with
'0x'.
No functional change intended to the existing call sites.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The builder in common code already does this, but it's not callable
independently from a separate location. Create a function x86 can
call to use its own domain builder, using createdomain arguments
as the parsed data.
The bindings are moved on the next patch so it's strict code motion.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reduce the scope of dom0less_iommu, iommu and cpupool_node. iommu, in
particular, wasn't being cleared, so the wrong flags may make it to
domains that should not have them.
Fixes: 1d2b4f3049fd("xen/arm, doc: Add a DT property to specify...")
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
It deals with a single domain, and will be called on a later patch
by a new function parse_dom0less_node(), so the new name is apt.
Also, pass parameters using boot_domain instead as the plan is to use it
as dumping gound for all the extracted information from the bindings.
Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Later patches move the bindings to a separate function and expect the
outputs to land in fields of a boot_domain. Adjust llc_color_str to
live inside boot_domain so it can be parsed later on.
Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
In later patches boot_domain becomes the common ground for the bindings
to drop the extracted information. In preparation for the bindings
themselves to be in a separate function, introduce kernel_info early in
the domain construction loop.
This simplifies a later diff, turning it into a strict cut-and-paste, rather
than a mutate-on-move.
Lines after domain_create() don't make use of the "d_cfg" and "flags"
variables because those will disappear when the bindings move to a
separate file.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Add the arguments that create_domain() takes to boot_domain. This creates
a consistent place to drop the outputs of the dom0less bindings.
Not a functional change. Later patches use these fields as the outputs of
the dom0less parsing functions.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
It's meant to be usable by anyone with CONFIG_DOM0LESS_BOOT.
While moving, replace an inclusion of public/domctl.h by a forward
declaration.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
When later on x86 starts using this file in later patches it won't find
device_tree.h because it's only transitively included by arm.
Make it explicit.
Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Trying to boot a compressed kernel with UBSAN enabled, results in the
following warning:
(XEN) UBSAN: Undefined behaviour in common/device-tree/kernel.c:21:12
(XEN) load of misaligned address 00000a0040f89867 for type 'uint32_t'
(XEN) which requires 4 byte alignment
...
(XEN) [<00000a0000529964>] kernel_decompress+0x2bc/0x5bc
(XEN) [<00000a000052a354>] kernel_probe+0x6f0/0x734
(XEN) [<00000a0000528714>] dom0less-build.c#construct_domU+0x188/0x9d8
If &image[image_len - 4] is not aligned to 4B boundary it causes
unaligned access which is undefined behavior on Arm. Use memcpy instead
to be safe.
Fixes: c1be0b102e ("xen/arm: support gzip compressed kernels")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
... to be in line with Misra rule 8.2 requirements.
Fixes: 6ff0cfbfd4 ("mm: allow page scrubbing routine(s) to be arch controlled")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Its initial calculation in cpufreq_statistic_init() is entirely unused,
as do_get_pm_info() recalculates it before use. That re-calculation can
then be done right where the output field is set, eliminating the need
for the internal field. In turn the struct pointer there can then be
constified.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Since we move "!PV_SHIM_EXCLUSIVE" dependency from CONFIG_HVM, there is
a chance that a randconfig picking both PV_SHIM_EXCLUSIVE=y and HVM=y results
in hvm.c being built, but monitor.c not being built, which leaves
functions like monitor_traps(), etc, undefined, causing linking to fail.
So we move monitor.o out of PV_SHIM_EXCLUSIVE condition to fix above linking
failure.
Fixes: 568f806cba ("xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"")
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Xen currently uses an ASID scheme where:
- ASIDs are cycled where a "TLB flush" is performed
- When ASIDs wrap around, perform a full TLB flush
- In exceptional cases, stop using ASIDs
However, the TLB control mode used only flushes the current active ASID of
the logical processor. Which mean that will supply "stale" ASIDs (not flushed),
because it hasn't been actually flushed (TLB_CTRL_FLUSH_ASID only performs a
TLB flush of the ASID set in VMCB).
This affects CPUs where flush-by-asid is available (Fam15h (2011) and later).
To fix this, always flush all ASIDs even when flush-by-asid is available.
Fixes: 64b1da5a2f ("x86/svm: Use flush-by-asid when available")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Wrap the p2m_is_altp2m() check with IS_ENABLED(CONFIG_ALTP2M) to allow the
compiler to short-circuit the condition at build time when ALTP2M is disabled.
Signed-off-by: Petr Beneš <w1benny@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Especially when dealing with large amounts of memory, memset() may not
be very efficient; this can be bad enough that even for debug builds a
custom function is warranted. We additionally want to distinguish "hot"
and "cold" cases (with, as initial heuristic, "hot" being for any
allocations a domain does for itself, assuming that in all other cases
the page wouldn't be accessed [again] soon). The goal is for accesses
of "cold" pages to not disturb caches (albeit finding a good balance
between this and the higher latency looks to be difficult).
Keep the default fallback to clear_page_*() in common code; this may
want to be revisited down the road.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
The present clear_page_sse2() is useful in case a page isn't going to
get touched again soon, or if we want to limit churn on the caches.
Amend it by alternatively using CLZERO, which has been found to be quite
a bit faster on Zen2 hardware at least. Note that to use CLZERO, we need
to know the cache line size, and hence a feature dependency on CLFLUSH
gets introduced.
For cases where latency is the most important aspect, or when it is
expected that sufficiently large parts of a page will get accessed again
soon after the clearing, introduce a "hot" alternative. Again use
alternatives patching to select between a "legacy" and an ERMS variant.
Don't switch any callers just yet - this will be the subject of
subsequent changes.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Stop the compiler from inlining non-trivial memset() and memcpy() (for
memset() see e.g. map_vcpu_info() or kimage_load_segments() for
examples). This way we even keep the compiler from using REP STOSQ /
REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is
available).
With gcc10 this yields a modest .text size reduction (release build) of
around 2k.
Unfortunately these options aren't understood by the clang versions I
have readily available for testing with; I'm unaware of equivalents.
Note also that using cc-option-add is not an option here, or at least I
couldn't make things work with it (in case the option was not supported
by the compiler): The embedded comma in the option looks to be getting
in the way.
Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Move the function to its own assembly file. Having it in C just for the
entire body to be an asm() isn't really helpful. Then have two flavors:
A "basic" version using qword steps for the bulk of the operation, and an
ERMS version for modern hardware, to be substituted in via alternatives
patching.
Alternatives patching, however, requires an extra precaution: It uses
memcpy() itself, and hence the function may patch itself. Luckily the
patched-in code only replaces the prolog of the original function. Make
sure this remains this way.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Move the function to its own assembly file. Having it in C just for the
entire body to be an asm() isn't really helpful. Then have two flavors:
A "basic" version using qword steps for the bulk of the operation, and an
ERMS version for modern hardware, to be substituted in via alternatives
patching.
For RET to be usable in an alternative's replacement code, extend the
CALL/JMP patching to cover the case of "JMP __x86_return_thunk" coming
last in replacement code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
While supposedly safe via enforcing a control flow change when modifying
already prefetched code, it may not really be. Afaik a request is
pending to drop the first of the two options in the SDM's "Handling
Self- and Cross-Modifying Code" section (still present there as of
version 087). Insert a serializing instruction there, and remove the
"noinline" in exchange.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Before we start actually adjusting behavior when ERMS is available,
follow Linux commit 161ec53c702c ("x86, mem, intel: Initialize Enhanced
REP MOVSB/STOSB") and zap the CPUID-derived feature flag when the MSR
bit is clear.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Implement the function early_fdt_map(), which is responsible for mapping
the Device Tree Blob in the early stages of the boot process, for MPU
systems.
We make use of the map_pages_to_xen() and destroy_xen_mappings() APIs.
In particular the latter function is necessary in the case that the
initial mapping of the fdt_header is insufficient to cover the entire
DTB, as we must destroy and then remap the region due to the APIs no
providing support for extending the size of an existing region.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Hari Limaye <hari.limaye@arm.com>
Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
This commit expands xen_mpumap_update/xen_mpumap_update_entry to include
destroying an existing entry.
We define a new helper "disable_mpu_region_from_index" to disable the MPU
region based on index. If region is within [0, 31], we could quickly
disable the MPU region through PRENR_EL2 which provides direct access to the
PRLAR_EL2.EN bits of EL2 MPU regions.
Rignt now, we only support destroying a *WHOLE* MPU memory region,
part-region removing is not supported, as in worst case, it will
leave two fragments behind.
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Signed-off-by: Wei Chen <wei.chen@arm.com>
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Hari Limaye <hari.limaye@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Juergen Gross