We particularly want/need to avoid accessing data outside (ahead of)
the ring buffer. Also latch both pointers into local variable to
avoid different steps of the calculation being done with different
values.
Reported-by: Quan Luo <a4651386@163.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Remove declarations of functions
intel_mcheck_timer()
mce_intel_feature_init()
mce_cap_init()
x86_mcinfo_getptr()
whose definitions had been removed long time ago.
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
During destroying the m2p mapping, the loop variable was always incremented
by one, as the current version used a compare operator on the left hand side,
which always evaluated to true, i.e.
i += 1UL < (L2_PAGETABLE_SHIFT - 2)
The fix increments the value of the variable by the actual page size by
using the shift operator instead.
Signed-off-by: Norbert Manthey <nmanthey@amazon.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
They're all solely dependent on guest type, so we don't need to repeat
all the same three pointers in every vCPU control structure. Instead use
static const structures, and store pointers to them in the domain
control structure.
Since touching it anyway, take the opportunity and expand
schedule_tail() in the only two places invoking it, allowing the macro
to be dropped.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
When __context_switch() is being bypassed during original context
switch handling, the vCPU "owning" the VMCS partially loses control of
it: It will appear non-running to remote CPUs, and hence their attempt
to pause the owning vCPU will have no effect on it (as it already
looks to be paused). At the same time the "owning" CPU will re-enable
interrupts eventually (the lastest when entering the idle loop) and
hence becomes subject to IPIs from other CPUs requesting access to the
VMCS. As a result, when __context_switch() finally gets run, the CPU
may no longer have the VMCS loaded, and hence any accesses to it would
fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from().
For consistency use the new function also in vmx_do_resume(), to
avoid leaving an open-coded incarnation of it around.
Reported-by: Kevin Mayer <Kevin.Mayer@gdata.de>
Reported-by: Anshul Makkar <anshul.makkar@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Tested-by: Sergey Dyasli <sergey.dyasli@citrix.com>
c/s 3044a2a "common/vcpu: Switch v->vcpu_info_mfn to mfn_t" was intended to be
no functional change.
Unfortunately, because vcpu_info_reset() clobbers v->vcpu_info_mfn, the change
ended up calling put_page_and_type() on MFN_INVALID.
Reintroduce the local variable, and leave a comment behind.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
We don't need a lock in vgic_get_target_vcpu anymore, solving the
following lock inversion bug: the rank lock should be taken first, then
the vgic lock. However, gic_update_one_lr is called with the vgic lock
held, and it calls vgic_get_target_vcpu, which tries to obtain the rank
lock.
Coverity-ID: 1381855
Coverity-ID: 1381853
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Before adding more use of stubs cloned from decoded guest insns, guard
ourselves against mistakes there: Should an exception (with the
noteworthy exception of #PF) occur inside the stub, forward it to the
guest.
Since the exception fixup table entry can't encode the address of the
faulting insn itself, attach it to the return address instead. This at
once provides a convenient place to hand the exception information
back: The return address is being overwritten by it before branching to
the recovery code.
Take the opportunity and (finally!) add symbol resolution to the
respective log messages (the new one is intentionally not being coded
that way, as it covers stub addresses only, which don't have symbols
associated).
Also take the opportunity and make search_one_extable() static again.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
init.data section is clearly writable, so, add "w" flag to its
definition in xen/arch/x86/boot/x86_64.S.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The newly-repurposed arch/x86/hypercall.c is a more appropriate place for the
hypercall continuation logic to live.
This is purely code motion.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Repurpose arch/x86/hypercall.c to be common x86 hypercall infrastructure, and
move the PV specific routines to arch/x86/pv/hypercall.c
This is purely code motion.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
HVM guests currently make use of arch.hvm_vcpu.hcall_64bit to track the ABI of
the hypercall in use.
The rest of Xen deals in terms of the comat ABI or not, so rename the boolean
and make it common, guared by CONFIG_COMPAT to avoid bloat if a compat ABI is
not wanted/needed.
Set hcall_compat uniformly for PV guests as well as HVM guests. This removes
the remaining piece of guest-type-specific knowledge from
hypercall_create_continuation(), allowing it to operate only in terms of the
hypercall ABI in use.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The now-common hcall_preempted boolean is perfectly usable for multicalls.
Remove the multicall-specific preemption mechanism.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
With hcall_preempted having just been made common, ARM can use use it to
simplify its hypercall handling.
This simplifies the continuation logic and removes the risk of accidentally
skipping multiple instructions.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
HVM guests currently make use of arch.hvm_vcpu.hcall_preempted to track
hypercall preemption in struct vcpu. Move this boolean to being common at the
top level of struct vcpu, which will allow it to be reused elsewhere.
Alter the PV preemption logic to use this boolean. This simplifies the code
by removing guest-type-specific knowledge, and removes the risk of accidently
skipping backwards or forwards multiple times and corrupting %rip.
In pv_hypercall() the old_rip bodge can be removed, and parameter clobbering
can happen based on a more obvious condition.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Extend the Maptrack comment to point at the Grant table subsystem.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
generated/autoconf.h is already included automatically so CONFIG_* defines are
available. However, the companion macros such as IS_ENABLED() are not
included.
Include them uniformly everywhere.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
xen/config.h includes asm/config.h, and is included automatically via CFLAGS.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Callers to libxl_cpupool_create() can either request a specific pool
id, or request that Xen do it for them. But at the moment, the
"automatic" selection is indicated by using a magic value, 0. This is
undesirable both because it doesn't obviously have meaning, but also
because '0' is a valid cpupool (albeit one which at the moment can't
be changed).
Introduce a constant, LIBXL_CPUPOOL_POOLID_ANY, to indicate this
instead. Still accept '0' as meaning "ANY" for backwards
compatibility.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: removed two trailing spaces ]
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Callers to xc_cpupool_create() can either request a specific pool id,
or request that Xen do it for them. But at the moment, the
"automatic" selection is indicated by using a magic value, 0. This is
undesirable both because it doesn't obviously have meaning, but also
because '0' is a valid cpupool (albeit one which at the moment can't
be changed).
Introduce a constant, XC_CPUPOOL_POOLID_ANY, to indicate this instead.
Have it be the default for the python bindings.
Manually translate it, even though it's the same underlying value,
because we don't yet have a relaible way of enforcing that these
values are the same.
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Specifying an empty cdrom device will result in a Xenstore entry
params = aio:(null)
as the physical device path isn't existing. This lets a domain booted
via OVMF hang as OVMF is checking for "aio:" only in order to detect
the empty cdrom case.
Use an empty string for the physical device path in this case. As a
cdrom device for HVM is always backed by qdisk we only need to cover this
backend.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Make it easier to figure out whether Xen is booting using ACPI or DT by
printing a message on the console.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
There are multiple path disable ACPI on error. Consolidate in a single
place, this will help in a follow-up patch to add more code on the error
path.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
When the GICv3 is not GICv2 compatible, the associated field in the MADT
will be zeroed. However, the rest of the code expects the variable to
be set to INVALID_PADDR.
This will result to false detection of GICv2 and give I/O access to page
0 for the hardware domain.
Thankfully, it will fail because the size of GICV has not been set.
Fix the detection by converting 0 to INVALID_PADDR for the GICC and
GICV base. At the same time only set the size of each region when the
base address is not 0.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Since commit 4557c22 "xen: arm: rewrite start of day page table and cpu
bring up", Xen requires to be launched in NS HYP/EL2.
xen.axf is generated in order to directly boot Xen on ARM models (e.g
Foundation). However they usually start in secure mode, which mean Xen
cannot boot.
The way forward to boot Xen on models is using either EFI or
bootwrapper [1].
[1] https://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The build option CONFIG_LOAD_ADDRESS is defined but never plumbed
through.
Signed-off-by: Julien Grall <julien.gralL@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
bitops.h cannot include asm_defns.h, because the static inlines in cpumasks.h
result in forward declarations of the bitops.h contents. Move ASM_FLAG_OUT()
to a new asm/compiler.h to compensate.
While making changes, switch bool_t to bool and use named asm parameters.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Commit 71bb7304e7 added flushing of
nested p2m tables whenever the host p2m table changed. Unfortunately
in the process, it added a filter to p2m_flush_table() function so
that the p2m would only be flushed if it was being used as a nested
p2m. This meant that the p2m was not being flushed at all for altp2m
callers.
Only check np2m_base if p2m_class for nested p2m's.
NB that this is not a security issue: The only time this codepath is
called is in cases where either nestedp2m or altp2m is enabled, and
neither of them are in security support.
Reported-by: Matt Leinhos <matt@starlab.io>
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Most of the comments describing the meaning of the
vCPU flags used by the scheduler miss the 'wings' (or
have other minor style issues).
Also, use 1U (instead of 1) as the base of shiftings.
No functional change intended.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Since we are doing cpumask manipulation already, clear a bit
in the mask at once. Doing that will save us an if, later in
the code.
No functional change intended.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Information we currently print for idle vCPUs is
rather useless. Credit2 already stopped showing that,
do the same for Credit and RTDS.
Also, define a new CPU status dump hook, which is
not defined by those schedulers which already dump
such info in other ways (e.g., Credit2, which does
that while dumping runqueue information).
This also means that, still in Credit2, we can keep
the runqueue and pCPU info closer together.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Meng Xu <mengxu@cis.upenn.edu>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Multi-touch fields re-use the page that is used by the other features
which means that you can interleave multi-touch, motion, and key
events.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
That way we have one person who can: a) poke other maintainers
or pull them in with new drivers are introduced, b) we have
one maintainer who can shepherd the patches along instead of
depending on the REST maintainers which may be busy with
other responsibilities.
Acked-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
There is a possible scenario when (d)->need_iommu remains unset
during guest domain execution. For example, when no devices
were assigned to it. Taking into account that teardown callback
is not called when (d)->need_iommu is unset we might have unreleased
resourses after destroying domain.
So, always call teardown callback to roll back actions
that were performed in init callback.
This is XSA-207.
Signed-off-by: Oleksandr Tyshchenko <olekstysh@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Julien Grall <julien.grall@arm.com>
hvm_physdev_op() and hvm_physdev_op_compat32() are almost identical, but there
is no need to have two functions instantiated at the end of different function
pointers.
Combine the two into a single hvm_physdev_op() and dispatch to
{do,compat}_physdev_op() based on the hcall_64bit setting.
This also fixes an inconsistency where 64bit PVH hardware domains were
permitted access to extra physdev ops, but 32bit domains weren't.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
hvm_grant_table_op() and hvm_grant_table_op_compat32() are almost identical,
but there is no need to have two functions instantiated at the end of
different function pointers.
Combine the two into a single hvm_grant_table_op() (folding
grant_table_op_is_allowed() into is now-single caller) and dispatch to
{do,compat}_grant_table_op() based on the hcall_64bit setting.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
hvm_memory_op() and hvm_memory_op_compat32() are almost identical, but there
is no need to have two functions instantiated at the end of different function
pointers.
Combine the two into single hvm_memory_op() which dispatches to
{do,compat}_memory_op() based on the hcall_64bit setting.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich
Haozhong Zhang
Norbert Manthey
Andrew Cooper
Wei Liu
Stefano Stabellini
Daniel Kiper
George Dunlap
Juergen Gross
Julien Grall
Olaf Hering
Dario Faggioli
Oleksandr Andrushchenko
Konrad Rzeszutek Wilk
Oleksandr Tyshchenko
Roger Pau Monne