summaryrefslogtreecommitdiff
path: root/i386/i386
AgeCommit message (Collapse)Author
2024-09-08fpu_set_state: accept fp_save_kind being incoherent if initialized is not setHEADmasterSamuel Thibault
2024-09-08fpu_set_state: return an error on incoherent fp_save_kindSamuel Thibault
2024-09-08add xfloat thread state interfaceLuca Dariz
* i386/i386/fpu.c: extend current getter and setter to support the extended state; move the struct casting here to reuse the locking and allocation logic for the thread state; make sure the new state is set as valid, otherwise it won't be applied; add i386_get_xstate_size() to dynamically retrieve the FPU state size. * i386/i386/fpu.h: update prototypes to accept generic thread state * i386/i386/pcb.c: forward raw thread state to getter and setter, only checking for minimum size and use the new i386_get_xstate_size() helper. * i386/include/mach/i386/mach_i386.defs: expose the new helper i386_get_xstate_size(). * i386/include/mach/i386/thread_status.h: add interface definition for I386_XFLOAT_STATE and the corresponding data structure. Message-ID: <20240904201806.510082-1-luca@orpolo.org>
2024-03-11x86_64: avoid iterating over the message twice in copyoutmsg/copyinmsg for ↵Flavio Cruz
faster RPCs. This is a follow up to https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=69620634858b2992e1a362e33c95d9a8ee57bce7 where we made inlined ports 8 bytes long to avoid resizing. The last thing that copy{in,out}msg were doing was just updating msgt_size field since that's required for kernel stub code and implicitly assumed by IPC code. This was moved into ipc_kmsg_copy{in,out}_body. For a 32 bit userland, the code also stops updating msgt_size for out of line ports, same as the 64 bit userland. Message-ID: <ZdQxWNSieTHcpM1b@jupiter.tail36e24.ts.net>
2024-03-09move x86 copy_user.[ch] to ipc/ and make it arch-indipendentLD
Message-ID: <20240309140244.347835-3-luca@orpolo.org>
2024-03-09remove machine/machspl.h as it duplicates machine/spl.hLD
Message-ID: <20240309140244.347835-2-luca@orpolo.org>
2024-03-03kernel traps: also catch general protection faultsSamuel Thibault
If userland passes a kernel pointer, it's not a page fault that we get, but a general protection fault. We also want to go through the recovery in that case, to make e.g. copyin/out return an error.
2024-02-23spl: Introduce assert_splvm and use it in process_pmap_updatesSamuel Thibault
Suggested-by: Damien Zammit <damien@zamaudio.com>
2024-02-19Introduce and use assert_splsched()Samuel Thibault
2024-02-18locore: Remove unnecessary call to CPU_NUMBERDamien Zammit
The cpu number is already in edx register, so use that.
2024-02-12Replace kernel header includes in include/mach/mach_types.h with forward ↵Flavio Cruz
declarations. I was trying to reuse TASK_NAME_SIZE in kern/thread.h but it was impossible because files included from kern/task.h end up requiring kern/thread.h (through percpu.h), creating a recursive dependency. With this change, mach_types.h only defines forward declarations and modules have to explicitly include the appropriate header file if they want to be able touch those structures. Most of the other includes are required because we no longer grab many different includes through mach_types.h. Message-ID: <20240212062634.1082207-1-flaviocruz@gmail.com>
2024-02-10Fix build with APIC without SMPSamuel Thibault
2024-02-09smp: Fix compile error with missing apboot_addrDamien Zammit
Message-ID: <20240209021108.1715770-1-damien@zamaudio.com>
2024-02-09smp: Fix INIT/STARTUP IPI sequenceDamien Zammit
TESTED: works in qemu TESTED: works hardware with AMD cpu Message-ID: <20240207050158.1640853-5-damien@zamaudio.com>
2024-02-08fpu: Fix cpuid feature detectionOlivier Valentin
Make sure to fetch capabilities from cpuid(0xd,0x1) Message-ID: <20240208165015.4700-3-valentio@free.fr>
2024-02-08Revert "fpu: Fix cpuid feature detection"Olivier Valentin
This reverts commit f8d0f98e80b3d7d9b24fa077818113fb0f4b3970. Message-ID: <20240208165015.4700-2-valentio@free.fr>
2024-02-08smp: Use HPET instead of pit one-shot that is unreliableDamien Zammit
NB: Every x86 board that uses ACPI most likely has a HPET since 2005. We can roll back to PIT in the cases where its not present, but the PIT one shot code is definitely currently broken. Message-ID: <20240207050158.1640853-4-damien@zamaudio.com>
2024-02-08Add HPET timer for small accurate delaysDamien Zammit
TESTED: This works in qemu correctly TESTED: This works on an AMD board with ACPI v2.0 correctly Message-ID: <20240207050158.1640853-3-damien@zamaudio.com>
2024-02-08separate lapic_enable from lapic_setupDamien Zammit
This initializes the lapic without turning on the IOAPIC interrupts during SMP init. Message-ID: <20240207050158.1640853-2-damien@zamaudio.com>
2024-02-05apboot: avoid self-modifying codeSamuel Thibault
self-modifying code is generally frowned upon, Intel largely says the support is model-dependent. We can as well just relocate from the C code like we did for the temporary gdt.
2024-02-05smp: Remove hardcoded AP_BOOT_ADDRDamien Zammit
This took some time to figure out. Involves a hand-crafted 16 bit assembly instruction [1] because it requires an immediate for the memory address of far jump. This required self-modifying code to inject the next instruction, therefore I added a near jump to clear the instruction cache queue in case the pipeline cached the unmodified jump location. [1] Intel Architecture Software Developer's Manual, Volume 2: Instruction Set Reference Manual
2024-02-05Fix apic_send_ipi function clobbering read only fieldsDamien Zammit
This was the root cause of failing to INIT. We were clobbering remote_read_status. And also, we need to reference the .r register when writing the ICR regs otherwise I think it writes all of the block. Message-ID: <20240205113327.1568218-2-damien@zamaudio.com>
2024-01-30apic: Set up LAPICs in xAPIC modeDamien Zammit
Clear flag in msr for xAPIC mode. Message-ID: <20240130080405.1304381-1-damien@zamaudio.com>
2024-01-29Support up to two IOAPICs with up to 32 GSIs on eachDamien Zammit
Previously, only IOAPIC[0] was supported. Now this supports up to two IOAPICs. Message-ID: <20240129100652.1262126-1-damien@zamaudio.com>
2024-01-27fpu: Fix cpuid feature detectionOlivier Valentin
Make sure to fetch capabilities from cpuid(0xd,0x1) and max structure sizes from cpuid(0xd,0x0). Message-ID: <20240124080019.8136-1-valentio@free.fr>
2023-12-17x86_64: Support 8 byte inlined port rights to avoid message resizing.Flavio Cruz
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.
2023-12-03Revert "x86_64: Support 8 byte inlined port rights to avoid message resizing."Samuel Thibault
This reverts commit 29d4bcaafc4c2040df27a6247603c68e7757205c.
2023-12-03Xen: fix buildSamuel Thibault
2023-12-03x86_64: Support 8 byte inlined port rights to avoid message resizing.Flavio Cruz
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>
2023-10-28locore: Homogeneize 32bit and 64bitSamuel Thibault
2023-10-2864bit: Fix locore buildSamuel Thibault
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.
2023-10-2864bit: Fix types in lock.hSamuel Thibault
simple locks use natural_t, and indexes for bt/bts/btr have to be 32bit.
2023-10-27Factorize more push/pop codeSamuel Thibault
2023-10-27locore: Also factorize segment management on i386Samuel Thibault
and harmonize i386/x86_64. This btw fixes not using dx in 32-on-64's alltraps.
2023-10-01copyinmsg: Check that we have not overflownSamuel Thibault
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.
2023-09-28x86_64: remove more unneeded segment selectors handling on full 64bitSamuel Thibault
This follows aaa33bd1ef300380279d9e2875b61a7abaf2c88d
2023-09-27percpu: simplify access in NCPUS==1 caseSamuel Thibault
2023-09-25percpu: active_stack with gsDamien Zammit
Message-Id: <20230925002417.467022-1-damien@zamaudio.com>
2023-09-24SMP: Fix setting up initial gdtSamuel Thibault
We cannot access cpu_id_lut from the initial AP state, so update the percpu segment after loading gdt.
2023-09-24cpuboot: Also set up %gs for APSamuel Thibault
So they can use it very early.
2023-09-24boothdr: Do not bother computing precise limitSamuel Thibault
Computing it would be complex, and this is a temporary descriptor anyway.
2023-09-24Use fewer cpu_number_slow callsSamuel Thibault
Now that gs is initialized early.
2023-09-24percpu active_thread using gs segmentDamien Zammit
TESTED: As per previous commit Message-Id: <20230924052824.449219-4-damien@zamaudio.com>
2023-09-24spl: Use gs to access CPU numberSamuel Thibault
Now that it can be used early.
2023-09-24boothdr: Also set up %gs for percpu accessSamuel Thibault
So we can use it very early.
2023-09-24start/switch_timer: Use CPU_NUMBERSamuel Thibault
They are called from context that has gs initialized.
2023-09-24percpu area using gs segmentDamien Zammit
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>
2023-09-24cpu_number: Inline widely used simple functionDamien Zammit
TESTED: on uniprocessor and smp, both behaved as normal. Message-Id: <20230924103428.455966-2-damien@zamaudio.com>
2023-09-24gdt: Cleanup gdt.h included in asmDamien Zammit
Message-Id: <20230924052824.449219-2-damien@zamaudio.com>
2023-09-23cpuboot: Use CPU_NUMBER_NO_STACK before stack is set upDamien Zammit
Message-Id: <20230923105449.425849-1-damien@zamaudio.com>