Age | Commit message (Collapse) | Author |
|
|
|
|
|
* 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>
|
|
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>
|
|
Message-ID: <20240309140244.347835-3-luca@orpolo.org>
|
|
Message-ID: <20240309140244.347835-2-luca@orpolo.org>
|
|
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.
|
|
Suggested-by: Damien Zammit <damien@zamaudio.com>
|
|
|
|
The cpu number is already in edx register, so use that.
|
|
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>
|
|
|
|
Message-ID: <20240209021108.1715770-1-damien@zamaudio.com>
|
|
TESTED: works in qemu
TESTED: works hardware with AMD cpu
Message-ID: <20240207050158.1640853-5-damien@zamaudio.com>
|
|
Make sure to fetch capabilities from cpuid(0xd,0x1)
Message-ID: <20240208165015.4700-3-valentio@free.fr>
|
|
This reverts commit f8d0f98e80b3d7d9b24fa077818113fb0f4b3970.
Message-ID: <20240208165015.4700-2-valentio@free.fr>
|
|
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>
|
|
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>
|
|
This initializes the lapic without
turning on the IOAPIC interrupts during SMP init.
Message-ID: <20240207050158.1640853-2-damien@zamaudio.com>
|
|
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.
|
|
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
|
|
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>
|
|
Clear flag in msr for xAPIC mode.
Message-ID: <20240130080405.1304381-1-damien@zamaudio.com>
|
|
Previously, only IOAPIC[0] was supported.
Now this supports up to two IOAPICs.
Message-ID: <20240129100652.1262126-1-damien@zamaudio.com>
|
|
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>
|
|
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.
|
|
This reverts commit 29d4bcaafc4c2040df27a6247603c68e7757205c.
|
|
|
|
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>
|
|
|
|
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.
|
|
simple locks use natural_t, and indexes for bt/bts/btr have to be 32bit.
|
|
|
|
and harmonize i386/x86_64.
This btw fixes not using dx in 32-on-64's alltraps.
|
|
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.
|
|
This follows aaa33bd1ef300380279d9e2875b61a7abaf2c88d
|
|
|
|
Message-Id: <20230925002417.467022-1-damien@zamaudio.com>
|
|
We cannot access cpu_id_lut from the initial AP state, so update the
percpu segment after loading gdt.
|
|
So they can use it very early.
|
|
Computing it would be complex, and this is a temporary descriptor
anyway.
|
|
Now that gs is initialized early.
|
|
TESTED: As per previous commit
Message-Id: <20230924052824.449219-4-damien@zamaudio.com>
|
|
Now that it can be used early.
|
|
So we can use it very early.
|
|
They are called from context that has gs initialized.
|
|
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>
|
|
TESTED: on uniprocessor and smp, both behaved as normal.
Message-Id: <20230924103428.455966-2-damien@zamaudio.com>
|
|
Message-Id: <20230924052824.449219-2-damien@zamaudio.com>
|
|
Message-Id: <20230923105449.425849-1-damien@zamaudio.com>
|