Haiku OS guest support #61
Comments
LekKit
added
enhancement
|
@X547 As far as I see, NVMe IRQ loss doesn't happen when running your Haiku build with ATA & Another interesting thing, EFI framebuffer seems to work properly now with nightly images & new U-Boot. I don't know what fixed it, I tried older RVVM commits but it still works... Maybe it was just a fluke or some local issue, huh. Would be happy if you can verify these.
|
ATA MMIO address is currently hardcoded both in boot loader and kernel. Kernel ATA driver need refactor because it currently assumes that register addresses are 16 bit. |
I hope we can just ignore all of this and get NVMe running instead. Where can I find |
It is here: https://github.com/haiku/haiku/blob/master/src/system/boot/platform/riscv/devices.cpp#L33. It is needed to add some |
|
My Haiku RVVM branch: https://github.com/X547/haiku/tree/rvvm2. WIP NVMe boot loader driver: https://github.com/X547/haiku/blob/e717045595ebbd71a30731bc57c96a5d1a68ef52/src/system/boot/platform/riscv/NvmeBlockDevice.cpp. |
|
I'm not sure I properly understand how to build Haiku |
You need to configure build first. It will build GCC for riscv64 target. Assuming that current directory contains |
Spell miss? Correct is |
I did that already using this guide https://www.haiku-os.org/guides/building/compiling-riscv64
I tried many, none worked (With the same error) |
|
Improved upstream ATA in 43aeba3, at least it's no longer a security hellhole (3 CWEs fixed, lol). Merged your API changes so you no longer need to hack on it each time. Is it worth adding some kind of |
https://www.haiku-os.org/guides/building/pre-reqs |
Ideally it will be nice to have an option to specify drive type for each image independently. |
Yes, it's just a convention that I have no plans for more storage devices currently. That's why I don't know what should I do with the CLI interface, really. |
|
Did you solve a problem of Haiku build? What Haiku source version are you using? What happens if run |
Using your Haiku fork, rvvm2 branch |
Fixed, source updated. |
|
Functional configuration:
|
Hurray, I now can at least try it since we have working i2c hid and stuff... Feels great (Tho perf could be better, I'm currently losing to QEMU here perhaps. Haiku uses floats a lot, right?) Will proceed to NVMe bootloader driver |
|
Hmm, sometimes I2C HID deadlocks apparently. Pretty rare to spot but I've seen these 2 times already. |
Syscon doesn't seem to work. Powering off the system from the guest leaves me with some win2000-vibe message "It's now safe to turn off the computer" and the machine never actually powers down. Should be trivial to implement, syscon is just a single mmio register with specific values for poweroff/reset. This is also used in QEMU and on SiFive boards AFAIK. |
|
Haiku currently support shutdown and RTC with HTIF commands. RTC HTIF interface is my extension and it work only in my TinyEMU fork. |
I can implement that as well probably? |
I think that it is better to implement more standard interfaces. HTIF commands currently used by Haiku:
Executing HTIF command: // host-target interface
struct HtifRegs
{
uint32 toHostLo;
uint32 toHostHi;
uint32 fromHostLo;
uint32 fromHostHi;
};
uint64
HtifCmd(uint32 device, uint8 cmd, uint32 arg)
{
if (gHtifRegs == 0)
return 0;
uint64 htifTohost = ((uint64)device << 56)
+ ((uint64)cmd << 48) + arg;
gHtifRegs->toHostLo = htifTohost % ((uint64)1 << 32);
gHtifRegs->toHostHi = htifTohost / ((uint64)1 << 32);
return (uint64)gHtifRegs->fromHostLo
+ ((uint64)gHtifRegs->fromHostHi << 32);
}FDT |
Yeah, syscon and goldfish rtc were implemented just because they match basic QEMU machine. I would prefer emulating hardware from real RV boards (current PLIC/CLINT/UART/I2C-OC/NVMe fall into this category well) or just some generic common hardware (simple-fb perhaps counts?.. My RPi uses this driver as well). |
|
Haiku
|
This is userland process crash. It can be continued with
|
Latest nightly image from https://download.haiku-os.org/nightly-images/riscv64/
Ah, I see |
|
I see there is an experimental stateful kernel event API in Haiku, and I tried to compile RVVM with This brings support for infinite amount of connections / port forwards and better performance.
Is there any way I can check for it's presence at compile time & runtime to add support for this without breaking compatibility with older Haiku versions? |
I think nothing better that function symbol presence detection in |
Should be fixed now (But the design will be further improved).
Should be also fixed as #118 is closed, but I don't have a proper Haiku image to test this fully. Upstreamed new RTC device (Dallas DS1742) which is present on some boards; Implemented SiFive GPIO device & GPIO API. |
This is likely because by default Haiku builds without SSL support. You need to specify |
It would be more useful to have VisionFive 2 GPIO. SiFive Unmatched if effectively end of life. |
Will try to implement it, I just need any already good working one for a side project related to RVVM. I also expect SiFive GPIO to be present in more boards in future (MilkV Oasis?). I also had a look at |
|
Can't build Perhaps some CI for those WIP Haiku versions is needed? Many complications arise each time I try to build them, upstream Haiku still doesn't have working I2C HID in RVVM and has memory corruptions. |
This is a known thing (and have it happened to me here too), try replacing it (create a backup) with this file in the source: https://github.com/haiku/haiku/blob/master/build/jam/repositories/HaikuPorts/riscv64 |
|
|
|
Try to kill it, it will auto-restart and maybe fix problem. It may be a bug in net_server DHCP handling and/or obscure behavior of RVVM DHCP emulation. |
|
Crash in Haiku UART logNote it mentions failure to get VBIOS from PCI ROM BAR, but PCI ROM BAR is for some reason "disabled" in host lspci and isn't available to VFIO API. 0a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev e7) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 0519
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 62
IOMMU group: 15
Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at e0000000 (64-bit, prefetchable) [size=2M]
Region 4: I/O ports at e000 [size=256]
Region 5: Memory at fce00000 (32-bit, non-prefetchable) [size=256K]
- Expansion ROM at 000c0000 [disabled] [size=128K]
Kernel driver in use: vfio-pci |
Any ideas how? AtomBIOS is critical for Haiku |
Here is amdgpu log from RISC-V Linux on the same VM & host setup Apparently PCI ROM availability depends on CSM (Legacy BIOS features) but my host system boots from EFI and has CSM disabled in the firmware options. This is why PCI ROM BAR is "disabled" in lspci and isn't available to VFIO. Linux amdgpu driver has multiple other ways to get VBIOS, in case of RVVM guest it dumps ROM using this method: Here is what it does on a different x86 machine (Reads from VFCT which is part of ACPI tables): ACPI + amdgpu logIt might be possible to implement a workaround and read PCI ROM from RVVM using another method instead of VFIO, then pass it to the guest as PCI ROM BAR, but I don't know how feasible it will be yet. |
|
This is what is I guess used for my GPU (Which is gfx8.0) and most modern ones: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/vi.c#L635 A few other AMD GPU families have different ROM dump method, namely Southern Islands (SI), Sea Islands (CIK), and some iGPU variations: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/si.c#L1306 |
|
Got this and freeze after attempting to download a file hosted on host Haiku with |
Did it eventually unfreeze, and if so did it continue the download? Or if it was otherwise stuck, were those messages repeated or only reported once?
Interesting. Looking at the code in question there isn't real deadlock potential, but it may invoke a handful of syscall variations under this lock, which could cause this.
I know this is not ideal (Locking should preferably only happen around structure manipulation and not heavyweight syscalls), but the finer grained locking design was postponed to prevent introducing new subtle sync bugs.
What upstream revision is that based on? |
It stuck forever and the same message repeats.
c4cc337 with minor Haiku window changes. |
Is it before |
|
@X547 Okay I discovered a weird kinda-bug, kinda-disagreement in how RVVM & Haiku understand POSIX API. Look at this: 087bd6b. Historically, With upstream Reverted 087bd6b: Why |
|
I should probably patch this and enable But it should be also looked at from Haiku side. I found this |
|
I looked at Haiku's source code. |
|
It seems I mixed things up a bit, my bad. Indeed the only Haiku bug is that UPD: Should be fixed by aaf8995 |
Bisecting the issue leads to f791aa5. So somehow the tiny difference to clocksource precision made This is one of those optimizations I purposely made at the beginning of v0.7-git development cycle to determine if it breaks anything during this version development. However, I am not sure that I'll try to inspect how exactly timings are impacted by that RVVM commit and report back - this is probably also very host-dependent. Perhaps this |
It is very likely that the bug is on Haiku side and RVVM behavior is fine. Anyway DHCP client should not crash when receive malformed data. |
Well DHCP handling has probably nothing to do with it. Something in I checked, and can confirm that RVVM timer clocksource never jumps back when using This diff --git a/src/rvtimer.c b/src/rvtimer.c
index 0c17c44..06c4031 100644
--- a/src/rvtimer.c
+++ b/src/rvtimer.c
@@ -74,6 +74,9 @@ uint64_t rvtimer_clocksource(uint64_t freq)
{
struct timespec now = {0};
clock_gettime(CHOSEN_POSIX_CLOCK, &now);
+
+ now.tv_nsec -= now.tv_nsec % 1000000;
+
return (now.tv_sec * freq) + (now.tv_nsec * freq / 1000000000ULL);
}
This drops RISC-V timer precision to 1ms. Note that 1ms is not that bad precision, and even peak for some hosts (x86 machines without TSC/APIC, etc). Commit f791aa5 simply extends this list. |
|
I reverted back to If you want to debug |
Milestones, progress
The text was updated successfully, but these errors were encountered: