It comes with AVX, so enable it if we've enabled AVX.
This also adjusts altcodepatch_replace to explicitly set NOPs
for the remainder of the patch area.
Change-Id: Ia07549851d86836ff5428635b580c751b4e5b2a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10867
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
[+] Implemented proper initialization and detection for eMMC card at mmc_bus.cpp
[+] Extended SD_COMMANDS enum at mmc.h to support eMMC CMD3. some common commands
are highlighted removing its specific card type prefix.
[+] Reading eMMC Device CID register attributes for initiating mmc disk node.
[+] added formal register content wrapper classes.
[+] Printing some attrs for debugging and verification.
[+] MMCBus and SDHCIBus are aware of the underlying card type, no problem unless more than one device
on same mmc bus.
i followed the specs on CID stipping, still asking for your validation.
Built and tested with success for QEMU emulated sdHC eMMC device, also tested with emulated
SD card to verify nothing backfires.
my reference is JESD84-B51 document.
*log file looks has this:
mmc_bus: Trying MMC CMD1 initialization...
...
mmc_bus: Detected MMC card after CMD1
...
...
mmc_bus: MMC RCA: 1 Status: 500
mmc_bus: MMC CID: MID=0, name="XQEMU!", PSN=31370686, PRV=201, MDT=14/2028
Change-Id: Ia6e93b154548ff7cf2dfae3bcffe85e6b2aa01fb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10641
Reviewed-by: Adrien Destugues <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Putting all the per-CPU messages in one array means they'll all
be on the same cache lines. The cpu_ent structure is cache-line-aligned,
so this means they'll be on separate cache lines.
The goal is to handle `FIXME` within WorkerThread that of MMCBus.
[+] Extended SDHCIBus to have:
> private PowerOff() to clear corresponding VDD1 power bit.
> Public TerminateBus() to terminate the bus
powering off,disabling clock and interrupts.
Also called within the destructor.
[+] Extend `mmc_bus_interface` to encapsulate terminate_bus
coping the same style of other interface utilities.
[+] MMCBus can its newly added private _TerminateBus() for handling sd cards
not supporting proposed voltage range.
Testing:
- used false invokation on qemu emulated sd card to test
the termination branch.
- Successfully built and run,SD card doesn't show up in DriveSetup
- debug Log show correct power and clock bit setting(power=0xe, clock=0x800b).
Please Guide me further on more effective test method.
Change-Id: Icc8eeac97b9c96dfbf0106871d26a41d7faea5dc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10622
Haiku-Format: Haiku-format Bot <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
* SCTLR register definitions made 64-bit
* isb added after writing to SCTLR, to ensure we don't execute
instructions requiring the MMU prior to the MMU being enabled
* GICv2 has per-cpu registers for IRQs < 32, so enabling or
disabling those IRQs needs to be done on all cores
* MMU setup code in kernel and bootloader made per-cpu
* Signiture of arch_smp_boot_other_cpus is now the same on all
architectures, with an addr_t page table
Change-Id: I13bef7ca4efc5504d643833664560a9a6a6a6964
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10649
Reviewed-by: waddlesplash <[email protected]>
Previously, busy-writing pages just stayed in the cache until
I/O finished. This wasn't right, as they should've been unmapped
(and removed) immediately, as a TODO in the PageWriteWrapper noted.
Now they are, and they're moved into a queue on the cache pending
the I/O completing.
This paves the way for fixing #18390.
Change-Id: I51778ba1cfc1d26f34dd44f1ee293381be59937f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8627
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Before, it just used a hardcoded Element::link member. Now,
it uses whatever one is specified based on the template
arguments.
No source compatibility breakage intended.
Change-Id: I62128921766df0b705488eb64402f902334f2ed0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10589
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
This fixes a long-standing TODO, and a major inconsistency
that for different caches, "commitment" reserves from different
pools, so any two aren't necessarily convertible.
The new system introduces a virtual method "TakeCommitmentFrom",
which allows the VM's cut_area routine to behave as it did
previously.
They mostly contained descriptions of functions' operations, not
what they're for, so they weren't so useful. I've added some of
the remarks they had (or ones with a similar purpose) inline
as documentation comments, and deleted the rest.
The documentation file hadn't been updated in a very long time,
and referred to locks and paradigms that have long since been
dropped (e.g. sMappingLock was removed in 2010, in
afed2658f4ef3e3df5ff8390d1d7a51b5b897a9e.)
Add a few "protected by" comments in VMArea to clarify things,
but otherwise this document looks entirely obsolete (I went
through all of it.)
Before this commit, swap space was committed entirely orthogonally
from memory commitments. This was not handled at all correctly
when cutting areas (the area cutting logic tries to migrate commitments
between caches, but in the case of swapping caches, it didn't,
and couldn't, take the separate fCommittedSwapSize into account.)
Even without that problem, totally separate swap and memory commitments
caused other problems. For instance, suppose a setup with 4GB of RAM
and 4GB of swap. Many caches are created, and all 4GB of swap gets
reserved, but the caches with this swap reserved have no or few pages
in them. Then, all 4GB of RAM gets used up. The page daemon runs, and
looks for things to swap out, but it can't find anything because all
our swappable caches with pages have no swap reservations, so all it
can do is flush out cached pages, which just degrades performance.
Or, consider what would happen if the 4GB of swap was released, but
the 4GB of RAM was still in use, and then the kernel tried to
allocate memory. It would get OOM errors, because none of the
caches have swap commitments and so nothing can be written out.
Under this new system, the specific swap space reservation only happens
just before the page is first written out, so both these cases should
be handled smoothly, and swap should be used in a much more sensible
fashion overall.
This change seems to be more in line with what other OSes do (Windows
Task Manager's "Committed" clearly is RAM+swap, for instance.)
The only potential downside to this change is that swappable caches
may temporarily go over their commitment when reading or writing
out pages to swap, before the page daemon has a chance to come by
and free the page or the swap space. But as that is a temporary state
and should always be resolved by the page daemon, I think it's
probably an acceptable trade-off.
Change-Id: I928f4b4cacbec26ed6315179476eaff1a7f626c8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10305
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
This begins paving the way for removal of user access to kernel
address space.
After the previous commits, BDirectWindow and BWindowScreen
still function properly.
Part of #19990.
Change-Id: I8477e43cd517ba67383755a4cb60b00bc117f5d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10559
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This will be useful in the case of cloned device caches based
around physical memory, e.g. for framebuffers.
Change-Id: If2b864208e86f436e91379b73c4b866b0bd5e1d7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10558
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
It can't work if the framebuffer is mapped per-application.
Instead, use the accelerant hook to get the framebuffer.
The BScreen methods this disables were deprecated and marked
private already, so no Haiku applications should be affected.
(If really necessary they could be reimplemented with BWindowScreen.)
Remove first _GetCardInfo in BWindowScreen; we invoke it
later, closer to where the buffer is actually used.
Tested with ParticlesII (which uses BWindowScreen) on VESA
with the new user-only-mapping accelerant.
Change-Id: I405bcfa8cb1eb2d0c346fafbc6233bef15196134
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10572
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Instead of the kernel heap being a compile-time parameter, make it
a runtime parameter (if DEBUG_HEAPS is specified, at least; otherwise
we're hardwired to the slab heap as before.)
This is similar to what's done in userland: there LD_PRELOAD and
MALLOC_DEBUG control the heaps, here "kernel_malloc" and then
"guarded_heap_options" kernel settings control the heap.
While at it, apply fixes to the guarded and debug heaps to ensure
a minimum alignment of sizeof(void*), if no specific alignment
is requested.
Tested with a lot of build configurations (DEBUG_HEAPS 0, 1;
DEBUG_HEAPS_DEFAULT slab, guarded; USE_DEBUG_HEAPS_FOR_OBJECT_CACHE
0, 1) and with various parameters specified in the bootloader.
* Insert/Remove can't fail, so drop status_t return values.
* "TransferAreas" is really "TakeAreasFrom", so rename it. This
avoids confusion with the "transfer_area" API call, which moves
an area to another address space (keeping the same cache.)
* Give arch_vm_supports_protection a team_id argument (primarily
to allow the kernel address space to be more restricted than
user ones.)
* Move invocation of arch_vm_supports_protection to a static method,
and also call fix_protection from there.
* Consolidate protection checks.
Adds support for the Hyper-V SCSI controller as part of the hyperv_scsi
driver. This driver enables the use of Hyper-V generation 2 VMs as
the SCSI controller is the only storage method supported.
IDE hard disks can be supported in the future on generation 1 VMs by
this driver, but this will require a mechansim to prevent the ATA
bus manager from handling hard disks and conflicting with this one.
Change-Id: Iabb9c0471578caf1ef80754f39a09e1ce0eb4249
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10504
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
* E2H (EL2 Host) is enabled by default and usually can't be disabled
on CPUs with FEAT_VHE. Since EL2 becomes a superset of EL1 with
E2H, we can simply do nothing and everything that expects EL1
will Just Work
* Changed some register bits numbers to avoid C integer promotion
issues
* sEmptyTable needs to be filled in earler, before the kernel team
is created. Otherwise, we put the uninitialized value of sEmptyTable
in TTBR0, which immediately pends SError on Apple M1
Change-Id: I84ff7fd9134448f27315dadfd12bdd9df8c75b10
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10547
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
These allow us to move a lot of the basic logic out of the
TranslationMaps. In the process, it extends the fix applied
to x86 in the previous commit to all the other maps.
Following upon a KDL reported by atomozero, on wait-for-free-SMP-messages
on an unblock occurring with interrupts disabled.
In changing cpu_ent, move disabled to the beginning to avoid
enlarging the structure unncessarily.
On a 4-core VM, this skips around 200 sends during boot, and
over 3000 during a rebuild of HaikuDepot + mime_db (cold). On
bare metal (i3, 2x2), it skips around 150 during boot, and a bit
below 3000 during a rebuild of HaikuDepot + mime_db (over a much
longer time than in the VM, as the hardware is slower.)
Performance in the VM doesn't look much different. But this might
help in VirtualBox, or other situations where ICI latency is far
above what it should be.
Since the methods now don't just "send", the names are changed
also (which is fitting since they're now API-incompatible.)
The changes in the TranslationMaps to adopt this fixes a correctness
issue: previously TLB invalidations would be done either with or
without interrupts enabled depending on how they were invoked.
Now, they'll always be done with interrupts disabled. (This is
the same fix that was recently done to x86.)
The idea with processing the ICIs on the current CPU too is
that presumably the other CPUs will take just as much, if not
more, time processing the ICI than the sending CPU. So, we might
as well do the processing while we wait, rather than before or after.
Testing shows this to indeed be the case. On a bare metal i3, kernel
map invalidations (with global invalidations always forced) across
a boot-to-desktop go from around ~60.8ms cumulative before,
to ~51.8ms cumulative after this change.
Change-Id: Icd0343d462de7cf11043e6438f47b02f6b88bb8b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10472
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
connecting
Sends an auth request to the controller, if connection was initated by
us
Change-Id: I32af0a24b902d0223bb4e773258ea9e9749a899c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10527
Reviewed-by: waddlesplash <[email protected]>
CreateConnection
Move expecting commands from RemoteDevice::Authenticate to where they
are called.In SSP we expect for the events after ConnectionComplete.
For the state machine, LINK_KEY_NOTIFY tells us the end of the pairing
in both pairings, so we clear all expected events there for the ones we added in
ConnectionComplete, In SimplePairingComplete we clear the ones added
in IOCapabilityRequest. Tested with both bluetooth 2.1 and older pairing.
Change-Id: Ia208506c9f289d9f44dc3b8b0e4cd8a726a5d726
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10526
Reviewed-by: waddlesplash <[email protected]>
Currently the IO-APIC is fully initialized after PCI initialization
resulting in the IO-APIC not being initialized on systems without a
PCI bus (i.e. Hyper-V Gen2 VMs). This change moves IO-APIC
initialization to occur during early init, deferring PCI interrupt
enumeration and routing until after PCI initialization has been
completed.
Change-Id: I00be0be05d2e7668c3c6bc7af3afc4ff8d04a129
Reviewed-on: https://review.haiku-os.org/c/haiku/+/10414
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: X512 X512 <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Elaine Gibson