In preparation for adding a devfn field. This makes the naming more
consistent, as the devfn field encloses both the dev and the fn
fields.
No functional change intended.
Requested-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
virt_timer_{save, return} always return 0 and none of the caller
actually check it. So change the return type to void.
Signed-off-by: Baodong Chen <chenbaodong@mxnavi.com>
[julien: Rework the commit message]
Acked-by: Julien Grall <julien.grall@arm.com>
arch.saved_context is already zeroed in alloc_vcpu_struct() by
clear_page(). So there are no need to memset it again in
arch_vcpu_create().
Signed-off-by: Baodong Chen <chenbaodong@mxnavi.com>
[julien: Rework the commit message]
Reviewed-by: Julien Grall <julien.grall@arm.com>
Using clang and lld 8 requires installing the packages from the
official llvm apt repositories, so modify the Debian Docker files for
stretch and unstable to add the llvm repo and install clang and lld
from it.
Also add some jobs to test building Xen with clang 8 and lld.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Doug Goldstein <cardoe@cardoe.com>
At the moment, interrupts are unmasked by gic_interrupt() before
calling do_{IRQ, LPI}(). In the case of handling an interrupt routed
to guests, its priority will be dropped, via desc->handler->end()
called from do_irq(), with interrupt unmasked.
In other words:
- Until the priority is dropped, only higher priority interrupt
can be received. Today, only Xen interrupts have higher priority.
- As soon as priority is dropped, any interrupt can be received.
This means the purpose of the loop in gic_interrupt() is defeated as
all interrupts may get trapped earlier. To reinstate the purpose of
the loop (and prevent the trap), interrupts should be masked when
dropping the priority.
For interrupts routed to Xen, priority will always be dropped with
interrupts masked. So the issue is not present. However, it means
that we are pointless try to mask the interrupts.
To avoid conflicting behavior between interrupt handling,
gic_interrupt() is now keeping interrupts masked and defer the decision
to do_{LPI, IRQ}.
Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
[julien: Reword the commit message]
Acked-by: Julien Grall <julien.grall@arm.com>
The "interrupts-extended" property is a special form for use when
a node needs to reference multiple interrupt parents.
According to:
Linux/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
But, there are cases when "interrupts-extended" property is used for
"outside /soc node" with a single interrupt parent as an equivalent of
pairs ("interrupt-parent" + "interrupts").
A good example here is ARCH timer node for R-Car Gen3/Gen2 family,
which is mandatory device for Xen usage on ARM. And without ability
to handle such nodes, Xen fails to operate.
So, this patch adds required support for Xen to be able to handle
nodes with that property.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Please note, this helper is ported from Linux v4.6.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Acked-by: Julien Grall <julien.grall@arm.com>
None of the parameters of secondary_start are actually used. So turn
secondary_start to a function with no parameters.
Also modify the assembly code to avoid setting-up the registers before
calling start_secondary.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Andrii Anisov <andrii.anisov@epam.com>
Currently, booting staging fails with:
(XEN) Using APIC driver default
(XEN) ----[ Xen-4.13-unstable x86_64 debug=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d08038f66e>] __x86_indirect_thunk_rax+0xe/0x10
(XEN) RFLAGS: 0000000000010016 CONTEXT: hypervisor
(XEN) rax: c2c2c2c2c2c2c2c2 rbx: ffff83003f4cc000 rcx: 0000000000000000
<snip>
(XEN) Xen code around <ffff82d08038f66e> (__x86_indirect_thunk_rax+0xe/0x10):
(XEN) ae e8 eb fb 48 89 04 24 <c3> 90 e8 05 00 00 00 0f ae e8 eb fb 48 89 0c 24
(XEN) Xen stack trace from rsp=ffff82d080827d28:
(XEN) c2c2c2c2c2c2c2c2 ffff82d080207588 ffff82d080827d68 0000000000000000
<snip>
(XEN) Xen call trace:
(XEN) [<ffff82d08038f66e>] __x86_indirect_thunk_rax+0xe/0x10
(XEN) [<ffff82d0806078a9>] setup_system_domains+0x18/0xab
(XEN) [<ffff82d08062d9c8>] __start_xen+0x1ea9/0x2935
(XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) GENERAL PROTECTION FAULT
(XEN) [error_code=0000]
(XEN) ****************************************
UBSAN (which I happened to have active in my build at the time) identifies the
problem explicitly:
(XEN) Using APIC driver default
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in /local/xen.git/xen/include/xsm/xsm.h:309:19
(XEN) member access within null pointer of type 'struct xsm_operations'
(XEN) ----[ Xen-4.13-unstable x86_64 debug=y Not tainted ]----
"adjust system domain creation (and call it earlier on x86)" didn't account
for the fact that domain_create() depends on XSM already being set up.
Therefore, domain_create() follows xsm_ops->alloc_security_domain() which is
offset 0 from a NULL pointer, meaning that we execute the 16bit IVT until
happening to explode in __x86_indirect_thunk_rax().
There is nothing very interesting that xsm_multiboot_init() does more than
allocating memory, which means that it is safe to move earlier during setup.
The resulting boot now looks like:
(XEN) Using APIC driver default
(XEN) XSM Framework v1.0.0 initialized
(XEN) Flask: 128 avtab hash slots, 283 rules.
(XEN) Flask: 128 avtab hash slots, 283 rules.
(XEN) Flask: 4 users, 3 roles, 38 types, 2 bools
(XEN) Flask: 13 classes, 283 rules
(XEN) Flask: Starting in enforcing mode.
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
and
(XEN) Using APIC driver default
(XEN) XSM Framework v1.0.0 initialized
(XEN) Initialising XSM SILO mode
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
UBSAN reports:
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in x86_64/mm.c:1108:31
(XEN) left shift of 255 by 24 places cannot be represented in type 'int'
(XEN) ----[ Xen-4.13-unstable x86_64 debug=y Tainted: H ]----
(XEN) CPU: 60
(XEN) RIP: e008:[<ffff82d0802a54ce>] ubsan.c#ubsan_epilogue+0xa/0xc2
<snip>
(XEN) Xen call trace:
(XEN) [<ffff82d0802a54ce>] ubsan.c#ubsan_epilogue+0xa/0xc2
(XEN) [<ffff82d0802a6009>] __ubsan_handle_shift_out_of_bounds+0x15d/0x16c
(XEN) [<ffff82d08033abd7>] check_descriptor+0x191/0x3dd
(XEN) [<ffff82d0804ef920>] do_update_descriptor+0x7f/0x2b6
(XEN) [<ffff82d0804efb75>] compat_update_descriptor+0x1e/0x20
(XEN) [<ffff82d0804fa1cc>] pv_hypercall+0x87f/0xa6f
(XEN) [<ffff82d080501acb>] do_entry_int82+0x53/0x58
(XEN) [<ffff82d08050702b>] entry_int82+0xbb/0xc0
(XEN)
(XEN) ================================================================================
As this is a constant, express it in longhand for correctness, and consistency
with the surrounding code.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This may result to TLB conflict abort.
Rather than dealing with Break-Before-Make in set_fixmap, each call to
set_fixmap in copy_from_paddr is paired with a call to clear_fixmap.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The two helpers {destroy, modify}_xen_mappings don't check that the
start is always before the end. This should never happen but if it
happens, it will result to unexpected behavior.
Catch such issues earlier on by adding an ASSERT in destroy_xen_mappings
and modify_xen_mappings.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Since commit f60658c6ae "xen/arm: Stop relocating Xen", the function
setup_page_tables() does not require any information from the FDT.
So the initialization of the page-tables can be done much earlier in the
boot process. The earliest setup_page_tables() can be called is after
traps have been initialized, so we can get backtrace if an error
occurred.
Moving the initialization of the page-tables also avoid the dance to map
the FDT again in the new set of page-tables.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
We have multiple static page-tables defined in arch/arm/mm.c. The
current way to define them is difficult to read and does not help when
making modification.
Two new helpers DEFINE_PAGE_TABLES (to define multiple page-tables) and
DEFINE_PAGE_TABLE (alias of DEFINE_PAGE_TABLES(..., 1)) are introduced
and now used to define static page-tables.
Note that DEFINE_PAGE_TABLES() alignment differs from what is currently
used for allocating page-tables. This is fine because page-tables are
only required to be aligned to a page-size.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for CPU0 domheap is unnecessary.
Furthermore, CPU0 page-tables are part of Xen binary and will already be
zeroed before been used. So it is pointless to zero the domheap again.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The boot code is using r2 and r3 to hold the page-table entry value.
While r2 is always updated before storing the value, this is not always
the case for r3.
Thankfully today, r3 will always be zero when we care. But this is
difficult to track and error-prone.
So always zero r3 within the few instructions before the write the
page-table entry.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrii Anisov <andrii.anisov@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The co-processor registers MAIR0 and MAIR1 are managed by EL1. So there
are no need to initialize them during Xen boot.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
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.
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, on platform supporting 42-bit PA, Xen will only expose
40-bit worth of IPA to all domains.
The limitation was to prevent allocating too much memory for the root
page tables as those platforms only support 3-levels page-tables. At the
time, this was deemed acceptable because none of the platforms had
address wired above 40-bits.
However, newer platforms take advantage of the full address space. This
will result to break Dom0 boot as it can't access anything above 40-bit.
The only way to support 42-bit IPA is to allocate 8 pages for the root
page-tables. This is a bit a waste of memory as Xen does not offer
per-guest stage-2 configuration. But it is considered acceptable as
current platforms support 42-bit PA have a lot of memory.
In the future, we may want to consider per-guest stage-2 configuration
to reduce the waste.
Signed-off-by: Feng Kan <fengkan@os.amperecomputing.com>
Signed-off-by: Vishnu <vishnu@os.amperecomputing.com>
[julien: rework commit message]
Acked-by: Julien Grall <julien.grall@arm.com>
According to Linux commit e75bef2a4f ("arm64: Select
ARCH_HAS_FAST_MULTIPLIER") this is a further improvement over the
variant using only bitwise operations on at least some hardware, and no
worse on other.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
pfn_pdx_hole_setup is meant to skip the first MAX_ORDER bits, but
actually it only skips the first MAX_ORDER-1 bits. The issue was
probably introduced by bdb5439c3f ("x86_64: Ensure frame-table
compression leaves MAX_ORDER aligned"), when changing to loop to start
from MAX_ORDER-1 an adjustment by 1 was needed in the call to
find_next_bit() but not done.
Fix the issue by passing j+1 and i+1 to find_next_zero_bit and
find_next_bit. Also add a check for i >= BITS_PER_LONG because
find_{,next_}zero_bit() are free to assume that their last argument is
less than their middle one.
Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
Signed-off-by: Jan Beulich <JBeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
CC: andrew.cooper3@citrix.com
CC: JBeulich@suse.com
CC: George.Dunlap@eu.citrix.com
CC: ian.jackson@eu.citrix.com
CC: konrad.wilk@oracle.com
CC: tim@xen.org
CC: wei.liu2@citrix.com
pfn_to_pdx expects an address, not a size, as a parameter. Specifically,
it expects the end address, then the masks calculations compensate for
any holes between start and end. Thus, we should pass the end address to
pfn_to_pdx.
The initial pdx is stored in frametable_base_pdx, so we can subtract the
result of pfn_to_pdx(start_address) from nr_pdxs; we know that we don't
need to cover any memory in the range 0-start in the frametable.
Remove the variable `nr_pages' because it is unused.
Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
CC: JBeulich@suse.com
Add Hygon Dhyana support to caculate the cpuid policies for creating PV
or HVM guest by using the code path of AMD.
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[Rebase over 0cd074144c "x86/cpu: Renumber X86_VENDOR_* to form a bitmap"]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
The Hygon Dhyana family 18h processor shares the same cpuid leaves as
the AMD family 17h one. So add Hygon Dhyana support to caculate the
cpuid policies as the AMD CPU does.
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
[Rebase over 0cd074144c "x86/cpu: Renumber X86_VENDOR_* to form a bitmap"]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
The Hygon Dhyana processor has the methold to get the last exception
source IP from MSR0000_01DD. So add support for it if the boot param
ler is true.
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
Add Hygon Dhyana support to update cpuid info for creating PV guest.
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
[Rebase over 0cd074144c "x86/cpu: Renumber X86_VENDOR_* to form a bitmap"]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add Hygon Dhyana support to handle HyperTransport range.
Also loading a nul selector does not clear bases and limits on Hygon
CPUs, so add Hygon Dhyana support to the function preload_segment.
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
[Rebase over 0cd074144c "x86/cpu: Renumber X86_VENDOR_* to form a bitmap"]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
The Hygon Dhyana CPU has the same speculative execution as AMD family
17h, so share AMD Retpoline and PTI mitigation code with Hygon Dhyana.
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
[Rebase over 0cd074144c "x86/cpu: Renumber X86_VENDOR_* to form a bitmap"]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
The machine check architecture for Hygon Dhyana CPU is similar to the
AMD family 17h one. Add vendor checking for Hygon Dhyana to share the
code path of AMD family 17h.
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
[Rebase over 0cd074144c "x86/cpu: Renumber X86_VENDOR_* to form a bitmap"]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
As Hygon Dhyana CPU share similar PMU architecture with AMD family
17h one, so add Hygon Dhyana support in vpmu_arch_initialise() and
vpmu_init() by sharing AMD code path.
Split the common part in amd_vpmu_init() to a static function
_vpmu_init(), making AMD and Hygon to call the shared function to
initialize vPMU.
As current vPMU still not support AMD Zen(family 17h), add 0x17 support
to amd_vpmu_init().
Also create a function hygon_vpmu_init() for Hygon vPMU initialization.
Both of AMD 17h and Hygon 18h have the same performance event select
and counter MSRs as AMD 15h has, so reuse the 15h definitions for them.
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon
Dhyana support to print the value of TOP_MEM2.
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
this MSR will stop the Xen initialization process in some Hygon
systems or produce GPF(0). So directly return false in the function
probe_cpuid_faulting() if !cpu_has_hypervisor.
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
[Rebase over 0cd074144c "x86/cpu: Renumber X86_VENDOR_* to form a bitmap"]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add x86 architecture support for a new processor: Hygon Dhyana Family
18h. To make Hygon initialization flow more clear, carve out code from
amd.c into a separate file hygon.c, and remove unnecessary code for
Hygon Dhyana.
To identify Hygon Dhyana CPU, add a new vendor type X86_VENDOR_HYGON
and vendor ID "HygonGenuine" for system recognition, and fit the new
x86 vendor lookup mechanism.
Hygon can fully use the function early_init_amd(), so make this common
function non-static and direct call it from Hygon code.
Add a separate hygon_get_topology(), which calculate phys_proc_id from
AcpiId[6](see reference [1]).
Reference:
[1] https://git.kernel.org/tip/e0ceeae708cebf22c990c3d703a4ca187dc837f5
Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
[Rebase over 0cd074144c "x86/cpu: Renumber X86_VENDOR_* to form a bitmap" and
64933920c9 "x86/cpu: Drop cpu_devs[] and $VENDOR_init_cpu() hooks"]
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
There is now enough complexity that a fuzzing harness is a good idea, and
enough supporting logic to implement one which AFL seems happy with.
Take the existing recalculate_synth() helper and export it as
x86_cpuid_policy_recalc_synth(), as it is needed by the fuzzing harness.
While editing the MAINTAINERS file, insert a related entry which was
accidentally missed from c/s 919ddc3c0 "tools/cpu-policy: Add unit tests", and
sort the lines.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
When merging a levelled policy, stale out-of-range leaves may remain.
Introduce a helper to clear them, and test a number of the subtle corner
cases.
The logic based on cpuid_policy_xstates() is liable to need changing when XCR0
has bit 63 defined. Leave BUILD_BUG_ON()'s behind with comments in all all
impacted areas, which includes in x86_cpuid_policy_fill_native().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
action->ack_type is set once before the timer even gets initialized, and
is never changed later. The timer gets activated only for EOI and UNMASK
types. Hence there's no need to have a respective if() in there. Replace
it by an ASSERT().
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>
There's no point entering the loop in the function in this case. Instead
there still being something in flight _after_ the loop would be an
actual problem: No timer would be running anymore for issuing the EOI
eventually, and hence this IRQ (and possibly lower priority ones) would
be blocked, perhaps indefinitely.
Issue a warning instead and prefer breaking some (presumably
misbehaving) guest over stalling perhaps the entire system.
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>
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>
Roger Pau Monné
Jan Beulich
Oleksandr Tyshchenko
Baodong Chen
Andrew Cooper
Andrii Anisov
Julien Grall
Vishnu Pajjuri OS
Stefano Stabellini
Pu Wen
Volodymyr Babchuk