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>
For an approach like that used in "x86: detect PIT aliasing on ports
other than 0x4[0-3]" [1] to work, channel 2 may not (appear to) continue
counting when "gate" is low. Record the time when "gate" goes low, and
adjust pit_get_{count,out}() accordingly. Additionally for most of the
modes a rising edge of "gate" doesn't mean just "resume counting", but
"initiate counting", i.e. specifically the reloading of the counter with
its init value.
No special handling for state save/load: See the comment near the end of
pit_load().
Along with introducing the get_count() helper to have the calculations
(and the locking check) in a single place, switch pit_get_count()'s d,
counter, and return type to unsigned int.
[1] https://lists.xen.org/archives/html/xen-devel/2023-05/msg00898.html
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
To avoid the need for a forward declaration of pit_load_count() in a
subsequent change, move it earlier in the file (along with its helper
callback).
While moving the code, address a few style issues.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Technically our helper post-dates all of these examples, but it's good cleanup
nevertheless. None of these examples should be using fully locked
test_and_set_bool() in the first place.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
These interfere with code legibility by hiding control flow. Expand and drop
them.
* Rearrange the order of actions to write into rc, then render rc in the
gdprintk().
* Drop redundant "rc = rc" assignments
* Switch to using %pd for rendering domains
As a side effect, this fixes several violations of MISRA rule 2.1 (dead code -
the while() following a goto).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
We already have all the bits necessary in PL011 driver to support SBSA
UART thanks to commit 032ea8c736 that
enabled it for ACPI. Plumb in the remaining part for device-tree boot:
- add arm,sbsa-uart compatible to pl011_dt_match (no need for a separate
struct and DT_DEVICE_START as SBSA is a subset of PL011),
- from pl011_dt_uart_init(), check for SBSA UART compatible to determine
the UART type in use.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Henry Wang <Henry.Wang@arm.com>
At the moment, we use 32-bit only accessors (i.e. readl/writel) to match
the SBSA v2.x requirement. This should not be the default case for normal
PL011 where accesses shall be 8/16-bit (max register size is 16-bit).
There are however implementations of this UART that can only handle 32-bit
MMIO. This is advertised by dt property "reg-io-width" set to 4.
Introduce new struct pl011 member mmio32 and replace pl011_{read/write}
macros with static inline helpers that use 32-bit or 16-bit accessors
(largest-common not to end up using different ones depending on the actual
register size) according to mmio32 value. By default this property is set
to false, unless:
- reg-io-width is specified with value 4,
- SBSA UART is in use.
For now, no changes done for ACPI due to lack of testing possibilities
(i.e. current behavior maintained resulting in 32-bit accesses).
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Tested-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
There are implementations of PL011 that can only handle 32-bit accesses
as oppose to the normal behavior where accesses are 8/16-bit wide. This
is usually advertised by setting a dt property 'reg-io-width' to 4.
Introduce CONFIG_EARLY_UART_PL011_MMIO32 Kconfig option to be able to
enable the use of 32-bit only accessors in PL011 early printk code.
Define macros PL011_{STRH,STRB,LDRH} to distinguish accessors for normal
case from 32-bit MMIO one and use them in arm32/arm64 pl011 early printk
code.
Update documentation accordingly.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Tested-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Although most PL011 UARTs can cope with 32-bit accesses, some of the old
legacy ones might not. PL011 registers are 8/16-bit wide and this shall
be perceived as the normal behavior.
Modify early printk pl011 code for arm32/arm64 to use the correct
accessors depending on the register size (refer ARM DDI 0183G, Table 3.1).
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Tested-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
For Dir 1.1, a document describing all implementation-defined behaviour
(i.e. gcc-specific behavior) will be added to docs/misra, also including
implementation-specific (gcc-specific) appropriate types for bit-field
relevant to Rule 6.1.
Rule 21.21 is lacking an example on gitlab but the rule is
straightforward: we don't use stdlib at all in Xen.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
The asm forming early error handling is a mix of local and non-local symbols,
and has some pointless comments. Drop the "# Error message" comments,
tweaking the style on modified lines, and make the symbols local.
However, leave behind one real symbol so this logic disassembles nicely
without merging in to acpi_boot_init(), which is the thing that happens to be
immediately prior in my build.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The reason for reset_stack() introduction is that stack should be
reset twice:
1. Before jumping to C world at the start of _start() function.
2. After jumping from 1:1 mapping world.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Sometimes variables are located in .sbss section but it won't
be mapped after MMU will be enabled.
To avoid MMU failures .sbss should be mapped
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Update to OVMF's latest stable tag.
This is been prompt by trying to build Xen on Debian Bookworm,
where edk2-stable202108 doesn't build. Also, it's been too long since
the last update.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Fix two issues related to leaf address lookups in VT-d:
* When translating an address that falls inside of a superpage in the
IOMMU page tables the fetching of the PTE value wasn't masking of the
contiguous related data, which caused the returned data to be
corrupt as it would contain bits that the caller would interpret as
part of the address.
* When the requested leaf address wasn't mapped by a superpage the
returned value wouldn't have any of the low 12 bits set, thus missing
the permission bits expected by the caller.
Take the opportunity to also adjust the function comment to note that
when returning the full PTE the bits above PADDR_BITS are removed.
Fixes: c71e55501a ('VT-d: have callers specify the target level for page table walks')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Let's try to avoid giving the impression that 32-bit tool stacks are as
capable as 64-bit ones.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Since QEMU commit 74a1b256d775 ("configure: Bump minimum Clang version
to 10.0"), or QEMU v8.0, Clang 10.0 is now the minimum to build QEMU.
QEMU 8.0 fails to build on Ubuntu Bionic.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Refer ARM DDI 0406C.d ID040418, B3-1345,
"A stage 2 translation with an input address range of 31-34 bits can
start the translation either:
- With a first-level lookup, accessing a first-level translation
table with 2-16 entries.
- With a second-level lookup, accessing a set of concatenated
second-level translation tables"
Thus, for 32 bit IPA, there will be no concatenated root level tables.
So, the root-order is 0.
Also, Refer ARM DDI 0406C.d ID040418, B3-1348
"Determining the required first lookup level for stage 2 translations
For a stage 2 translation, the output address range from the stage 1
translations determines the required input address range for the stage 2
translation. The permitted values of VTCR.SL0 are:
0b00 Stage 2 translation lookup must start at the second level.
0b01 Stage 2 translation lookup must start at the first level.
VTCR.T0SZ must indicate the required input address range. The size of
the input address region is 2^(32-T0SZ) bytes."
Thus VTCR.SL0 = 1 (maximum value) and VTCR.T0SZ = 0 when the size of
input address region is 2^32 bytes.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
When 32 bit physical addresses are used (ie PHYS_ADDR_T_32=y),
"va >> ZEROETH_SHIFT" causes an overflow.
Also, there is no zeroeth level page table on Arm32.
Also took the opportunity to clean up dump_pt_walk(). One could use
DECLARE_OFFSETS() macro instead of declaring an array of page table
offsets.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
As the previous patch introduces CONFIG_PHYS_ADDR_T_32 to support 32 bit
physical addresses, the code specific to "Large Physical Address Extension"
(ie LPAE) should be enclosed within "ifndef CONFIG_PHYS_ADDR_T_32".
Refer xen/arch/arm/include/asm/short-desc.h, "short_desc_l1_supersec_t"
unsigned int extbase1:4; /* Extended base address, PA[35:32] */
unsigned int extbase2:4; /* Extended base address, PA[39:36] */
Thus, extbase1 and extbase2 are not valid when 32 bit physical addresses
are supported.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Some Arm based hardware platforms which does not support LPAE
(eg Cortex-R52), uses 32 bit physical addresses.
Also, users may choose to use 32 bits to represent physical addresses
for optimization.
To support the above use cases, we have introduced arch independent
config to choose if the physical address can be represented using
32 bits (PHYS_ADDR_T_32) or 64 bits (!PHYS_ADDR_T_32).
For now only ARM_32 provides support to enable 32 bit physical
addressing.
When PHYS_ADDR_T_32 is defined, PADDR_BITS is set to 32. Note that we
use "unsigned long" (not "uint32_t") to denote the datatype of physical
address. This is done to avoid using a cast each time PAGE_* macros are
used on paddr_t. For eg PAGE_SIZE is defined as unsigned long. Thus,
each time PAGE_SIZE is used with paddr_t, the result will be
"unsigned long".
On 32-bit architecture, "unsigned long" is 32-bit wide. Thus, it can be
used to denote physical address.
When PHYS_ADDR_T_32 is not defined for ARM_32, PADDR_BITS is set to 40.
For ARM_64, PADDR_BITS is set to 48.
The last two are same as the current configuration used today on Xen.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Restructure the code so that one can use pa_range_info[] table for both
arm32 as well as arm64.
Also, removed the hardcoding for P2M_ROOT_ORDER and P2M_ROOT_LEVEL as
p2m_root_order can be obtained from the pa_range_info[].root_order and
p2m_root_level can be obtained from pa_range_info[].sl0.
Refer ARM DDI 0406C.d ID040418, B3-1345,
"Use of concatenated first-level translation tables
...However, a 40-bit input address range with a translation granularity of 4KB
requires a total of 28 bits of address resolution. Therefore, a stage 2
translation that supports a 40-bit input address range requires two concatenated
first-level translation tables,..."
Thus, root-order is 1 for 40-bit IPA on arm32.
Refer ARM DDI 0406C.d ID040418, B3-1348,
"Determining the required first lookup level for stage 2 translations
For a stage 2 translation, the output address range from the stage 1
translations determines the required input address range for the stage 2
translation. The permitted values of VTCR.SL0 are:
0b00 Stage 2 translation lookup must start at the second level.
0b01 Stage 2 translation lookup must start at the first level.
VTCR.T0SZ must indicate the required input address range. The size of the input
address region is 2^(32-T0SZ) bytes."
Thus VTCR.SL0 = 1 (maximum value) and VTCR.T0SZ = -8 when the size of input
address region is 2^40 bytes.
Thus, pa_range_info[].t0sz = 1 (VTCR.S) | 8 (VTCR.T0SZ) ie 11000b which is 24.
VTCR.T0SZ, is bits [5:0] for arm64.
VTCR.T0SZ is bits [3:0] and S(sign extension), bit[4] for arm32.
For this, we have used struct bitfields to convert pa_range_info[].t0sz to its
arm32 variant.
pa_range_info[] is indexed by ID_AA64MMFR0_EL1.PARange which is present in Arm64
only. This is the reason we do not specify the indices for arm32. Also, we
duplicated the entry "{ 40, 24/*24*/, 1, 1 }" between arm64 and
arm32. This is done to avoid introducing extra #if-defs.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
[julien: Tweak some comments and one check]
Acked-by: Julien Grall <jgrall@amazon.com>
The RSBA bit, "RSB Alternative", means that the RSB may use alternative
predictors when empty. From a practical point of view, this mean "Retpoline
not safe".
Enhanced IBRS (officially IBRS_ALL in Intel's docs, previously IBRS_ATT) is a
statement that IBRS is implemented in hardware (as opposed to the form
retrofitted to existing CPUs in microcode).
The RRSBA bit, "Restricted-RSBA", is a combination of RSBA, and the eIBRS
property that predictions are tagged with the mode in which they were learnt.
Therefore, it means "when eIBRS is active, the RSB may fall back to
alternative predictors but restricted to the current prediction mode". As
such, it's stronger statement than RSBA, but still means "Retpoline not safe".
CPUs are not expected to enumerate both RSBA and RRSBA.
Add feature dependencies for EIBRS and RRSBA. While technically they're not
linked, absolutely nothing good can come of letting the guest see RRSBA
without EIBRS. Nor a guest seeing EIBRS without IBRSB. Furthermore, we use
this dependency to simplify the max derivation logic.
The max policies gets RSBA and RRSBA unconditionally set (with the EIBRS
dependency maybe hiding RRSBA). We can run any VM, even if it has been told
"somewhere you might run, Retpoline isn't safe".
The default policies are more complicated. A guest shouldn't see both bits,
but it needs to see one if the current host suffers from any form of RSBA, and
which bit it needs to see depends on whether eIBRS is visible or not.
Therefore, the calculation must be performed after sanitise_featureset().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Juergen Gross