Commit 56a7aaa16b introduced some SVE related code that is protected by
'#if defined(__aarch64__)', the issue is that this doesn't take into
consideration when the toolstack is compiled for an arm32 Dom0 running on
an arm64 platform, it should be able to create SVE enabled guests but with
the current code it's not.
So fix the issue by compiling the code when the toolstack is compiled for
both arm32 and arm64.
Fixes: 56a7aaa16b ("tools: add physinfo arch_capabilities handling for Arm")
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
Note that second sentence is not part of the newer Armv8 spec. But the
interpretation is not much different.
The updated entry will not be used until xen_pt_update() completes.
So rather than adding the ISB after write_pte() in create_xen_table()
and xen_pt-update_entry(), add it in xen_pt_update().
Also document the reasoning of the deferral after each write_pte() calls.
Fixes: 07d11f63d0 ("xen/arm: mm: Avoid flushing the TLBs when mapping are inserted")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
Note that second sentence is not part of the newer Armv8 spec. But the
interpretation is not much different.
As the entry created by arch_pmap_map() will be used soon after
pmap_map() returns, we want to ensure the DSB in write_pte() has
completed. So add an ISB.
Fixes: 4f17357b52 ("xen/arm: add Persistent Map (PMAP) infrastructure")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
The implementation of write_pte() is pretty much the same on arm32
and arm64. So it would be good to consolidate it as this would help
to clarify the requirements when using the helper.
Take the opportunity to switch from assembly to call macros. Note there
is a difference on arm32 because the option was not specified. But this
meant 'sy' (system wide).
Futhermore, the requirements for the ISB is incomplete. Per the Arm Arm,
(Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12), DSB will only
affect explicit accesses. So an ISB is necessary after DSB to ensure
the completion. Having an ISB after each update to the page-tables is
probably too much, so let the caller add the instruction when it is
convenient.
Lastly, the barrier in write_pte() may be too restrictive but I haven't
yet find the proper section(s) in the Arm Arm.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
----
I am a bit split on whether we should add an ISB in write_pte(). It
would make easier for the developper, but would likely force a pipeline
flush too often.
It might also be possible to drop the ISB (and even DSB) when updating
stage-2 PTE (Linux already does it, see 120798d2e7d1). But I am not sure
this is worth it in Xen.
On older version of the Arm Arm (ARM DDI 0487E.a, B2-125) there were
the following paragraph:
"DMB and DSB instructions affect reads and writes to the memory system
generated by Load/Store instructions and data or unified cache
maintenance instructions being executed by the PE. Instruction fetches
or accesses caused by a hardware translation table access are not
explicit accesses."
Newer revision (e.g. ARM DDI 0487J.a) doesn't have the second sentence
(it might be somewhere else in the Arm Arm). But the interpretation is
not much different.
In setup_fixmap(), we write the fixmap area and may be used soon after,
for instance, to write to the UART. IOW, there could be hardware
translation table access. So we need to ensure the 'dsb' has completed
before continuing. Therefore add an 'isb'.
Fixes: 2b11c36461 ("xen/arm64: head: Remove 1:1 mapping as soon as it is not used")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Per the Arm Arm (ARM DDI 0406C.d A3.8.3):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
The function switch_to_runtime_mapping() is responsible to map the
Xen at its runtime address if we were using the temporary area before
jumping returning using a runtime address. So we need to ensure the
'dsb' has completed before continuing. Therefore add an 'isb'.
Fixes: fbd9b5fb4c ("xen/arm32: head: Remove restriction where to load Xen")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Per the Arm Arm (ARM DDI 0406C.d A3.8.3):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
In setup_fixmap(), we write the fixmap area and may be used soon after,
for instance, to write to the UART. IOW, there could be hardware
translation table access. So we need to ensure the 'dsb' has completed
before continuing. Therefore add an 'isb'.
Fixes: e79999e587 ("xen/arm32: head: Remove 1:1 mapping as soon as it is not used")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Tested-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
UBSAN has been enabled a few years ago on x86 but was never
enabled on Arm because the final binary is bigger than 2MB (
the maximum we can currently handled).
With the recent rework, it is now possible to grow Xen over 2MB.
So there is no more roadblock to enable Xen other than increasing
the reserved area.
On my setup, for arm32, the final binaray was very close to 4MB.
Furthermore, one may want to enable UBSAN and GCOV which would put
the binary well-over 4MB (both features require for some space).
Therefore, increase the size to 8MB which should us some margin.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>o
At the moment, the maximum size of Xen binary we can support is 2MB.
This is what we reserved in the virtual address but also what all
the code in Xen relies on as we only allocate one L3 page-table.
When feature like UBSAN (will be enabled in a follow-up patch) and GCOV
are enabled, the binary will be way over 2MB.
The code is now reworked so it doesn't rely on a specific size but
will instead look at the reversed size and compute the number of
page-table to allocate/map.
While at it, replace any reference to 4KB mappings with a more
generic word because the page-size may change in the future.
Also fix the typo s/tlb/tbl/ in code move in arm32/head.S
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
At the moment, we are mapping the size of the reserved area for Xen
(i.e. 2MB) even if the binary is smaller. We don't exactly know what's
after Xen, so it is not a good idea to map more than necessary for a
couple of reasons:
* We would need to use break-before-make if the extra PTE needs to
be updated to point to another region
* The extra area mapped may be mapped again by Xen with different
memory attribute. This would result to attribute mismatch.
Therefore, rework the logic in create_page_tables() to map only what's
necessary.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
At the moment, we are mapping the size of the reserved area for Xen
(i.e. 2MB) even if the binary is smaller. We don't exactly know what's
after Xen, so it is not a good idea to map more than necessary for a
couple of reasons:
* We would need to use break-before-make if the extra PTE needs to
be updated to point to another region
* The extra area mapped may be mapped again by Xen with different
memory attribute. This would result to attribute mismatch.
Therefore, rework the logic in create_page_tables() to map only what's
necessary. To simplify the logic, we also want to make sure _end
is page-aligned. So align the symbol in the linker and add an assert
to catch any change.
Lastly, take the opportunity to confirm that _start is equal to
XEN_VIRT_START as the assembly is using both interchangeably.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Both the stub and the x86 prototypes for replace_grant_host_mapping()
and create_grant_host_mapping() will define the first parameter (and
third for the former) as uint64_t. Yet Arm will define it as
'unsigned long'.
While there are no differences for 64-bit, for 32-bit it means
that the address should be truncated as 32-bit guest could support
up to 40-bit addresses.
So replace 'unsigned long' with 'uint64_t' for the first parameter
(and third parameter for replace_grant_host_mapping()).
Signed-off-by: Julien Grall <jgrall@amazon.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Tested-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Change parameter names in guest_wrmsr_x2apic() and
guest_wrmsr_apic_base() definitions in order to:
1) keep consistency with parameter names used in guest_* function
declarations;
2) fix violations of MISRA C:2012 Rule 8.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Change parameter names of nestedhvm_vcpu_iomap_get() definition to
those used in the function declaration in order to:
1) improve readability;
2) fix violations of MISRA C:2012 Rule 8.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Swap parameter names 'src' and 'dst' of hvm_copy_context_and_params()
declaration for consistency with the corresponding definition and the
uses of such function.
Also, this fixes a violation of MISRA C:2012 Rule 8.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
This option hardens Xen by forcing it to write secure (NX-enhanced) PTEs
regardless of the runtime NX feature bit in boot_cpu_data. This prevents an
attacker with partial write support from affecting Xen's PTE generation
logic by overriding the NX feature flag. The patch asserts support for the
NX bit in PTEs at boot time and if so short-circuits the cpu_has_nx macro
to 1.
It has the nice benefit of replacing many instances of runtime checks with
folded constants. This has several knock-on effects that improve codegen,
saving 2.5KiB off the text section.
The config option defaults to OFF for compatibility with previous
behaviour.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Intel CPUs have a bit in MSR_IA32_MISC_ENABLE that may prevent the NX bit
from being advertised. Clear it unconditionally if we can't find the NX
feature right away on boot.
The conditions for the MSR being read on early boot are (in this order):
* Long Mode is supported
* NX isn't advertised
* The vendor is Intel
The order of checks has been chosen carefully so a virtualized Xen on a
hypervisor that doesn't emulate that MSR (but supports NX) doesn't triple
fault trying to access the non-existing MSR.
With that done, we can remove the XD_DISABLE checks in the intel-specific
init path (as they are already done in early assembly). Keep a printk to
highlight the fact that NX was forcefully enabled.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Currently libxl and the x86-emulator tests carry their own versions. Factor
those out into the common macros header so every library can make use of
it. This is required so the following patch can add this macro to a header
used both in Xen and tools/libs.
No functional change.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
A recent xentrace highlighted an unhandled corner case in the vcpu
"start-of-day" logic, if the trace starts after the last running ->
non-running transition, but before the first non-running -> running
transition. Because start-of-day wasn't handled, vcpu_next_update()
was expecting p->current to be NULL, and tripping out with the
following error message when it wasn't:
vcpu_next_update: FATAL: p->current not NULL! (d32768dv$p, runstate RUNSTATE_INIT)
where 32768 is the DEFAULT_DOMAIN, and $p is the pcpu number.
Instead of calling vcpu_start() piecemeal throughout
sched_runstate_process(), call it at the top of the function if the
vcpu in question is still in RUNSTATE_INIT, so that we can handle all
the cases in one place.
Sketch out at the top of the function all cases which we need to
handle, and what to do in those cases. Some transitions tell us where
v is running; some transitions tell us about what is (or is not)
running on p; some transitions tell us neither.
If a transition tells us where v is now running, update its state;
otherwise leave it in INIT, in order to avoid having to deal with TSC
skew on start-up.
If a transition tells us what is or is not running on p, update
p->current (either to v or NULL). Otherwise leave it alone.
If neither, do nothing.
Reifying those rules:
- If we're continuing to run, set v to RUNNING, and use p->first_tsc
as the runstate time.
- If we're starting to run, set v to RUNNING, and use ri->tsc as the
runstate time.
- If v is being deschedled, leave v in the INIT state to avoid dealing
with TSC skew; but set p->current to NULL so that whatever is
scheduled next won't trigger the assert in vcpu_next_update().
- If a vcpu is waking up (switching from one non-runnable state to
another non-runnable state), leave v in INIT, and p in whatever
state it's in (which may be the default domain, or some other vcpu
which has already run).
While here, fix the comment above vcpu_start; it's called when the
vcpu state is INIT, not when current is the default domain.
Signed-off-by: George Dunlap <george.dunlap@cloud.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Remove the hlist defines/functions and the rcu related functions from
tools/xenstore/list.h, as they are not used.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Move the rest of live update related code from xenstored_control.c to
a dedicated new source file.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Instead of using #ifdef in xenstored_control.c split out the code of
environment specific functions (daemon or Mini-OS) to dedicated source
files.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Instead of including the same small C source in multiple binaries from
2 source directories, use a header file with inline functions as a
replacement.
As some of the functions are exported by libxenstore, rename the inline
functions from xs_*() do xenstore_*() and add xs_*() wrappers to
libxenstore.
With that no sources required to build libxenstore are left in
tools/xenstore, so the file COPYING can be removed now.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
xs_daemon_tdb() in xs_lib.c is no longer used at all, so it can be
removed. xs_domain_dev() and xs_write_all() are not used by xenstored,
so they can be moved to tools/libs/store/xs.c.
xs_daemon_rootdir() is used by xenstored only and it only calls
xs_daemon_rundir(), so replace its use cases with xs_daemon_rundir()
and remove it from xs_lib.c.
xs_daemon_socket_ro() is needed in libxenstore only, so move it to
tools/libs/store/xs.c.
Move functions used by xenstore-client only to xenstore_client.c.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Currently if the processor id is not identified (ie it is missing in proc-v7.S)
, then Xen boot fails quite early.
We have removed this restriction as for some CPUs (eg Cortex-R52), there isn't
any special initialization required.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
When enabling UBSAN on arm32, the following splat will be printed:
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in arch/arm/arm32/vfp.c:75:22
(XEN) left shift of 255 by 24 places cannot be represented in type 'int'
This is referring to the shift in FPSID_IMPLEMENTER_MASK. While we could
only add the U to the value shift there, it would be better to be
consistent and also add it for every value shifted.
This should also addressing MISRA Rule 7.2:
A "u" or "U" suffix shall be applied to all integer constants that
are represented in an unsigned type
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
The instruction ADR is able to load an address of a symbol that is
within the range +/- 1 MB of the instruction.
While today Xen is quite small (~1MB), it could grow up to 2MB in the
current setup. So there is no guarantee that the instruction can
load the string address (stored in rodata).
So replace the instruction ADR with the pseudo-instruction ADR_L
which is able to handle symbol within the range +/- 4GB.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
The instruction CBNZ can only jump to a pc-relative that is in the
range +/- 1MB.
Alternative instructions replacement are living in a separate
subsection of the init section. This is usually placed towards
the end of the linker. Whereas text is towards the beginning.
While today Xen is quite small (~1MB), it could grow up to
2MB in the current setup. So there is no guarantee that the
target address in the text section will be within the range +/-
1MB of the CBNZ in alternative section.
The easiest solution is to have the target address within the
same section of the alternative. This means that we need to
duplicate a couple of instructions.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
----
I couldn't come up with a solution that would not change the number
of instructions executed in the entry path.
Since commit 62529f16c8 ("xen/arm32: head: Use a page mapping for the
1:1 mapping in create_page_tables()"), the register 'r6' is not used
anymore within create_page_tables(). So remove it from the documentation.
Signed-off-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
The linker will happily link Xen if it is bigger than what we can handle
(e.g 2MB). This will result to unexpected failure after boot.
This unexpected failure can be prevented by forbidding linking if Xen is
bigger than the area we reserved.
Signed-off-by: Julien Grall <julien@xen.org>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Tested-by: Henry Wang <Henry.Wang@arm.com>
In the files `xen/arch/arm/include/asm/arm(32|64)/flushtlb.h' there are a
few occurrences of nested '//' character sequences inside C-style comment
blocks, which violate Rule 3.1. The patch aims to resolve those by changing
the inner comments to arm asm comments, delimited by ';' instead.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
It creates confusion since the new format of documenting violations can
be found in: docs/misra/documenting-violations.rst.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
In the current version of replace_grant_host_mapping() function, the
declaration (correctly) uses the parameter names 'gpaddr' and
'new_gpaddr', while the definition uses the parameter names 'addr' and
'new_addr'.
Change the parameter names of the definition to 'gpaddr' and
'new_gpaddr' so that it is clear what type of address is expected and
violations of MISRA C:2012 Rule 8.3 are fixed.
In both declaration and definition of function
replace_grant_host_mapping() change the parameter name 'mfn' to 'frame',
thus improving readability and keeping consistency with name used in
create_grant_host_mapping().
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Change the parameter names of function declarations to be consistent
with the names used in the corresponding function definitions, thus
fixing violations of MISRA C:2012 Rule 8.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
In the current versions of vcpu_vgic_init() and vcpu_vgic_free(),
the declarations (correctly) use the parameter name 'v' while the
corresponding definitions use the parameter name 'vcpu'.
Since it is common to use 'v' to denote a vCPU, change the parameter
name 'vcpu' of function definitions to 'v', thus fixing violations of
MISRA C:2012 Rule 8.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
In the current version of ioremap_addr() function, the declaration
uses the parameter name 'start' (consistenly with the other ioremap_*
function declarations), while the definition uses the parameter name
'pa'.
Change the parameter name 'pa' of function definition to 'start', thus
fixing a violation of MISRA C:2012 Rule 8.3 and keeping the consistency
with other ioremap_* functions.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
In the current version of domain() function, the declaration
(correctly) uses the parameter name 'v' while the definition uses the
parameter name 'vcpu'.
Since it is common to use 'v' to denote a vCPU, change the parameter
name 'vcpu' of function definition to 'v', thus fixing a violation of
MISRA C:2012 Rule 8.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Change the function name 'access_guest_memory_by_ipa' to
'access_guest_memory_by_gpa' and change its formal parameter name from
'ipa' to 'gpa' because of the following:
1) 'gpa' is used more frequently and therefore is preferable;
2) changing parameter name makes the declaration consistent with the
corresponding definition thus fixing a violation of MISRA C:2012 Rule
8.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
This should be static, and there's no need for a separate (non-init, even)
function to perform a simple equality test. Drop the is_ prefix which is
gramatically questionable, and make it __ro_after_init.
Leave a TODO, because the behaviour is definitely wrong to be applied to all
modern Intel CPUs. The question has been raised on xen-devel previously
without conclusion.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In particular, the libxg wrapper for unxz.c uses char for bool_t which is a
major antipattern. Luckily the code doesn't suffer from truncated values.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
During an iteration of the initial ppc64le support patchset the default
defconfig was renamed but build.yaml wasn't updated to reflect this. Fix
it up.
Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add the build system changes required to build for ppc64le (POWER8+).
As of now the resulting image simply boots to an infinite loop.
$ make XEN_TARGET_ARCH=ppc64 -C xen build
This port targets POWER8+ CPUs running in Little Endian mode specifically,
and does not boot on older machines. Additionally, this initial skeleton
only implements the PaPR/pseries boot protocol which allows it to be
booted in a standard QEMU virtual machine:
$ qemu-system-ppc64 -M pseries-5.2 -m 256M -kernel xen/xen
Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
These aren't used, and are not obvious useful either.
tools/ does have some logic which works on $(XEN_OS) directly, and some on
CONFIG_$(XEN_OS) too, but this isn't how we typically refer to things.
The only user ever of this scheme (AFAICT) was introduced in
c0fd920e98 (2006) and deleted in fa2244104b (2010).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Jiamei Xie <jiamei.xie@arm.com>
Luca Fancellu
Julien Grall
Andrew Cooper
Federico Serafini
Alejandro Vallejo
George Dunlap
George Dunlap
Juergen Gross
Ayan Kumar Halder
Julien Grall
Nicola Vetrini
Michal Orzel
Stefano Stabellini
Shawn Anastasio