Commit graph

1036 commits

Author SHA1 Message Date
Tomasz Bursztyka
27df16ea8e arch/x86: Prepare EFI support
As for Multiboot, let prep_c be aware of EFI boot.
In the futur, EFI will pass an argument to it.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-03-22 09:56:54 -04:00
Tomasz Bursztyka
f19f9db8df arch/x86: Expand cpu boot argument
In order to mitigate at runtime whether it booted on multiboot or EFI,
let's introduce a dedicated x86 cpu argument structure which holds the
type and the actual pointer delivered by the method (multiboot_info, or
efi_system_table)

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-03-22 09:56:54 -04:00
Tomasz Bursztyka
9fb80d04b4 arch/x86: Expose multiboot init function even when disabled
Just a dummy function will do.

When enabled, the code does not need the #ifdef as cmake is handling
this properly already. This was also the wrong CONFIG_ used there
anyway.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-03-22 09:56:54 -04:00
Nazar Kazakov
f483b1bc4c everywhere: fix typos
Fix a lot of typos

Signed-off-by: Nazar Kazakov <nazar.kazakov.work@gmail.com>
2022-03-18 13:24:08 -04:00
Nazar Kazakov
9713f0d47c everywhere: fix typos
Fix a lot of typos

Signed-off-by: Nazar Kazakov <nazar.kazakov.work@gmail.com>
2022-03-14 20:22:24 -04:00
Gerard Marull-Paretas
a87c811ec9 arch: x86: use DEVICE_DT_GET_ONE
Improve code by using DEVICE_DT_GET_ONE instead of device_get_binding,
since the intel_vt_d device instance can be obtained at compile time.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-10 13:45:59 -05:00
Gerard Marull-Paretas
95fb0ded6b kconfig: remove Enable from boolean prompts
According to Kconfig guidelines, boolean prompts must not start with
"Enable...". The following command has been used to automate the changes
in this patch:

sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig*

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-03-09 15:35:54 +01:00
Tomasz Bursztyka
0c9ce49d2a arch/x86: Fix MSI MAP destination
When Zephyr runs directly on actual hardware, it will be always
directing MSI messages to BSP (BootStrap Processor). This was fine until
Zephyr could be ran on virtualizor that may NOT run it on BSP.

So directing MSI messages on current processor. If Zephyr runs on actual
hardware, it will be BSP since such setup is always made at boot time by
the BSP. On other use case it will be whatever is relevant at that time.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-02-22 10:35:39 -05:00
Tomasz Bursztyka
0affb29572 arch/x86: Add a CPUID function to get initial APIC ID
Depending on whether X2APIC is enabled or not, it will be safer to grab
such ID from the right place.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-02-22 10:35:39 -05:00
Tomasz Bursztyka
7ea9b169f7 arch/x86: Have a dedicated place for CPUID related functions
This will centralize CPUID related accessors. There was no need for it
so far, but this is going to change.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-02-22 10:35:39 -05:00
Carles Cufi
e83a13aabf kconfig: Rename the TEST_EXTRA stack size option to align with the rest
All stack sizes should end with STACK_SIZE.

Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2022-02-22 08:23:05 -05:00
Carlo Caione
240c975ad4 core: z_data_copy does not depend on CONFIG_XIP
When XIP is not enabled, z_data_copy() already falls back to an empty
function. No need to ifdef it.

Signed-off-by: Carlo Caione <ccaione@baylibre.com>
2022-02-22 10:22:53 +01:00
Daniel Leung
25f87aac87 x86: remove @return doc for void functions
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2022-01-12 16:02:16 -05:00
Tomasz Bursztyka
4090962386 drivers/interrupt_controller: Add source id to VT-D interrupt remap
Change the API and apply that change where relevant.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
345e122dd2 arch/x86: Add a function to retrieve ID from ACPI's DMAR
This will be necessary to get IOAPIC and HPET source ids for VT-D.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
1012e254cc arch/x86: PCIE MSI address and data may be out of remapping
In fact, in case of VT-D being enabled, it will require to get an
address and data for its own MSI based interrupts which cannot be
remapped (i.e.: will directly go to the relevant APIC).

This is necessary to get the Fault event supported in VT-D.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
1a1bc0d242 drivers/interrupt_controller: Make VT-D remap generic and handle flags
This will not only be used by MSI remapping but by all relevant
interrupts.

