Update with github version

Great! Thank you.

Also for uninit

If everything looks good, please merge the parent revision before merging this one.

I don't implement it on gdb just because I cannot make wait operation on gdb work on my PC. Thus I am unable to test. Still checking where is the problem.

Minor fix

Restore to zen4

Rebase with zen4 patch

Rebase with zen4 patch

Remove useless thread

I discover the original wait operation for gdb is not working now. I configure one vm with rfb and gdb. When gdb is with wait operation, the rfb does not have any output. But if the gdb is not waiting, the rfb will have output and gdb can attach to vm after boot up. I checkout to the main branch and it is also the case.

• usr.sbin/bhyve: add wait operation for uart

• Add wait operation for uart

Fix condition when there is no rendezvous member

Another consumer of rendezvous will be the raw socket over serial console that I have implemented a couple months ago. I haven't implement the wait operation on raw socket serial console. I would like to confirm the interface of rendezvous before I implement it.

Update implementation by using only one mutex and cond variable

Free members

Use correct license header

Modify copyright header

The elf parse, ctf parser is all from ctfdump and refactor it into C++. However, because it is cddl, I am wondering if there is any legal concern?

Move into usr.bin

Remove unused CTF in Makefile

It doesn't report the correct freq from zen5 (observed from htop). We can only observe a static frequency instead of dynamically changed. I will create a patch about zen4 later

BTW, is hwpstate_amd quite older than intel one? I thought it don't have autonomous mode and it throttling all cpu into same freqs.

Update debug message for fid

Fix style and report error for fid

Fix break error and add reference

Add co-author

Amend commit message

Fix indent

Use Makefile.crates

Elaborate commit message and manual

Sorry I cannot find other use case. Do you have any idea on the use case of raw tcp? Due to the unsafeness of raw TCP. We should use this feature in localhost. And because of the lack of terminal command in raw TCP support. It is much better to use modem device rather than raw tcp in localhost. So this feature actually is for proxy only (like OpenStack) because most of these applications implement raw tcp connection rather than modem device. But if we support telnet it will be useful because it is much simpler than modem device on configuration. I am planning to do so but we need this feature first because telnet is built upon tcp.

Hello, is there any update about this? Anyone want to merge this can use this to have direct patch.

Use ::1 for safe ipv6 address

User 127.0.0.1 instead of 0.0.0.0 in manual

For the 0.0.0.0 problem. I think we should fix it in the separated patch as we should also modify the VNC part.
Here is the branch that follows up the upstream modification of this patch:

Elaborate manual over TCP raw socket

Thanks for your feedback and here is the patch

Use warn instead of warnx on system call

Fix some typo and double close

Rebase and refactor comment

Prevent race condition in is_socket

• Add bhyve uart tcp backend
• Add manual page

• Add bhyve uart tcp backend
• Add manual page

@imp Hello, I found this needed feature in your idea list. Do you have any problem or feedback?

Fix it

Comply with space style

Add extra id for smbus

Remove useless newline

Move SCALE outside

Bump gstat manual

Reduce double outside scale

Apply clang-format

Rebase to main and make scale more obvious

Backward competible implementation

So do you means we only aware of the incompatible kernel and don't implement similar check for kernel module?

I think you are right, I don't think about kernel problem. And in my opinion, it is the chicken-and-egg conundrum if we implemented it in a normal ELF way (rely on VMA of section) for kernel. But it is still a mitigation for driver developer when developing kernel module. Besides, we still need uuid_addr for relocatable kernel module. I have extract my patch to contain relocatable file handling only. So I think we should preserve this patch not merge it until finding a way to verify who is the correct kernel? (by extended the kernel dump header as you mentioned or something else?)

Expose uuid for kernel module in kernel to prevent incompetable coredump loaded by debugger for relocatable file

But we cannot just rely on the file to tell use where the memory is because it maybe wrong after you compile the module. For relocatable file, you don't even have VMA to tell you where is the memory. We should use uuid_addr from kernel memory. This is why I think we should have build-id feature (The file loaded is different from the one statically resides in your file system)

Got it. Thanks for your response!

Just a question, how you test on kernel, I use spike --kernel /path/to/kernel /path/to/sbi. It give me invalid address error even after I add -m0x1000000,0x2000.

Update to 2024-05-31