The timer needs to remain active only until all pending IRQ instances
have seen EOIs from their respective domains. Stop it when the in-flight
count has reached zero in desc_guest_eoi(). Note that this is race free
(with __do_IRQ_guest()), as the IRQ descriptor lock is being held at
that point.
Also pull up stopping of the timer in __do_IRQ_guest() itself: Instead
of stopping it immediately before re-setting, stop it as soon as we've
made it past any early returns from the function (and hence we're sure
it'll get set again).
Finally bail from the actual timer handler in case we find the timer
already active again by the time we've managed to acquire the IRQ
descriptor lock. Without this we may forcibly EOI an IRQ immediately
after it got sent to a guest. For this, timer_is_active() gets split out
of active_timer(), deliberately moving just one of the two ASSERT()s (to
allow the function to be used also on a never initialized timer).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
guest_handle_subrange_okay() takes inclusive first and last parameters,
i.e. checks that [first, last] is valid. Many callers, however, actually
need to see whether [first, limit) is valid (i.e., limit is non-
inclusive), and to do this they subtract 1 from the size. This is
normally correct, except in cases where first == limit, in which case
guest_handle_subrange_okay() will be passed a second parameter less than
its first.
As it happens, due to the way the math is implemented in x86's
guest_handle_subrange_okay(), the return value turns out to be correct;
but we shouldnt rely on this behavior.
Make sure all callers handle first == limit explicitly before calling
guest_handle_subrange_okay().
Note that the other uses (increase-reservation, populate-physmap, and
decrease-reservation) are already fine due to a suitable check in
do_memory_op().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Split out this mostly arch-independent code into a common-code helper
function. (This does away with Arm's arch_init_memory() altogether.)
On x86 this needs to happen before acpi_boot_init(): Commit 9fa94e1058
("x86/ACPI: also parse AMD IOMMU tables early") only appeared to work
fine - it's really broken, and doesn't crash (on non-EFI AMD systems)
only because of there being a mapping of linear address 0 during early
boot. On EFI there is:
Early fatal page fault at e008:ffff82d08024d58e (cr2=0000000000000220, ec=0000)
----[ Xen-4.13-unstable x86_64 debug=y Not tainted ]----
CPU: 0
RIP: e008:[<ffff82d08024d58e>] pci.c#_pci_hide_device+0x17/0x3a
RFLAGS: 0000000000010046 CONTEXT: hypervisor
rax: 0000000000000000 rbx: 0000000000006000 rcx: 0000000000000000
rdx: ffff83104f2ee9b0 rsi: ffff82e0209e5d48 rdi: ffff83104f2ee9a0
rbp: ffff82d08081fce0 rsp: ffff82d08081fcb8 r8: 0000000000000000
r9: 8000000000000000 r10: 0180000000000000 r11: 7fffffffffffffff
r12: ffff83104f2ee9a0 r13: 0000000000000002 r14: ffff83104f2ee4b0
r15: 0000000000000064 cr0: 0000000080050033 cr4: 00000000000000a0
cr3: 000000009f614000 cr2: 0000000000000220
fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000
ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
Xen code around <ffff82d08024d58e> (pci.c#_pci_hide_device+0x17/0x3a):
48 89 47 38 48 8d 57 10 <48> 8b 88 20 02 00 00 48 89 51 08 48 89 4f 10 48
Xen stack trace from rsp=ffff82d08081fcb8:
[...]
Xen call trace:
[<ffff82d08024d58e>] pci.c#_pci_hide_device+0x17/0x3a
[ [< >] pci_ro_device+...]
[<ffff82d080617fe1>] amd_iommu_detect_one_acpi+0x161/0x249
[<ffff82d0806186ac>] iommu_acpi.c#detect_iommu_acpi+0xb5/0xe7
[<ffff82d08061cde0>] acpi_table_parse+0x61/0x90
[<ffff82d080619e7d>] amd_iommu_detect_acpi+0x17/0x19
[<ffff82d08061790b>] acpi_ivrs_init+0x20/0x5b
[<ffff82d08062e838>] acpi_boot_init+0x301/0x30f
[<ffff82d080628b10>] __start_xen+0x1daf/0x28a2
Pagetable walk from 0000000000000220:
L4[0x000] = 000000009f44f063 ffffffffffffffff
L3[0x000] = 000000009f44b063 ffffffffffffffff
L2[0x000] = 0000000000000000 ffffffffffffffff
****************************************
Panic on CPU 0:
FATAL TRAP: vector = 14 (page fault)
[error_code=0000] , IN INTERRUPT CONTEXT
****************************************
Of course the bug would nevertheless have lead to post-boot crashes as
soon as the list would actually get traversed.
Take the opportunity and
- convert BUG_ON()s being moved to panic(),
- add __read_mostly annotations to the dom_* definitions.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Its management shouldn't be arch-specific, and in particular there
should be no need for special precautions when creating the special
domains.
At this occasion
- correct parenthesization of for_each_pdev(),
- stop open-coding for_each_pdev() in vPCI code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
This is a timer handler, so it gets entered with IRQs enabled. Therefore
there's no need to save/restore the IRQ masking flag.
Additionally the final switch()'es ACKTYPE_EOI case re-acquires the lock
just for it to be dropped again right away. Do away with this.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
As build system now supports *_defconfig rules it is good to be able
to configure minimal XEN image with
make tiny64_defconfig
command.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Julien Grall <julien.grall@arm.com>
This #ifdef-ary isn't necessary, and the logic can live in a plain if()
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
* Drop redundant brackes, and inline qualifiers.
* Insert newlines and spaces where appropriate.
* Drop redundant NDEBUG - gdprint() is already conditional. Fix the
logging level, as gdprintk() already prefixes the guest marker.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
vm_event_resume() should use domain_vcpu(), rather than opencoding it
without its Spectre v1 safety.
vm_event_wake_blocked() can't ever be invoked in a case where d->vcpu is
NULL, so drop the outer if() and reindent, fixing up style issues.
The comment, which is left alone, is false. This algorithm still has
starvation issues when there is an asymetric rate of generated events.
However, the existing logic is sufficiently complicated and fragile that
I don't think I've followed it fully, and because we're trying to
obsolete this interface, the safest course of action is to leave it
alone, rather than to end up making things subtly different.
Therefore, no practical change that callers would notice.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
The use of (*ved)-> leads to poor code generation, as the compiler can't
assume the pointer hasn't changed, and results in hard-to-follow code.
For both vm_event_{en,dis}able(), rename the ved parameter to p_ved, and
work primarily with a local ved pointer.
This has a key advantage in vm_event_enable(), in that the partially
constructed vm_event_domain only becomes globally visible once it is
fully constructed. As a consequence, the spinlock doesn't need holding.
Furthermore, rearrange the order of operations to be more sensible.
Check for repeated enables and an bad HVM_PARAM before allocating
memory, and gather the trivial setup into one place, dropping the
redundant zeroing.
No practical change that callers will notice.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
These serve no purpose, but to add to the congnitive load of following
the code. Remove the level of indirection.
Furthermore, the lock protects all data in vm_event_domain, making
ring_lock a poor choice of name.
For vm_event_get_response() and vm_event_grab_slot(), fold the exit
paths to have a single unlock, as the compiler can't make this
optimisation itself.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
This parameter isn't used at all. Futhermore, elide the copyback in
failing cases, as it is only successful paths which generate data which
needs sending back to the caller.
Finally, drop a redundant d == NULL check, as that logic is all common
at the begining of do_domctl().
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
According to Linux commit 0136611c62 ("optimize hweight64 for x86_64")
this is a further improvement over the variant using only bitwise
operations. It's also a slight further code size reduction.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Algorithmically this gets us in line with current Linux, where the same
change did happen about 13 years ago. See in particular Linux commits
f9b4192923 ("bitops: hweight() speedup") and 0136611c62 ("optimize
hweight64 for x86_64").
Kconfig changes for actually setting HAVE_FAST_MULTIPLY will follow.
Take the opportunity and change generic_hweight64()'s return type to
unsigned int.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The "allbutself" cpumask in stop_machine_run() is not needed. Instead
of allocating it on the stack it can easily be avoided.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
'notifier_block' can be replaced with 'list_head' when used for
'notifier_head', this makes a little clearer.
Signed-off-by: Baodong Chen <chenbaodong@mxnavi.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
when 'periodic_period' is zero, there is no need to initialize 'now'.
Signed-off-by: Baodong Chen <chenbaodong@mxnavi.com>
Acked-by: Dario Faggioli <dfaggioli@suse.com>
This is to accompany sanitize_input(). Just like for initial state we
want to have state between two emulated insns sane, at least as far as
assumptions in the main emulator go. Do minimal checking after segment
register, CR, and MSR writes, and roll back to the old value in case of
failure (raising #GP(0) at the same time).
In the particular case observed, a CR0 write clearing CR0.PE was
followed by a VEX-encoded insn, which the decoder accepts based on
guest address size, restricting things just outside of the 64-bit case
(real and virtual modes don't allow VEX-encoded insns). Subsequently
_get_fpu() would then assert that CR0.PE must be set (and EFLAGS.VM
clear) when trying to invoke YMM, ZMM, or OPMASK state.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Don't enforce any other dependencies for now, just like we don't enforce
e.g. PAE enabled as a prereq for long mode.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Drop the ap2m_active boolean, and consistently use the unlocking form:
if ( p2m != hostp2m )
__put_gfn(p2m, gfn);
__put_gfn(hostp2m, gfn);
which makes it clear that we always unlock the altp2m's gfn if it is in use,
and always unlock the hostp2m's gfn. This also drops the ternary expression
in the logdirty case.
Extend the logdirty comment to identify where the locking violation is liable
to occur.
No (intended) overall change in behaviour.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
When you boot Xen with the default 256 NR_CPUS, on a box with rather more
processors, the resulting spew is unnecesserily verbose. Instead, print the
message once, e.g:
(XEN) ACPI: X2APIC (apic_id[0x115] uid[0x115] enabled)
(XEN) WARNING: NR_CPUS limit of 256 reached - ignoring further processors
(XEN) ACPI: X2APIC (apic_id[0x119] uid[0x119] enabled)
(XEN) ACPI: X2APIC (apic_id[0x11d] uid[0x11d] enabled)
(XEN) ACPI: X2APIC (apic_id[0x121] uid[0x121] enabled)
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reflow the ZynqMP message for grepability, and fix the omission of a newline.
There is a race condition where multiple cpus could race to set once_ boolean.
However, the use of this construct is mainly useful for boot time code, and
the only consequence of the race is a repeated print message.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
They are both Airmont-based and should have been included in c/s 17f74242cc
"x86/spec-ctrl: Extend repoline safey calcuations for eIBRS and Atom parts".
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
It appears that even 64-bit versions of Windows 10, when not using syth-
etic timers, will use 32-bit HPET non-periodic timers. There is a test
in hpet_set_timer(), specific to 32-bit timers, that tries to disambiguate
between a comparator value that is in the past and one that is sufficiently
far in the future that it wraps. This is done by assuming that the delta
between the main counter and comparator will be 'small' [1], if the
comparator value is in the past. Unfortunately, more often than not, this
is not the case if the timer is being re-started after a migrate and so
the timer is set to fire far in the future (in excess of a minute in
several observed cases) rather then set to fire immediately. This has a
rather odd symptom where the guest console is alive enough to be able to
deal with mouse pointer re-rendering, but any keyboard activity or mouse
clicks yield no response.
This patch simply adds an extra check of 'creation_finished' into
hpet_set_timer() so that the 'small' time test is omitted when the function
is called to restart timers after migration, and thus any negative delta
causes a timer to fire immediately.
[1] The number of ticks that equate to 0.9765625 milliseconds
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The function passes 0 as "alloc" argument to addr_to_dma_page_maddr(),
so -ENOMEM simply makes no sense (and its use was probably simply a
copy-and-paste effect originating at intel_iommu_map_page()).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR_EL1.
So remove the zeroing and logic to check if the CPU is part of a
uniprocessor system.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
At the moment, the earlyprintk messages are interleaved with the
instructions. This makes more difficult to read the objdump output.
Introduce a new macro to add a string in .rodata.str and use it for all
the earlyprintk messages.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
The various pieces of the hypercall page infrastructure have grown
organically over time and ended up in a bit of a mess.
* Rename all functions to be of the form *_init_hypercall_page(). This
makes them somewhat shorter, and means they can actually be grepped
for in one go.
* Move init_hypercall_page() to domain.c. The 64-bit traps.c isn't a
terribly appropriate place for it to live.
* Drop an obsolete comment from hvm_init_hypercall_page() and drop the
domain parameter from hvm_funcs.init_hypercall_page() as it isn't
necessary.
* Rearrange the logic in the each function to avoid needing extra local
variables, and to write the page in one single pass.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Drop introduced trailing whitespace, excessively long lines, mal-indention,
superfluous use of PRI macros for int-or-smaller types, and incorrect PRI
macros for gfns and mfns.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
The p2m_altp2m_lazy_copy is responsible for lazily populating an
altp2m view when the guest traps out due to no EPT entry being present
in the active view. Currently, in addition to taking a number of
unused argements, the whole calling convention has a number of
redundant p2m lookups: the function reads the hostp2m, even though the
caller has just read the same hostp2m entry; and then the caller
re-reads the altp2m entry that the function has just read (and possibly set).
Rework this function to make it a bit more rational. Specifically:
- Pass the current hostp2m entry values we have just read for it to
use to populate the altp2m entry if it finds the entry empty.
- If the altp2m entry is not empty, pass out the values we've read so
the caller doesn't need to re-walk the tables
- Either way, return with the gfn 'locked', to make clean-up handling
more consistent.
Rename the function to better reflect this functionality.
While we're here, change bool_t to bool, and return true/false rather
than 1/0.
It's a bit grating to do both the p2m_lock() and the get_gfn(),
knowing that they boil down to the same thing at the moment; but we
have to maintain the fiction until such time as we decide to get rid
of it entirely.
Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
vm_event_claim_slot() returns -EOPNOTSUPP for an uninitialized ring
since commit 15e4dd5e86 ("common/vm_event: Initialize vm_event
lists on domain creation"), but the callers test for -ENOSYS.
Correct the callers.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Except in the top level function we don't mean to ever write through
"end". The variable is used solely for pointer comparison purposes
there. Add const everywhere.
Also make function heading wrapping style uniform again for all of the
involved functions.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Along the lines of b9f6395590 ("x86/cpuid: adjust dependencies of
post-SSE ISA extensions") further convert SSEn dependencies to be more
chain like, with each successor addition depending on its immediate
predecessor. This is more in line with how hardware has involved, and
how other projects like gcc and binutils connect things together.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
GCC 4.4 (as included in CentOS 6) is too old to handle designated initialisers
in anonymous unions. As this is just a developer tool, skip the test in this
case, rather than sacraficing the legibility/expresibility of the test cases.
This fixes the Gitlab CI tests.
While adding this logic to cpu-polcy, adjust the equivelent logic from
x86_emulator on which this was based. Printing:
Test harness not built, use newer compiler than "gcc"
isn't helpful for anyone unexpectedly encountering the error.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Instead of ignoring xen.lds and asm-offsets.s for every specific arch,
let's instead just use gitignore's wildcard feature to ignore them for
all archs.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
DSDT for qemu-xen lacks _STA method of PCI slot object. If _STA method
doesn't exist then the slot is assumed to be always present and active
which in conjunction with _EJ0 method makes every device ejectable for
an OS even if it's not the case.
qemu-kvm is able to dynamically add _EJ0 method only to those slots
that either have hotpluggable devices or free for PCI passthrough.
As Xen lacks this capability we cannot use their way.
qemu-xen-traditional DSDT has _STA method which only reports that
the slot is present if there is a PCI devices hotplugged there.
This is done through querying of its PCI hotplug controller.
qemu-xen has similar capability that reports if device is "hotpluggable
or absent" which we can use to achieve the same result.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The only use of asm/vpl011.h is protected by the CONFIG_SBSA_VUART_CONSOLE
define so lets protect the include as well.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Guests can issue grant table operations and provide guest controlled
data to them. This data is used for memory loads in helper functions
and macros. To avoid speculative out-of-bound accesses, we use the
array_index_nospec macro where applicable, or the block_speculation
macro.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Also include the only other AVX512ER insn pair, VEXP2P{D,S}.
Note that despite the replacement of the SHA insns' table slots there's
no need to special case their decoding: Their insn-specific code already
sets op_bytes (as was required due to simd_other), and TwoOp is of no
relevance for legacy encoded SIMD insns.
The raising of #UD when EVEX.L'L is 3 for AVX512ER scalar insns is done
to be on the safe side. The SDM does not clarify behavior there, and
it's even more ambiguous here (without AVX512VL in the picture).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Plus their AVX512BW counterparts.
Take the opportunity and also eliminate a pair of open coded instances
of scalar_1op().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich
Volodymyr Babchuk
Andrew Cooper
Baodong Chen
Roger Pau Monné
Juergen Gross
Petre Pircalabu
Paul Durrant
Julien Grall
Tamas K Lengyel
Wei Liu
Alistair Francis
Igor Druzhinin
Norbert Manthey