From its introduction it has been used solely to add and remove pools.
No list traversal or alike did ever occur. Drop all of this as being dead
code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
For a long time (if not forever) this lock has been referenced only from a
single CU. Misra C:2012 rule 8.7 (which we didn't accept yet) wants us to
have such identifiers non-external.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Rename the enum to intc_variant and the structure member from hw_version
to hw_variant to better reflect that these values select between
different controller variants, not versions of the same one.
Requested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
In preparation for a hypervisor change also include the nul terminator in
the size calculations. (Note that xc_flask_getbool_byid() doesn't support
FLASK_GETBOOL's "ID being -1" variant of operation, and hence doesn't need
fiddling with.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
These existed to work around a bug in older GCC when using struct-casting for
variable initialisation. However, our baseline toolchain is new enough to not
suffer this bug.
Removing these resolves two MISRA Rule 9.2 violations which exist in release
builds of Xen only, where "= { ... }" is disallowed for simple scalar
initialisation.
The BUILD_BUG_ON() in xenmem_add_to_physmap() cannot stay as it is, because
INVALID_GFN is not an Integer Constant Expression. Replace it BUILD_ERROR()
which is the nearest available alternative.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Simply define shadow_audit_enable to be false for the !SHADOW_AUDIT case.
Change the variable to be a bool, and __read_mostly as it's only enabled by
debugkey.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Adjust kexec and kimage to more closely adhere to Xen style.
Sort the includes, dropping duplicates (kexec.h) and unused (ctype.h and
kernel.h).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
The v1 interface was declared obsolete in Xen 4.4 (2013) when kexec in Xen was
overhauled.
The only known user of the v1 interface was the classic-xen fork of Linux.
Linux PVOps does not interact with Xen kexec directly, delegating it entirely
to userspace (i.e. kexec-tools). Xen support in kexec-tools was part of this
work, and uses the "new" interface.
As such, there's no sensible way to test changes to the old interface any
more.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
It is mostly sorted, but there are anomalies. Eliminating them gives
people fewer excuses to (blindly) add to the end of the list.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
IRQ_PER_CPU and IRQ_GUEST_EOI_PENDING are entirely unused. x86 uses
IRQ_REPLAY, but only ever to clear the bit. Drop all three constants.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Several files in xen/common/sched still reference schedule.c in
their comments, which was the original name of xen/common/sched/core.c
before commit 6cb4b01c03 ("xen/sched: move schedulers and cpupool
coding to dedicated directory") renamed and moved it. Some comments
also reference functions that no longer exist.
Rework the comments to remove stale file and function references.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Furkan Caliskan <frn1furkan10@gmail.com>
Acked-by: Juergen Gross <jgross@suse.com>
Unmapping the virtual VMCB is performed near the end of the domain
destroy procedure but the mapped guest frame prevents domain destroy
from getting to that point. This means guests that call VMRUN cannot
be fully destroyed.
Move the unmap of the virtual VMCB earlier to fix the issue.
Fixes: bcf557675d ("x86: properly use map_domain_page() in nested HVM code")
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
There's no need to open-code these. No functional change intended, even if
the | changes to + in to_bcd().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
... outside of __get_cmos_time()'s locked region. There's no need to hold
the lock for these computations.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
The current logic in ns16550_interrupt() will loop until the device sets
the NOINT in IIR. At least on the Lenovo ThinkSystem SR630 V4 the flow
control of the serial-over-lan emulated UART seems to be broken, as it
doesn't set the NOINT bit consistently. The Transmitter Holding Register
Empty in LSR also seems to not be properly signaled, as even with it set
writes to the transmit register take ~6ms. This leads to the watchdog
triggering very easily on such system.
Introduce an upper bound on the execution time of ns16550_interrupt(), this
is currently set as 4x the polling interval, which is calculated as the
time to fill RX FIFO and/or empty TX FIFO. The current maximum timeout is
either 5ms or the polling interval, whatever is higher. Once the timeout
triggers the interrupt is disabled and the uart is switched to polling
mode.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
It's possible for IRQ_DISABLED to be set while running the handler
execution loop in do_IRQ(). Such disabling can be done by the handler
itself, or from a remote CPU.
Check for IRQ_DISABLED not being set in the loop condition, as to not
execute the handler if the IRQ has been disabled.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
In preparation for irq_to_desc() being called by common IRQ code.
PowerPC doesn't have an irq_desc array defined, so it cannot use the
generic irq_to_desc macro in the common header.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
RISCV declares irq_desc as a static array, opposed to x86 that uses a
pointer allocated at boot time. This creates issues when attempting to add
an extern declaration for irq_desc, as asm/irq.h is included by xen/irq.h where
the definition of struct irq_desc resides, and an empty forward declaration
doesn't make the compiler happy because it doesn't know the type
data-storage.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
When a node's depth exceeds DEVICE_TREE_MAX_DEPTH inside the
device_tree_for_each_node() loop, the code prints a warning and
executes 'continue;' statement, which jumps to condition check,
bypassing the iterator update step:
node = fdt_next_node(fdt, node, &depth).
The node and depth are not updated, the loop repeatedly evaluates
the same too-deep node, causing a hang.
Fix this by wrapping the node processing logic in an 'else' block.
This ensures the loop update step is executed on every iteration,
safely skipping deeply nested nodes and doing the traversal.
Fixes: 40f2ea3df2 ("xen/arm: pass node to device_tree_for_each_node")
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleskii Kurochko <oleksii.kurochko@gmail.com>
gicv3_lpi_init_host_lpis() initializes Xen-side host LPI bookkeeping,
registers the CPU notifier, and allocates the boot CPU pending table.
The pending table allocation uses gicv3_its_get_memflags().
ITS quirks are discovered by gicv3_its_init(), so allocating the boot
CPU pending table from gicv3_dist_init() can happen before the memory
restrictions required by the ITS are known. On affected systems this
can leave the pending table allocated using the default memory policy.
Move host LPI initialization after gicv3_its_init(), and only run it
when a host ITS was found. The old call ignored the return value. Now
that the call is made from gicv3_init(), check it and panic on failure
because Redistributor LPI initialization relies on that state being
available.
Although this reorders host LPI bookkeeping with respect to ITS
initialization, it does not change the hardware-visible LPI setup
sequence. gicv3_lpi_init_host_lpis() does not program the
Redistributor or submit any ITS commands. gicv3_cpu_init() still
programs GICR_PENDBASER/GICR_PROPBASER via
gicv3_lpi_init_rdist(), sets GICR_CTLR.EnableLPIs, and only then calls
gicv3_its_setup_collection(), which submits the first MAPC/SYNC
commands. Therefore, the ordering introduced by 95604873cc remains
unchanged.
This also narrows the condition for host LPI initialization from
"GICD advertises LPIs" to "a host ITS was discovered". This is
intentional: Xen currently has no supported LPI path without a host
ITS, and gicv3_lpi_init_rdist() already rejects that case with
-ENODEV. Therefore, on systems where GICD_TYPE_LPIS is set but no host
ITS is present, skipping gicv3_lpi_init_host_lpis() only avoids
allocating host LPI state that cannot be used by a supported Xen LPI
path.
Fixes: dcb6cb2636 ("ARM: GICv3 ITS: introduce host LPI array")
Fixes: 751ec850ec ("ARM: ITS: implement quirks and add support for Renesas Gen4 ITS")
Signed-off-by: Mykola Kvach <mykola_kvach@epam.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Setting ->orig_video_isVGA to the specific marker should be done only when
the VBE tag is present and the FRAMEBUFFER is either absent or indicates
RGB type. Since the "video" variable now starts out non-NULL, this
property was broken when in particular neither of the tags are present. To
move back to at least close to original behavior, add a 2nd check to said
conditional.
Fixes: d5a73cdc6b ("x86/boot: Use boot_vid_info variable directly from C code")
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
XEN_DOMCTL_SCHEDOP_putvcpuinfo can flip the RTDS_extratime bit on a vCPU
that is currently depleted (cur_budget == 0, possibly sitting on the
depleted queue). rt_dom_cntl() touches only svc->flags; cur_budget is
left unchanged. As a result the next code path that calls runq_insert()
on this vCPU - rt_unit_wake() after a domain_unpause(),
rt_context_saved() following a delayed runq add, or repl_timer_handler()
after a replenishment - places the vCPU on the run queue, because
has_extratime(svc) is now true and runq_insert() admits extratime units
regardless of cur_budget:
/* add svc to runq if svc still has budget or its extratime is set */
if ( svc->cur_budget > 0 ||
has_extratime(svc) )
deadline_runq_insert(svc, &svc->q_elem, runq);
else
list_add(&svc->q_elem, &prv->depletedq);
The very next rt_schedule() iterates the run queue from runq_pick()
and trips the ASSERT(iter_svc->cur_budget > 0) at the bottom of the
loop, panicking the host. Observed trace:
Assertion 'iter_svc->cur_budget > 0' failed at common/sched/rt.c:1035
----[ Xen-4.22-unstable arm64 debug=y ubsan=y Not tainted ]----
[<...>] rt.c#rt_schedule+0x1558/0x33e0 (PC)
[<...>] core.c#do_schedule+0x2e4/0x15b4
[<...>] core.c#schedule+0xb14/0xe50
[<...>] softirq.c#__do_softirq+0x20c/0x3d4
[<...>] do_softirq+0x14/0x1c
[<...>] domain.c#idle_loop+0x194/0x558
Minimal reproducer: pin a single-vCPU domU to a pCPU, program RTDS with
extratime off and a low utilisation (e.g. budget = 10ms / period = 100ms)
so the vCPU spends most of its time in the depleted queue, pause the
domain, issue a putvcpuinfo that sets XEN_DOMCTL_SCHEDRT_extra, then
unpause. As soon as the schedule softirq fires on the pCPU, the BUG
hits. The same sequence is reachable without an explicit pause: any
window in which rt_dom_cntl() runs between burn_budget()'s budget
exhaustion and rt_context_saved()'s runq_insert() also closes onto the
same broken state, because the per-scheduler lock is dropped between
those two points.
The semantics for "extratime gets exhausted budget refilled" already
live in burn_budget():
if ( has_extratime(svc) )
{
svc->priority_level++;
svc->cur_budget = svc->budget;
}
Apply the same priority-demotion-and-refill in rt_dom_cntl() when the
flag transitions from off to on while the vCPU is depleted, clear
RTDS_depleted to match, and - if the vCPU is currently on the depleted
queue - move it to the run queue using the same q_remove() +
runq_insert() pattern already used by repl_timer_handler(). The vCPU
remains on the replenishment queue throughout, so its normal
replenishment cadence is preserved.
The complementary transition (on -> off) is already safe: clearing the
flag only narrows the runq_insert() admission condition, so subsequent
depleted insertions correctly route to the depleted queue.
No other call sites need changes: with cur_budget restored before the
flag is observable to runq_insert(), runq_pick()'s long-standing
invariant (every run-queue entry has cur_budget > 0) is preserved.
Fixes: 463b958317 ("xen:rtds: towards work conserving RTDS")
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Returning from an NMI which hits guest context needs special casing in FRED
mode just like it does in IDT mode.
Break nmi_exit_to_guest() out of handle_ist_exception(), and use it in
entry_FRED_R3() also.
Expand the comment a little, and invert the conditional jump to
compat_restore_all_guest() to avoid needing an #else clause for CONFIG_PV32.
Fixes: 87cfcbe9f0 ("x86/pv: Guest exception handling in FRED mode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Relase-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Loaders respecting IMAGE_SCN_MEM_DISCARDABLE would not load such sections,
yet we need to access it ourselves when switching out of "physical mode".
Leverage behavior new to GNU ld 2.46: Any contribution to .reloc which
doesn't have the discardable flag set (which cannot even be expressed in
ELF) will yield the output section also non-discardable.
Since for intermediate binaries we don't care about section attributes,
link in the new object only on the final linking pass.
Reported-by: Yann Sionneau <yann.sionneau@vates.tech>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Prior to commit 9c20d3c591 ("x86/IDT: Make idt_tables[] be per_cpu(idt)"),
the global idt_tables[] was always safe to use for CPUs in any state.
However, not-yet-onlined CPUs (e.g. MADT with more entries than exist in
practice) or offlined CPUs (e.g. xen-hptool) have their per-cpu pointer
poisoned to detect incorrect uses. machine_kexec() trips over the posion when
clobbering #MC entry paths. Update the comment to discuss parked CPUs, and to
remove discussion which isn't particularly relevant to the actions at hand.
This fixes a fatal #GP (non-canonical memory reference) when trying to enter
the crash kernel.
Fixes: 9c20d3c591 ("x86/IDT: Make idt_tables[] be per_cpu(idt)")
Reported-by: Lin Liu <Lin.Liu01@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
With FRED just as with IDT, it's unsafe to run the exception handlers after
switching stack.
To remove this unsafe window, %cr4 needs clearing earlier. In turn, we may
need to switch to PCID 0 earlier too in order to be able to clear CR4.PCIDE.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
After switching stack, it is not safe to run any exception handlers, because
attempts to access the cpu_info block are out-of-bounds and will generate wild
accesses.
Invalidating the IDT in the common path means there's no need to do so again
in the 32bit path, so drop compat_mode_idt entirely.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
When FRED is active, it is not possible to hook NMIs like this.
NMI hooking in the crash path has undergone several revisions since its
introduction. Notably since commit e7f147bf4a ("x86/crash: Drop manual
hooking of exception_table[]") we use the regular nmi_callback()
infrastructure.
Instead of asserting that we don't enter do_nmi_crash() on the crashing CPU,
tolerate it and return early. It's a marginally longer codepath but behaves
the same and is compatible with FRED.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Leaving the hook pointers in struct xsm_ops when !SYSCTL would lead to
the BUG_ON() in xsm_fixup_ops() triggering for respectively configured
hypervisors.
While moving the #ifdef for the corresponding xsm_*() wrappers, also move
those for xsm_page_offline() (where the hook pointer field already is
suitably guarded).
Fixes: c9eabaa03a ("xen/xsm: wrap around xsm_sysctl with CONFIG_SYSCTL")
Fixes: bddd9af604 ("xen/sysctl: wrap around XEN_SYSCTL_readconsole")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Release-Acked-by: Oleskii Kurochko <oleskii.kurochko@gmail.com>
Add documentation for the Assisted-by tag to clarify how
AI-assisted tooling may be disclosed in Xen patches.
The guidance follows the Linux kernel documentation.
Signed-off-by: Cody Zuschlag <cody.zuschlag@gmail.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
cpumask_to_xenctl_bitmap() may return errors. Clearing the error indicator
of an earlier such call by a (successful) later call is misleading the
caller. For "set", keep setting soft affinity if the hard affinity copy-
back fails; only accumulate respective errors.
While fiddling with return values, also drop a redundant clearing of
"ret". This eliminates a Misra C:2012 rule 2.2 ("There shall be no dead
code") violation.
Fixes: 6e4ecc6d58 ("sched: DOMCTL_*vcpuaffinity works with hard and soft affinity")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Be less strict with permissions checks when removing a mapping and
only request the caller domain to have access to the region. Keep the
same permission checks for addition operations.
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>
This wants xsm_domctl() invoked, but the domctl lock not taken. Move the
handling to the respective switch(), thus eliminating the need for a
separate xsm_domctl() invocation.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Like for XEN_DOMCTL_getdomaininfo there's no need to hold the domctl
lock for XEN_DOMCTL_getvcpuinfo. While moving the code also switch to
using domain_vcpu().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tentatively-acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
About half the callers of vcpu_runstate_get() are solely after the
"running" time of a vCPU. Introduce a specialization with a smaller
read critical section and thus reduced risk of a need for retries.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
fdt_property() unconditionally calls memcpy(ptr, val, len) even when
len is zero and val is NULL. This is a legitimate calling convention
for adding empty FDT properties such as "interrupt-controller", which
carry no payload.
However, compilers that treat memcpy as nonnull on its pointer arguments
will fire UBSAN before observing that len is zero.
Guard the memcpy() with a check on len so it is skipped entirely when
there is no payload to copy, bringing the code in line with the
nonnull contract.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Origin: git://git.kernel.org/pub/scm/utils/dtc/dtc.git f57e7df35df4
Fixes: f0ea065580 ("libfdt: add version 1.3.0")
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Baptiste Le Duc <baptiste.le-duc@vates.tech>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
As Michal had indicated in review, status is now a variable that is set
but never read. I made the resulting change locally, but then committed a
stale version of the patch (also omitting Michal's R-b).
Amends: eff88c4d35 ("gnttab: simplify (really: drop) gnttab_set_frame_gfn()")
Reported-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
The original commit showed a ~6% regression in a benchmark. The call to
align_timer(firsttick, period) rounds firsttick up to the next mutiple
of the period, if firsttick % period != 0:
align_timer(0, period) -> 0
align_timer(1, period) -> period
align_timer(period, period) -> period
align_timer(period + 1, period) -> 2 * period
So adding the period (sampling_rate) before calling align_timer() will
in most cases incease the expiration to 2 * period (sampling_rate) (the
exception being firsttick % period == 0). This longer timer slows the
reaction time of the algorithm.
This reverts commit a0ed5bcfbe, just without
re-introducing the style issues that were there.
Fixes: a0ed5bcfbe ("xen/cpufreq: fix usages of align_timer() in the on-demand governor")
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Jan Beulich