Fix also IRTE settings:
- handle x2apic for destination id
- destination mode is always logical (as for IOAPIC)

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
4047b793c8 drivers/interrupt_controller: Generate proper MSI address on VT-D
SHV bit depends on the number of vectors allocated.
If it's facing a multi-vector MSI array, it will set the bit.
If not the bit must be 0.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
6ed593f861 drivers/pcie: Extending parameters to pcie_msi_map
n_vector will be necessary for VT-D actually.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
25b8df0bdb drivers/pcie: Even single MSI based interrupt needs to be remapped
Refactor to handle this case. This is valid only when MSI multi-vector
feature is enabled.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
fa34b135f5 arch/x86: Make sure PCIE allocated IRTEs are tighten to irq/vector
As all interruption need to go through VT-D, calling vt-d remap will
happen on lower level as seen next, so make sure all pcie related
irq/vector get tighten to their respective allocated IRTE.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
84319db9fe arch/x86: All dynamic IRQ connection need to be remapped
Allocate an IRTE for all irq being connected through
arch_irq_connect_dynamic(). This will be mandatory since VT-D expects to
filter all interruptions (but the one it generates, as we will see
later).

Taking into account CONFIG_INTEL_VTD_ICTL_XAPIC_PASSTHROUGH, which could
help for debugging.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
ad8ab01488 arch/x86: On irq remapping, all PCIE MSI/MSI-X need to be remapped
There is no need to differentiate with multi-vector or not, MSI vs
MSI-x: all need to be remapped if Intel VT-D is on.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
f0a7f250a0 arch/x86: Fixing MSI vector allocation
Fixing an out of bound issue.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2022-01-07 10:47:27 -05:00
Tomasz Bursztyka
2623315802 arch/x86: PCIE MSI vector allocator can use arch IRQ allocator
Instead of messing up with the PCI bus.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2021-12-22 12:16:52 +01:00
Tomasz Bursztyka
88bac5d0b5 arch/x86: Implement the IRQ allocation and usage interfaces for intel 64
This is the only architecture user for this at the moment.

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2021-12-22 12:16:52 +01:00
Tomasz Bursztyka
c76651b9ab arch/x86: Do not call irq controller on dedicated irq/vector function
MSI/MSI-x interrupt do not need any interrupt controller handling
(ioapic/loapic).

Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2021-12-22 12:16:52 +01:00
Carles Cufi
4f64ae383d x86: acpi: Fix address-of-packed-mem warning
The warning below appears once -Waddress-of-packed-mem is enabled:

