Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shutdown notification to guest on window close #60

Open
X547 opened this issue Nov 24, 2022 · 10 comments
Open

Shutdown notification to guest on window close #60

X547 opened this issue Nov 24, 2022 · 10 comments
Labels
blocked on Blocked on some other feature/project enhancement New feature or request guest issue Issue caused by the guest

Comments

@X547
Copy link
Contributor

X547 commented Nov 24, 2022

Currently closing RVVM window cause instant shutdown that give no chance to gratefully shutdown guest and may cause data loss.

@LekKit
Copy link
Owner

LekKit commented Nov 24, 2022

Currently closing RVVM window cause instant shutdown that give no chance to gratefully shutdown guest and may cause data loss.

Somewhat trying to improve on that to at least not kill the process immediately (bf692d4 and similar), this at least flushes the blkdev caches. No idea how to make a graceful shutdown notification for the guest tho (That would be best).
We don't have ACPI for power button or anything like that on RISC-V afaik. USB HID has power keycode. Maybe you know other ways to notify guests about shutdown?

@LekKit LekKit added the enhancement New feature or request label Nov 24, 2022
@LekKit
Copy link
Owner

LekKit commented Nov 30, 2022

Status: If I2C HID has same keycodes as USB HID, and the HID_KEY_POWER will be properly handled by guests, this may be resolved soon (See #58).
If that approach fails, this most likely won't be worked on.

@X547
Copy link
Contributor Author

X547 commented Dec 4, 2022

@LekKit
Copy link
Owner

LekKit commented Dec 5, 2022

This should help: https://www.kernel.org/doc/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt

A bit of research reveals this signals same KEY_POWER event to the guest through internal kernel facilities on Linux, I.e. not much different from pressing HID_KEY_POWER using existing devices.
For handling KEY_POWER, udev rules are needed (or some systemd magic) which means this is never going to work for Linux guests without additional configuration within them.

I tested bunch of distros (Ubuntu, Debian, Arch) with extended DEs like KDE Plasma, everyone happily ignored HID_KEY_POWER until I manually added an udev rule.
Haiku doesn't handle HID_KEY_POWER from i2c hid as well it seems.

@LekKit LekKit added guest issue Issue caused by the guest blocked on Blocked on some other feature/project labels Mar 25, 2023
@LekKit LekKit mentioned this issue Mar 7, 2024
10 tasks
@LekKit
Copy link
Owner

LekKit commented Jun 16, 2024

Seems that at some point HID_KEY_POWER hook was implemented in Arch RISC-V distro, so that a simple sequence of HID API calls shuts down the guest cleanly:

hid_keyboard_press(win->keyboard, HID_KEY_POWER);
hid_keyboard_release(win->keyboard, HID_KEY_POWER);

However this still doesn't work for a lot of other guests (Many operating systems do not have I2C HID driver or don't handle HID_KEY_POWER). So maybe we should keep the behavior on window closing, but introduce some new GUI button or a keybind for guest shutdown?

@X547
Copy link
Contributor Author

X547 commented Jun 18, 2024

I will be happy if I will be able to gracefully shutdown VM with a close button. It will improve convenience a lot, at least for me. Kill VM by close button is dangerous and easily can cause a loss if unsaved/unflushed data.

Maybe it is a good idea to first try to send HID_KEY_POWER and then if close button is pressed second time after small time interval then show dialog "Do you want to shutdown VM? Yes/No".

For non-GUI mode HID_KEY_POWER can be mapped to Ctrl+C. Behavior can be controlled with some command-line option.

@fish4terrisa-MSDSM
Copy link
Contributor

For non-GUI mode HID_KEY_POWER can be mapped to Ctrl+C. Behavior can be controlled with some command-line option.

That's not a good choice,though. Mapping HID_KEY_POWER to Ctrl+C in non-GUI will cause trouble to stdio terminal using mode, and for most times, terminal users can stop the program by themselves and dont need a 'shutdown' option.

@LekKit
Copy link
Owner

LekKit commented Jun 24, 2024

That's not a good choice,though. Mapping HID_KEY_POWER to Ctrl+C in non-GUI will cause trouble to stdio terminal using mode, and for most times, terminal users can stop the program by themselves and dont need a 'shutdown' option.

I'm probably going to implement keybinds somewhat similar to QEMU ones:

  • Ctrl + A, X: Exit RVVM
  • Ctrl + A, P: Send KEY_POWEROFF to the machine (not sure how to access hid_kbd handle from chardev_term tho, and QEMU doesn't implement this)

It will only apply to terminals over stdio, since PTY/pipe terminals should have their own way of detaching from the session without affecting RVVM guest.

@fish4terrisa-MSDSM
Copy link
Contributor

That's not a good choice,though. Mapping HID_KEY_POWER to Ctrl+C in non-GUI will cause trouble to stdio terminal using mode, and for most times, terminal users can stop the program by themselves and dont need a 'shutdown' option.

I'm probably going to implement keybinds somewhat similar to QEMU ones:

  • Ctrl + A, X: Exit RVVM
  • Ctrl + A, P: Send KEY_POWEROFF to the machine (not sure how to access hid_kbd handle from chardev_term tho, and QEMU doesn't implement this)

It will only apply to terminals over stdio, since PTY/pipe terminals should have their own way of detaching from the session without affecting RVVM guest.

That seems good. However, will it influence the use of Ctrl + A in the guest? (For example, use Ctrl+Shift+A to behave like Ctrl+A in the guest)

@LekKit
Copy link
Owner

LekKit commented Jun 24, 2024

That seems good. However, will it influence the use of Ctrl + A in the guest? (For example, use Ctrl+Shift+A to behave like Ctrl+A in the guest)

Double Ctrl + A should send a single Ctrl + A into the guest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked on Blocked on some other feature/project enhancement New feature or request guest issue Issue caused by the guest
Projects
None yet
Development

No branches or pull requests

3 participants