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
|
The Thanks for the report! |
I'm on a Mac Studio with M1 Ultra for the host, and I was testing RVVM with
I'll try to keep an eye on the repo, but if you have any code you'd like me to test to see if it fixes my issues, whether it's in a PR or merged, feel free to ping me and I'll try it out! |
It might be that the down/up key events are sent immediately by your host (firmware quirk?), the guest fails to handle the first interrupt in time, thus only receives the "key up" event and gets confused. I can reproduce it by manually sequencing those events in code, but when handling real user input there was usually slight delay which hid the issue from plain sight. I guess you could try to hack it around to make sure this is really the case I imagine:
This will make the GUI thread lag slightly on keyboard events, but if it fixes the loss of keyboard input then I'm certain what fix will be right |
Well, I'll be damned. That actually makes all my keyboard input show up perfectly in RVVM! (Edit: even using 10ms instead of 20ms works fine for an extended typing test I just did.) |
|
hrev57592: |
Is it upstream or some branch? Upstream Haiku seems have random corruptions in heap allocator on non-x86 platforms. I fixed it in my |
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 |
Milestones, progress
The text was updated successfully, but these errors were encountered: