| Age | Commit message (Collapse) | Author |
|---|
|
We should only set USER
- for user processes maps
- for 32bit Xen support
This was not actually posing problem since in 32bit segmentation
protects us, and in 64bit the l4 entry for the kernel is already set.
But better be safe than sorry.
|
|
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>
|
|
This adds a parameter called keep_map_locked to vm_map_lookup()
that allows the function to return with the map locked.
This is to prepare for fixing a bug with gsync where the map
is locked twice by mistake.
Co-Authored-By: Sergey Bugaev <bugaevc@gmail.com>
Message-ID: <20240222082410.422869-3-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: <20240211115958.1889648-1-damien@zamaudio.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>
|
|
vm_page_grab_contig does not necessarily allocate at the beginning of
the DMA segment, so rather allocate by hand very early.
|
|
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>
|
|
This enables gnumach to additionally parse the XSDT table
if the revision of ACPI is 2.
TESTED: Still works on qemu (ACPI v1.0)
TESTED: Works on a x86 board with XSDT (ACPI v2.0)
Message-ID: <20240131021218.1335821-1-damien@zamaudio.com>
|
|
Move cninit() further down so that IOAPIC has a chance
to initialize before the com port interrupt is unmasked
in the IOAPIC, fixing a fault and reboot.
Message-ID: <20240131100210.1354522-1-damien@zamaudio.com>
|
|
For rumpdisk to efficiently determine the physical address, both
for checking whether it is below 4GiB, and for giving it to the disk
driver, we need a gnumach primitive (and that is not conditioned by
MACH_VM_DEBUG like mach_vm_region_info and mach_vm_object_pages_phys
are).
|
|
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>
|
|
Since we are not using legacy MP tables but intending to use ACPI
to configure interrupt routing, we can assume all boards have
virtual wire mode, thus do not require setting of IMCR register.
(This may fix crashes on machines that do not have IMCR registers).
Message-ID: <20240124035138.1044855-2-damien@zamaudio.com>
|
|
TESTED: By booting gnumach off an HP T620 with console=com0 and receiving 115200 8N1 console
on another machine connected via the serial port in minicom.
Without this patch, part of the console is garbled by mismatching com params (9600 7N1).
Message-ID: <20240119031214.691086-1-damien@zamaudio.com>
|
|
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.
|
|
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>
|
|
|
|
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.
|
|
Message-Id: <20231001045755.95707-1-damien@zamaudio.com>
|
|
Message-Id: <20231001045731.95682-1-damien@zamaudio.com>
|
|
This also makes the code more coherent with other levels.
|
|
This is convenient when tracking buffer overflows
|
|
Message-Id: <20230930063032.75232-3-damien@zamaudio.com>
|
|
Message-Id: <20230930063032.75232-2-damien@zamaudio.com>
|
|
They are useless on x86_64.
|
|
This follows aaa33bd1ef300380279d9e2875b61a7abaf2c88d
|
|
|
