aboutsummaryrefslogtreecommitdiff
path: root/x86_64
Commit message (Collapse)AuthorAgeFilesLines
* Fix x86_64 buildSamuel Thibault2024-10-301-0/+2
|
* x86_64: fix double fault handlerLuca Dariz2024-09-081-1/+1
| | | | | | * x86_64/locore.S: adjust to the changes in the thread state structure (segment registers), and add the missing opcode. Message-ID: <20240904201806.510082-3-luca@orpolo.org>
* Make -fno-PIE etc. architecture-dependentSergey Bugaev2024-03-271-0/+4
| | | | | | | | | | There might be good reasons why Mach on x86 shouldn't be built as PIC/ PIE, but there are also very good reasons to support PIE on other architectures. Potentially implementing KASLR is one such reason; but also the Linux AArch64 boot protocol (that the AArch64 port will use for booting) lets the bootloader load the kernel image at any address, which makes PIC pretty much required. Message-ID: <20240327161841.95685-11-bugaevc@gmail.com>
* move x86 copy_user.[ch] to ipc/ and make it arch-indipendentLD2024-03-092-614/+0
| | | | Message-ID: <20240309140244.347835-3-luca@orpolo.org>
* x86_64: split SET_KERNEL_SEGMENTS() for NCPU > 1Luca Dariz2024-03-091-3/+7
| | | | | | This allows 32on64 to work again. Also, it's a clearer indication of a missing part. Message-ID: <20240309140244.347835-1-luca@orpolo.org>
* x86_64 locore: Check segmentation by handSamuel Thibault2024-03-041-0/+20
| | | | | | | x86_64 ignores the segmentation limit, so we have to check it by hand when accessing userland pointers. Reported-by: Sergey Bugaev <bugaevc@gmail.com>
* locore: Remove unnecessary call to CPU_NUMBERDamien Zammit2024-02-181-2/+1
| | | | The cpu number is already in edx register, so use that.
* USER32: change default to disabled and make it a general optionLuca Dariz2023-12-291-10/+4
| | | | | | | | | | | | * configfrag.ac: add the global option USER32; although it makes sense for 64-bit versions only, it can be used by future 64-bit architectiures and not only x86_64. Also, change the default setting to be disabled; now that we have a working full 64-bit system, it makes sense to consider it the common choice. * x86_64/configfrag.ac: define the correct 32-bit cpu if USER32 is enabled. Message-ID: <20231228194301.745811-2-luca@orpolo.org>
* x86_64: Support 8 byte inlined port rights to avoid message resizing.Flavio Cruz2023-12-171-7/+60
| | | | | | | | | | If a port is inlined in a message, the user has to use mach_port_name_inlined_t to define each port. Out of line memory continues to use mach_port_name_t since that memory has to be copied to the kernel anyway. Both copyinmsg and copyoutmsg can be reduced to nothing (if we ignore USER32) as a follow up but kept this patch simple for ease of review.
* Revert "x86_64: Support 8 byte inlined port rights to avoid message resizing."Samuel Thibault2023-12-031-60/+7
| | | | This reverts commit 29d4bcaafc4c2040df27a6247603c68e7757205c.
* Xen: fix buildSamuel Thibault2023-12-031-2/+2
|
* Fix 32-on-64: Fix missing es pushSamuel Thibault2023-12-031-1/+2
| | | | push %es actually cannot be compiled
* x86_64: Support 8 byte inlined port rights to avoid message resizing.Flavio Cruz2023-12-031-7/+60
| | | | | | | | | | | If a port is inlined in a message, the user has to use mach_port_name_inlined_t to define each port. Out of line memory continues to use mach_port_name_t since that memory has to be copied to the kernel anyway. Both copyinmsg and copyoutmsg can be reduced to nothing (if we ignore USER32) as a follow up but kept this patch simple for ease of review. Message-ID: <ZWg00XzFPqqL1yF-@jupiter.tail36e24.ts.net>
* locore: Homogeneize 32bit and 64bitSamuel Thibault2023-10-281-0/+2
|
* 64bit: Fix locore buildSamuel Thibault2023-10-281-5/+5
| | | | | | | | | To allow references to int_stack_base to be quite unconstrained, we need to use 64bit register indexing. CPU_NUMBER_NO_GS was missing a 64bit variant. CPU_NUMBER_NO_STACK assumes being passed a 32bit register.
* x86_64/locore.S: Fix int stack checks when NCPUS > 1Damien Zammit2023-10-281-5/+8
| | | | Message-ID: <20231028001347.448826-1-damien@zamaudio.com>
* Factorize more push/pop codeSamuel Thibault2023-10-271-35/+34
|
* locore: Also factorize segment management on i386Samuel Thibault2023-10-271-22/+22
| | | | | | and harmonize i386/x86_64. This btw fixes not using dx in 32-on-64's alltraps.
* 32-on-64: Fix missing es pushSamuel Thibault2023-10-271-1/+1
|
* Fix interrupt handlingDamien Zammit2023-10-031-15/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Logic for interrupts: - interrupt.S raises spl (thus IF cleared) - interrupt.S EOI - interrupt.S calls the handler - for pure in-kernel handlers, they do whatever they want with IF cleared. - when a userland handler is registers, queue_intr masks the irq. - interrupt.S lowers spl with splx_cli, thus IF still cleared - iret, that sets IF - later on, userland acks the IRQ, that unmasks the irq The key to this change is that all interrupts, including IPIs, are treated the same way. Eg. the spl level is now raised before an IPI and restored after. Also, EOI is not needed inside irq_acknowledge. With this change and the experimental change not to dispatch threads direct to idle processors in the scheduler, I no longer observe kernel faults, but an occasional hang does occur. Message-Id: <20231002033906.124427-1-damien@zamaudio.com>
* copyinmsg: Check that we have not overflownSamuel Thibault2023-10-011-1/+2
| | | | | This if of course too late in case of a failure, but better assert than get awful bugs, and it's really not supposed to happen.
* copyout_unpack_msg_type: Avoid changing the kernel headerSamuel Thibault2023-10-011-2/+14
|
* Update the 64bit RPC ABI to be simplerFlavio Cruz2023-09-251-16/+72
| | | | | | | | | | | | | | | | | * Make full use of the 8 bytes available in mach_msg_type_t by moving into the unused 4 bytes. This allows us to use 32bits for mach_msg_type_number_t whether we use the longform or not. * Make mach_msg_type_long_t exactly the same as mach_msg_type_t. Updating MiG is strongly encouraged since it will generate better code to handle this new format. After this change, any compatibility with compiled binaries for Hurd x86_64 will break since the message format is different. However, the new schema simplifies the overall ABI, without having "holes" and also avoids the need to have a 16 byte mach_msg_type_long_t. Was able to boot a basic system up to a bash shell. Message-Id: <ZIfqFe5bPNPeH4xg@jupiter.lan>
* percpu: active_stack with gsDamien Zammit2023-09-252-7/+5
| | | | Message-Id: <20230925002417.467022-1-damien@zamaudio.com>
* x86_64: Change active_threads to use gs like i386Damien Zammit2023-09-252-5/+4
| | | | Message-Id: <20230925002353.466997-1-damien@zamaudio.com>
* start/switch_timer: Use CPU_NUMBERSamuel Thibault2023-09-241-2/+2
| | | | They are called from context that has gs initialized.
* percpu area using gs segmentDamien Zammit2023-09-242-3/+6
| | | | | | | | | | | | | | | This speeds up smp again, by storing the struct processor in a percpu area and avoiding an expensive cpu_number every call of current_processor(), as well as getting the cpu_number by an offset into the percpu area. Untested on 64 bit and work remains to use other percpu arrays. TESTED: (NCPUS=8) -smp 1 boots to login shell ~2x slower than uniprocessor TESTED: (NCPUS=8) -smp 2 boots to INIT but hangs there TESTED: (NCPUS=8) -smp 4 gets stuck seemingly within rumpdisk and hangs TESTED: (NCPUS=1) uniprocessor is a bit faster than normal Message-Id: <20230924103428.455966-3-damien@zamaudio.com>
* gdt: Cleanup gdt.h included in asmDamien Zammit2023-09-241-0/+1
| | | | Message-Id: <20230924052824.449219-2-damien@zamaudio.com>
* Fix 64bit xen buildSamuel Thibault2023-08-301-2/+3
|
* apic: Use cpuid to read the apic id for speedDamien Zammit2023-08-221-3/+3
| | | | Message-Id: <20230816014440.2322705-1-damien@zamaudio.com>
* IPI: Do not include support when NCPUS=1Samuel Thibault2023-08-132-0/+6
|
* IPI: Rework irq names and fix x86_64 buildSamuel Thibault2023-08-132-5/+10
|
* i386/x86_64: Add remote AST via IPI mechanismDamien Zammit2023-08-131-0/+3
|
* simple lock: check that the non-_irq variants are not called from IRQSamuel Thibault2023-08-121-3/+11
|
* x86_64: fix NCPUS > 1 build of CX() macroSamuel Thibault2023-08-123-58/+58
| | | | | With the kernel gone to -2GB, the base+index addressing needs to use a 64bit register index.
* Acknowledge IRQ *before* calling the handlerSamuel Thibault2023-08-101-23/+24
| | | | | | | | | | | | 5da1aea7ab3c ("Acknoledge interrupt after handler call") moved the IRQ ack to after calling the handler because of overflows. But that was because the interrupts were getting enabled at some point. Now that all spl levels above 0 just disable interrupts, once we have called spl7 we are safe until splx_cli is called (and even that doesn't release interrupts, only the eventual iret will). And if the handler triggers another IRQ, it will be lost, so we do want to ack the IRQ before handling it.
* x86_64: homogeneize with i386 about _call_singleSamuel Thibault2023-08-102-6/+10
|
* x86_64: fix recursive disabling of interruptsSamuel Thibault2023-08-101-2/+4
| | | | | In case interrupts were already disabled before TIME_TRAP_[US]ENTRY are called, we don't want to execute sti.
* interrupt.S: No nested interrupts during IPIs && more x86_64 smp supportDamien Zammit2023-08-061-0/+10
| | | | Message-Id: <20230805154843.2003098-1-damien@zamaudio.com>
* x86_64: remove unneeded segment selectors handling on full 64 bitLuca Dariz2023-08-041-11/+5
| | | | | | | | | | | | | * i386/i386/db_interface.c: don't set unused segment selectors on full 64-bit * i386/i386/db_trace.c: likewise. * i386/i386/i386asm.sym: likewise. * i386/i386/pcb.c:: likewise. * i386/i386/thread.h: remove ES/DS/FS/GS from thread state on !USER32, as they are unused in this configuration. Only SS and CS are kept. * x86_64/locore.S: convert segment handling macros to no-op on full 64-bit Message-Id: <20230729174753.1145878-5-luca@orpolo.org>
* x86_64: refactor segment register handlingLuca Dariz2023-08-041-143/+85
| | | | | | | | | | | | | | | | | | | | | | | | | The actual values are not saved together with the rest of the thread state, both because it would be quite espensive (reading MSR, unless rdfsbase instructions are supported, but that's optional) and not really needed. The only way the user has to change its value is with a specific RPC, so we can intercept the change easily. Furthermore, Leaving the values there exposes them to being corrupted in case of a double interruption, e.g. an irq is handled just before iretq but after starting to restore the thread state. This solution was suggested by Sergey Bugaev. * i386/i386/db_trace.c: remove fsbase/gsbase from the registers available * i386/i386/debug_i386.c: remove fsbase/gsbase from the printed thread state * i386/i386/i386asm.sym: remove fsbase/gsbase as it's not needed in asm anymore * i386/i386/pcb.c: point fsbase/gsbase to the new location * i386/i386/thread.h: move fsbase/gsbase to the machine state * x86_64/locore.S: generalize segment-handling including es/ds/gs/fs and remove fsbase/gsbase handling. Also, factor out kernel segment selector setting to a macro. Message-Id: <20230729174753.1145878-4-luca@orpolo.org>
* x86_64: format pusha/popa macros for readabilityLuca Dariz2023-08-041-2/+35
| | | | Message-Id: <20230729174753.1145878-3-luca@orpolo.org>
* x86_64: disable V86 mode on full 64-bit configurationLuca Dariz2023-08-041-0/+8
| | | | | | | | * i386/i386/pcb.c: simplify exception stack location and adapt thread gettrs/setters * i386/i386/thread.h: don't include V86 fields on full 64-bit * x86_64/locore.S: don't include checks for V86 mode on full 64-bit Message-Id: <20230729174753.1145878-2-luca@orpolo.org>
* x86_64: fix stack handling on recursive interrupts for USER32Luca Dariz2023-08-041-5/+11
| | | | | | | | * x86_64/locore.S: ensure the thread state is filled completely even on recursive interrups. The value of the segment selectors is not very important in this case, but we still need to align the stack to the bottom of i386_interrupt_state. Message-Id: <20230729174753.1145878-1-luca@orpolo.org>
* x86_64: install emergency handler for double faultLuca Dariz2023-08-042-12/+28
| | | | | | | | | | | | * i386/i386/idt.c: add selector for the interrupt-specific stack * i386/i386/ktss.c: configure ist1 to use a dedicated stack * i386/i386/trap.c: add double fault handler, which just prints the state and panics. There is not much else to do in this case but it's useful for troubleshooting * x86_64/idt_inittab.S: allow to specify an interrupt stack for custom handlers * x86_64/locore.S: add double fault handler Message-Id: <20230729174514.1145656-1-luca@orpolo.org>
* x86_64: add a critical section on entry and exit from syscall/sysretLuca Dariz2023-06-171-1/+3
| | | | | | | | | | | When entering a syscall we're still using the user stack, so we can't reliably handle exceptions or interrupts, otherwise a user thread can easily crash the machine with an invalid stack. Instead, disable interrupts and (hopefullly) avoid traps in the fragments where we need to have the user stack in RSP. * i386/i386/ldt.c: mask interrupts and IOPL on syscall entry * x86_64/locore.S: keep interrupts disabled when we use the user stack
* x86_64: use solid intstack already during bootstrapLuca Dariz2023-06-171-4/+1
| | | | | * x86_64/boothdr.S: there is no reason to not use it right away Message-Id: <20230615214931.189270-1-luca@orpolo.org>
* copyinmsg: allow for the last message element to have msgt_number = 0.Flavio Cruz2023-06-121-2/+1
| | | | | | | | | | | | | When copying messages from user space, some messages may have mach_msg_type_t with msgt_number = 0 and no data after. This is a valid message and we want to allow that. I found this bug when testing "[PATCH gnumach] Update the 64bit RPC ABI to be simpler" and attempting to run a basic Hurd x86_64 that can start a bash shell. When mach_msg_type_long_t is the same size as mach_msg_type_t this bug happens quite frequently and prevents the system from starting properly. Message-Id: <ZIaiHnfrv6Y9hEel@jupiter.lan>
* Xen 64bit: Also put kernel at end of addressing spaceSamuel Thibault2023-05-262-5/+6
|
* x86_64: fix APIC initializationLuca Dariz2023-05-211-3/+14
| | | | | | | * i386/i386at/acpi_parse_apic.c: use vm_offset_t instead of uint32_t for vm addresses * x86_64/Makefrag.am: support --enable-apic Message-Id: <20230521204918.492957-1-luca@orpolo.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-04 11:39:37 +0000