aboutsummaryrefslogtreecommitdiff
path: root/x86_64
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* Ship missing msr.h fileSamuel Thibault2023-05-201-0/+1
|
* fix fs/gs save/restore and USER32Luca Dariz2023-05-181-3/+1
| | | | | | * x86_64/locore.S: fix PUSH_FSGS -> _ISR and always make room for fsgsbase on a 64-bit kernel. Message-Id: <20230518210839.655403-1-luca@orpolo.org>
* x86_64: Attempt to fix ast_from_interruptSergey Bugaev2023-05-171-1/+2
| | | | Message-Id: <20230517181150.65810-1-bugaevc@gmail.com>
* x86_64: Check for AST when exiting a syscallSergey Bugaev2023-05-121-3/+25
| | | | | | | | | | ...like it's already done when exiting a trap. This is required, since handing a syscall can result in an AST; in particular this happens when the current thread is being terminated, which sets AST_TERMINATE and expects the thread to never return to userspace. Fixes a kernel crash upon calling exit () or pthread_exit () in glibc. Message-Id: <20230511192859.890693-1-bugaevc@gmail.com>
* add setting gs/fsbaseLuca Dariz2023-05-011-18/+71
| | | | | | | | | | | * i386/i386/i386asm.sym: add offsets for asm * i386/i386/pcb.c: switch FSBASE/GSBASE on context switch and implement accessors in thread setstatus/getstatus * i386/i386/thread.h: add new state to thread saved state * kern/thread.c: add i386_FSGS_BASE_STATE handler * x86_64/locore.S: fix fs/gs handling, skipping the base address and avoid resetting it by manually re-loading fs/gs Message-Id: <20230419194703.410575-5-luca@orpolo.org>
* x86_64: add 64-bit syscall entry pointLuca Dariz2023-05-013-6/+199
| | | | | | | | | | | | | | | | | | | | | | | | | While theoretically we could still use the same call gate as for 32-bit userspace, it doesn't seem very common, and gcc seems to not encode properly the instruction. Instead we use syscall/sysret as other kernels (e.g. XNU,Linux). This version still has some limitations, but should be enough to start working on the 64-bit user space. * i386/i386/i386asm.sym: add more constants to fill pcb->iss * i386/i386/ldt.c: configure 64-bit syscall entry point. We can just check for the SEP bit as MSR are always available on x86_64. * i386/i386/ldt.h: swap CS/DS segments order if !USER32 as required by sysret * i386/i386/locore.h: add syscall64 prototype * i386/i386/msr.h: add MSR definitions and C read/write helpers * i386/include/mach/i386/syscall_sw.h: remove old BSD_TRAP * x86_64/Makefrag.am: selectively install syscall_sw.h depending on USER32 * x86_64/include/syscall_sw.h: add entry point template from user space * x86_64/locore.S: implement syscall64 entry point and use it when a 64-bit user-space is configured Message-Id: <20230419194703.410575-4-luca@orpolo.org>
* fix copyoutmsg for 64-bit userspaceLuca Dariz2023-04-201-3/+2
| | | | | * x86_64/copy_user.c: use the correct user/kernel msg structure Message-Id: <20230419194703.410575-2-luca@orpolo.org>
* fix address fault for 32-on-64-bit syscallLuca Dariz2023-04-201-2/+2
| | | | | | * x86_64/locore.S: the faulty address is found in %rbp and not in %rsi, so copy that in CR2 Message-Id: <20230419194703.410575-1-luca@orpolo.org>
* Align mach_msg_type_t and mach_msg_type_long_t with the same alignment as ↵Flavio Cruz2023-03-081-39/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | uintptr_t. With this change, any 64 bit code using the IPC subsystem without relying on MiG will work without any changes. We have a few examples of this inside gnumach but also in the Hurd servers. For example, in hurd/console/display.c typedef struct { mach_msg_header_t Head; mach_msg_type_t ticknoType; natural_t tickno; mach_msg_type_t changeType; file_changed_type_t change; mach_msg_type_t startType; loff_t start; mach_msg_type_t endType; loff_t end; } Request; This will now work correctly in 64 bits, without requiring any explicit padding. As a follow up, we can simplify mach_msg_type_long_t so that we only need an 8 byte structure where the second field will include the number of elements for the long form. This is already included in mach_msg_type_t as unused_msgtl_number. Message-Id: <ZAbhOfOzsb8qPFs6@jupiter.tail36e24.ts.net>
* Support alignment requirements for a 64 bit kernel.Flavio Cruz2023-02-271-14/+22
| | | | | | | | | | | | | We introduce both a user alignment and a kernel alignment. These are separate requirements since for 64 bit with a 32 bit kernel we need to ensure the kernel can consume messages that are 8-byte aligned. This change removes any possibility of undefined behavior and also allows the kernel to support 64 bit RPCs for the userland. A lot of the code that performs alignment was simplified under the assumption that the message headers are well aligned. To enforce that going forward, a few static assertions were added. Message-Id: <Y/KrixiC9Njmu7ef@jupiter.tail36e24.ts.net>
* x86_64: fix user trap during syscall with an invalid user stackLuca Dariz2023-02-271-10/+10
| | | | | | | * i386/i386/locore.h: user vm_offset_t in the recovery_table * x86_64/locore.S: fix RECOVERY() location and keep user regs in %rbx, as it seems the convention. This only applies to 32-bit userspace. Message-Id: <20230227204501.2492152-5-luca@orpolo.org>
* fix port name copyinLuca Dariz2023-02-271-0/+2
| | | | | | | * x86_64/copy_user.c: in mach_msg_user_header_t there are some holes that need to be cleared, to adapt to the different layout of mach_msg_header_t. Message-Id: <20230227204501.2492152-4-luca@orpolo.org>
* fix copyin/outmsg header for ! USER32Luca Dariz2023-02-271-2/+2
| | | | | | * x86_64/copy_user.c: fix copyin/out, we already have a pointer to user/kernel buffers Message-Id: <20230227204501.2492152-3-luca@orpolo.org>
* Make curr_ipl[] per cpuDamien Zammit2023-02-141-13/+21
|
* x86_64: Fix broken int_stack_baseDamien Zammit2023-02-131-1/+1
| | | | Message-Id: <20230213084919.1157074-6-damien@zamaudio.com>
* Make mach_msg_header_t have the same size for both 64 bit kernel and userland.Flavio Cruz2023-02-131-22/+13
| | | | | | | | This has several advantages: 1) We don't need to resize mach_msg_header_t, it is just a copy. 2) Mig won't require any changes because it statically computes the size of mach_msg_header_t, otherwise we would need two sizes (28 vs 32 bytes). Message-Id: <Y+l8UhXXX9Qo9tVA@jupiter.tail36e24.ts.net>
* Consider protected payloads in mach_msg_header_t when resizing messages.Flavio Cruz2023-02-121-0/+22
| | | | | | | | | | Protected payloads will be 8-byte longs which are the same size as kernel ports. Also aligned all the structures to be 4-byte aligned since it makes it easier to parse them as padding won't be added to mach_msg_user_header_t before the protected payload. Message-Id: <Y+krwRFIUeyRszl9@jupiter.tail36e24.ts.net>
* move kernel virtual address space to upper addressesLuca Dariz2023-02-121-6/+6
| | | | | | | | | | | | | | | | | | * i386/i386/vm_param.h: adjust constants to the new kernel map - the boothdr.S code already sets up a temporary map to higher addresses, so we can use INIT_VM_MIN_KERNEL_ADDRESS as in xen - increase the kernel map size to accomodate for bigger structures and more memory - adjust kernel max address and directmap limit * i386/i386at/biosmem.c: enable directmap check also on x86_64 * i386/include/mach/i386/vm_param.h: increase user virtual memory limit as it's not conflicting with the kernel's anymore * i386/intel/pmap.h: adjust lin2pdenum_cont() and INTEL_PTE_PFN to the new kernel map * x86_64/Makefrag.am: change KERNEL_MAP_BASE to be above 4G, and according to mcmodel=kernel. This will allow to use the full memory address space. Message-Id: <20230212172818.1511405-10-luca@orpolo.org>
* extend data types to hold a 64-bit addressLuca Dariz2023-02-121-2/+2
| | | | | | | * i386/i386/trap.c: change from int to a proper type to hold a register value * x86_64/locore.S: use 64-bit register to avoid address truncation Message-Id: <20230212172818.1511405-8-luca@orpolo.org>
* fix x86_64 asm for higher kernel addressesLuca Dariz2023-02-122-6/+4
| | | | | | | * x86_64/interrupt.S: use 64-bit registers as variables could be stored at high addresses * x86_64/locore.S: Likewise Message-Id: <20230212172818.1511405-3-luca@orpolo.org>
* enable syscalls on x86_64Luca Dariz2023-02-121-3/+0
| | | | | Signed-off-by: Luca Dariz <luca@orpolo.org> Message-Id: <20230212170313.1501404-7-luca@orpolo.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-08 20:41:07 +0000