/home/carles/src/zephyr/zephyr/arch/x86/core/acpi.c: In function
'z_acpi_find_table':
/home/carles/src/zephyr/zephyr/arch/x86/core/acpi.c:190:24: warning:
taking address of packed member of 'struct acpi_xsdt' may result in an
unaligned pointer value [-Waddress-of-packed-member]
  190 |    for (uint64_t *tp = &xsdt->table_ptrs[0]; tp < end; tp++) {

To avoid the warning, use an intermediate void * variable.

More info in #16587.

Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2021-12-10 14:08:59 +01:00
Daniel Leung
650a629b08 debug: gdbstub: remove start argument from z_gdb_main_loop()
Storing the state where this is the first GDB break can be done
in the main GDB stub code. There is no need to store the state
in architecture layer.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-11-30 15:24:00 -05:00
Daniel Leung
e1180c8cee x86: gdbstub: add arch-specific funcs to read/write registers
This adds some architecture-specific functions to read/write
registers for the GDB stub. This is in preparation for the actual
introduction of these functions in the core GDB stub code to
avoid breaking the build in between commits.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-11-30 15:24:00 -05:00
Daniel Leung
1cd7cccbb1 kernel: mem_domain: arch_mem_domain functions to return errors
This changes the arch_mem_domain_*() functions to return errors.
This allows the callers a chance to recover if needed.

Note that:
() For assertions where it can bail out early without side
   effects, these are converted to CHECKIF(). (Usually means
   that updating of page tables or translation tables has not
   been started yet.)
() Other assertions are retained to signal fatal errors during
   development.
() The additional CHECKIF() are structured so that it will bail
   early if possible. If errors are encountered inside a loop,
   it will still continue with the loop so it works as before
   this changes with assertions disabled.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-11-22 12:45:22 -05:00
Flavio Ceolin
7dd4297214 pm: Remove unused parameter
The number of ticks on z_pm_save_idle_exit is not used and there is
no need to have it.

Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2021-11-17 11:15:49 -05:00
Andy Ross
1238410914 arch/x86_64: Add hook for CONFIG_SCHED_THREAD_USAGE accounting in ISRs
Call into z_thread_usage_stop() before ISR entry to avoid including
interrupt handling totals in thread usage stats.

This has to go into the assembly immediately before the callback-based
dispatch.  Note that the dispatch code was putting the vector number
in RCX, which was unfortunate as that's a caller-saved register.
Would be nice to clean this up in the future so it lives in a
preserved register but it's mildly complicated to make work with the
way we do the stack layout right now.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2021-11-08 21:32:20 -05:00
Daniel Leung
d33017b458 x86: x86-64: add arch_float_en-/dis-able() functions
This adds arch_float_enable() and arch_float_disable() to x86-64.
As x86-64 always has FP/SSE enabled, these operations are basically
no-ops. These are added just for the completeness of arch interface.

Fixes #38022

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-09-03 10:00:02 -04:00
Torsten Rasmussen
c6aded2dcb linker: align _image_rodata and _image_rom start/end/size linker symbols
Cleanup and preparation commit for linker script generator.

Zephyr linker scripts provides start and end symbols for each larger
areas in the linker script.

The symbols _image_rom_start and _image_rom_end corresponds to the group
ROMABLE_REGION defined in the ld linker scripts.

The symbols _image_rodata_start and _image_rodata_end is not placed as
independent group but covers common-rom.ld, thread-local-storage.ld,
kobject-rom.ld and snippets-rodata.ld.

This commit align those names and prepares for generation of groups in
linker scripts.

The symbols describing the ROMABLE_REGION will be renamed to:
_image_rom_start -> __rom_region_start
_image_rom_end   -> __rom_region_end

The rodata will also use the group symbol notation as:
_image_rodata_start -> __rodata_region_start
_image_rodata_end   -> __rodata_region_end

Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-08-28 08:48:03 -04:00
Daniel Leung
c2a01af003 x86: pin z_x86_set_stack_guard()
This function should be pinned in memory instead of simply
putting it in the boot section, as this function will be
used when new threads are created at runtime.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-08-26 21:16:22 -04:00
Daniel Leung
7605619c1e x86: userspace: page in stack before starting user thread
If generic section is not present at boot, the thread stack
may not be in physical memory. Unconditionally page in the stack
instead of relying on page fault to speed up a little bit
on starting the thread.

Also, this prevents a double fault during thread setup when
setting up stack permission in z_x86_userspace_enter().

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-08-26 21:16:22 -04:00
Daniel Leung
30e5968d34 x86: don't clear BSS if not in physical memory at boot
If the BSS section is not present in physical memory at boot,
do not zero the section, or else page faults would occur.
The zeroing of BSS will be done once the paging mechanism
has been initialized.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-08-26 21:16:22 -04:00
Chen Peng1
fbe13b7bc2 cmake: oneApi: add oneApi support on windows.
add .S file extension suffix into CMAKE_ASM_SOURCE_FILE_EXTENSIONS,
because clang from OneApi can't recongnize them as asm files on
windows, then they won't be added into build system.

Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
2021-07-27 07:20:12 -04:00
Dong Wang
a6800cefb1 x86/cache: fix issues in arch dcache flush function
Correct the wrong operand of clflush instruction. The old operand
points to a location inside stack and doesn't work. The new one
works well by taking linux kernel code as reference.

End address instead of size should get round up

Add Kconfig option to disable the usage of mfence intruction for
SoC that has clfulsh but no mfence supported.

Signed-off-by: Dong Wang <dong.d.wang@intel.com>
2021-07-23 16:22:07 -04:00
Maksim Masalski
466c5d9dea arch: x86: core: remove order eval of 'z_x86_check_stack_bounds' args
The code depends on the order of evaluation 'z_x86_check_stack_bounds'
function arguments.
The solution is to assign these values to variables and then pass
them in.
The fix would be to make 2 local variables, assign them the values
of _df_esf.esp and .cs, and then call the function with those 2 local
variables as arguments.
Found as a coding guideline violation (MISRA R13.2) by static
coding scanning tool.

Change "int reason" to "unsigned reason" like in other functions.

Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
2021-06-23 07:10:18 -04:00
Maksim Masalski
cbfd33f2ec arch: add comments to empty default case, add default LOG_ERR
According to the Zephyr Coding Guideline all switch statements
shall be well-formed.
Add a comment to the empty default case.
Add a LOG_ERR to the default case.

Found as a coding guideline violation (MISRA R16.1) by static
coding scanning tool.

Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
2021-06-22 08:23:43 -04:00
Daniel Leung
454522430f x86: acpi: use memory mapping/unmapping to access ACPI tables
Instead of accessing ACPI tables through physical address, do
memory mapping/unmapping so they can be accessed via virtual
addresses. This allows us to avoid identity mapping all
physical memory, and thus no need for a page table large enough
to map everything.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-06-11 16:12:52 +02:00
Daniel Leung
a3e817700f x86: acpi: limit search on where EBDA can be
This limits the search for Extended BIOS Data Area (EBDA) to
0x80000 to 0x100000 as this is usually the area for it.
If 0000:040e has an address not pointing to this area, it is
probably an invalid address, and should not be de-referenced
to avoid segfault.

Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2021-06-11 16:12:52 +02:00
Jeremy Bettis
2de4a902de cmake: Support coverage flags on all archs
Most arch's CMakeLists.txt contain rules to add compiler and linker
flags for coverage if CONFIG_COVERAGE is enabled, but 4 of them were
missing this.

Instead, set the coverage flags in arch/common/CMakeLists.txt which
affects all archs.

Signed-off-by: Jeremy Bettis <jbettis@chromium.org>
2021-06-10 18:01:36 -04:00
Maksim Masalski
e96df40004 arch: x86: cast to the same size composite expression
Essential type of RHS operand (64 bit) is wider than essential
type of composite expression in LHS operand (32 bit).
LHS entry_val is 32 bit, and RHS (phys+offset) is 64 bit.
Cast RHS composite expression to the (pentry_t) type.

Found as a coding guideline violation (MISRA R10.7) by static
coding scanning tool.

Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
2021-06-10 17:17:23 -04:00
Andy Ross
9cb8dcbf84 arch/x86_64: Use modern CR0 assembly
The 16 bit bootstrap code for SMP CPUs was using the 286-era "lmsw"
instruction (load machine status word) to set the protected bit in CR0
(which is the modern evolution of the same register), presumably
because this is 16 bit code and we can't move a dword into CR0.

But that's wrong, because the full instruction set *is* available in
real mode on a 386, you just have to use a operand size prefix to get
to it, which the assembler emits for you automatically when you use
the .code16 directive.

Write this conventionally and use modern (e.g. 1986-era) instructions.
It also has the advantage of not confusing much more modern
hypervisors like ACRN by issuing instructions they (and I!) never knew
existed.

Fixes #35076

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2021-06-03 20:07:50 -05:00
Andy Ross
5e9c583c24 arch/x86_64: Terrible, awful hackery to bootstrap entry
Because of a historical misunderstanding, by default the ACRN
hypervisor wants to load Zephyr at address 0x1000 and enter the binary
at that same address.  This entry point corresponds to the __start
symbol of the build they were given, which is a 1-cpu non-SMP
configuration.  Unfortunately, when we build with
CONFIG_MP_NUM_CPUS=1, the code in locore.S #if's out the 16 bit entry
point for the auxiliary CPUs at the start of the section.  So in the
build ACRN received, the start address happened to be 0x7000, the same
address we need to launch the AP processors from.

That's right: under ACRN, the SAME ADDRESS used to enter the OS in 32
bit mode needs to be used later to boot CPUs running in 16 bit real
mode!

The solution, such as it is, is to put a 32 bit jump at the entry
address which hops to the 32 bit OS entry code, and then scribble NOP
instructions over that jump once we get there so that the next time we
reach that address (in real mode) we fall through to the correct
entry.

This patch should be considered a temporary workaround.  While it
works on all x86 hardware, it's not really needed.  A much better
solution would be to eliminate the locore linker region entirely
(which causes other headaches) and enter the Zephyr binary in a 32 bit
address somewhere in the contiguous high memory area.  All that locore
is needed for is the 16 bit bootstrap code for SMP processors, which
is ~6 instructions and can be copied in from the kernel at runtime.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2021-06-03 20:07:50 -05:00
Johan Hedberg
8341a136d6 x86: multiboot: Fix NULL pointer dereferences
From the point of checking the info pointer value all code in the
z_multiboot_init() function depends on it being non-NULL. Therefore,
simply return from the function if it's NULL.

Fixes #33084

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2021-05-25 13:37:19 -04:00
Andy Ross
41e885947e arch/x86: Correct multiboot interpretation when building for EFI
When loaded via EFI, we obviously don't have a multiboot info pointer
available (we might have an EFI system table, but zefi doesn't pass
that through yet).  Don't try to parse the "whatever garbage was in
%rbp" as a multiboot table.

The configuration is a little clumsy, as strictly our EFI kconfig just
says we're "building for" EFI but not that we'll boot that way.  And
tests like arch/x86/info are trying to set CONFIG_MULTIBOOT=n
unconditionally, when it really should be something they detect from
devicetree or wherever.

Fixes #33545

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2021-05-15 15:30:02 -04:00