aboutsummaryrefslogtreecommitdiff
path: root/usr.sbin/bhyve
Commit message (Collapse)AuthorAgeFilesLines
* bhyve.8: Improve readability by not breaking -f's synopsisMateusz Piotrowski8 days1-1/+1
| | | | MFC after: 3 days
* bhyve.8: Fix formatting of -G's "w" prefixMateusz Piotrowski8 days1-4/+4
| | | | | | | "w" is a command modifier, not an argument. Use Cm. Fixes: 2cdff9918e79 byhve: add option to specify IP address for gdb MFC after: 3 days
* bhyve/virtio-scsi: Don't invoke iov_to_buf() in an assert() expressionHans Rosenfeld2026-05-061-2/+4
| | | | | | | | | | If anyone would build bhyve with -DNDEBUG, any code in the expression in assert() won't be executed. Instead put the return value in a temporary variable to assert that it has the expected value. Reviewed by: emaste, markj (earlier version) Fixes: 2a514d377b37 ("bhyve/virtio-scsi: Preallocate all I/O requests") Differential Revision: https://reviews.freebsd.org/D55803
* bhyve: allow read/write to full CRB bufferCorvin Köhne2026-04-301-1/+1
| | | | | | | | | | | For some reason, we've incorrectly calculated the size of the CRB data buffer register. There's no need to divide the CRB data buffer size by 4. We should allow access to the whole buffer instead. Reviewed by: markj MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Pull Request: https://github.com/freebsd/freebsd-src/pull/2169
* libvmmapi: Check for allocation failure in vm_vcpu_open()Hans Rosenfeld2026-04-201-0/+13
| | | | | | | | | | vm_vcpu_open() really should check the value returned from malloc() and return NULL on failure. Also, all users of vm_vcpu_open() need to check the returned value for NULL, too. Reviewed by: corvink, markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D56346
* bhyve/virtio: Fix comparison of integer expressions of different signednessHans Rosenfeld2026-04-012-7/+7
| | | | | | | | | | | | | It's a bit silly to have iov_to_buf() and buf_to_iov() return a ssize_t to begin with, just to be able to return -1 for error. Change this to size_t and use 0 as an error indicator, which won't require any changes to the code using these functions. While here, switch iov_to_buf() to use reallocf() instead of realloc(). Reviewed by: jhb Fixes: 2a514d377b37 ("bhyve/virtio-scsi: Preallocate all I/O requests") Differential Revision: https://reviews.freebsd.org/D55800
* bhyve/virtio-scsi: Check LUN address validityHans Rosenfeld2026-03-041-15/+108
| | | | | | | | | | Instead of blindly trusting the guest OS driver that it sends us well- formed LUN addresses, check the LUN address for validity and fail the request if it is invalid. While here, constify the members of the virtio requests which aren't device-writable anyway. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53470
* bhyve/virtio-scsi: Preallocate all I/O requestsHans Rosenfeld2026-03-041-117/+359
| | | | | | | | | | | | | By preallocating all I/O requests on all queues, we can take most allocations out of the hot I/O code paths and simplify the code significantly. While here, make sure we check all allocations for success and make sure to handle failures gracefully. Additionally, check for I/O request validity as early as possible, and return illegal requests immediately. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53469
* bhyve/virtio: Rework iovec handling functions for efficiency and clarityHans Rosenfeld2026-03-044-106/+136
| | | | | | | | | | | | | | | | | | | | | | | | Add check_iov_len() to check whether an iovec array covers a certain length without the need to call count_iov() on the whole array first. Garbage-collect the 'seek' argument to buf_to_iov(), used only by virtio-scsi control request handling. The apparent benefit of using it to copy only the final status byte instead of the whole TMF or AN request (25 and 21 bytes, respectively) is dubious at best, given that the extra code to handle this in buf_to_iov() allocates and frees a new iovec array and uses seek_iov(), which traverses the whole array and copies iovecs around. Replace seek_iov() and truncate_iov(), used only by virtio-scsi, with a single function split_iov() which combines the functionality of both in a more efficient way: While seek_iov() always copies all iovecs past the seek offset into a new iovec array, split_iov() works in place and doesn't copy iovecs unless actually necessary. By using split_iov(), we can avoid almost all copying of iovecs in I/O handling code paths of virtio-scsi. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53468
* bhyve: Fix truncate_iov()Mark Johnston2026-02-241-10/+5
| | | | | | | | | | | | | The implementation was simply wrong. It would always just return the first entry in the iovec, even if the requested length is larger than that first entry. Note, this function will be removed soon, see D53468. Reported by: Vinod p n <vinod272@gmail.com> Reviewed by: des, emaste, Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org> MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D55438
* bhyve: Add SPDX-License-Identifier tagTuukka Pasanen2026-02-201-0/+2
| | | | | Reviewed by: emaste Sponsored by: The FreeBSD Foundation
* bhyve: fix USB mouse requestsChuck Tuffli2026-02-191-9/+17
| | | | | | | | | | | | | | | | | | | | | USB HCI requests may not include HCI transfer block structures (i.e., xfer->data[] == NULL), but in several places, the USB mouse emulation code assumes one will exist. This can lead to a NULL pointer dereference and a SEGV in the bhyve process as observed via experiments with an Ubuntu guest and PyUSB code. Note that many of the cases processing other request types already checked for data == NULL. While in the neighborhood, fix a typo in the loop iterating over the usb_data_xfer_block array which used the wrong variable to check for valid data (idx vs. i). Reported by: danmcd@edgecast.io Obtained from: SmartOS MFC after: 1 week Relnotes: yes Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D54661
* bhyve: Fix unchecked stream I/O in RFB handlerHayzam Sherif2026-02-191-22/+54
| | | | | | | | | | | | | Convert rfb_send_* helpers to return status codes and check their results. Add missing checks for stream_read() and stream_write() returns during the handshake in rfb_handle() to avoid acting on failed I/O. Signed-off-by: Hayzam Sherif <hayzam@gmail.com> Reviewed by: markj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D55343
* vmm.4: Add information on VM access controlMark Johnston2026-02-191-5/+20
| | | | | | | | | Add a section to vmm.4 explaining how vmm device file ownership works. MFC after: 2 months Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54742
* bhyve: Propagate errors from rfb_recv_* functionsHayzam Sherif2026-02-161-25/+76
| | | | | | | | | | | | Update rfb_recv_* functions to return -1 on failure and 0 on success. Update rfb_handle to check these return values and drop the connection if an error occurs. Signed-off-by: Hayzam Sherif <hayzam@gmail.com> Reviewed by: markj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation
* bhyve: Fix a misleading error messageMark Johnston2026-02-161-2/+7
| | | | | | | | | | | The ioctl might fail because it's run in a jail which doesn't have permission to invoke ppt ioctls. Reviewed by: jhb MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55070
* bhyve: Simplify passthru_msix_addr()Mark Johnston2026-02-061-54/+26
| | | | | | | | | | It can use the passthru_mmio_map() helper function. Make that change, and also make passthru_mmio_map() use EPRINTLN to fix formatting when the guest console is stdio. Reviewed by: corvink, jhb MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D55067
* bhyve/virtio-scsi: Unlimit max_sectorsHans Rosenfeld2026-02-061-1/+2
| | | | | | | | | | | | The old default of 2 for max_sectors limits performance significantly with guest systems where the virtio-scsi driver actually honors this value. As CTL doesn't seem to have any limit of the maximum size of a single transfer, set this to INT32_MAX by default. Reviewed by: corvink Differential Revision: https://reviews.freebsd.org/D53466
* bhyve/virtio-scsi: advertise support for indirect descriptorsHans Rosenfeld2026-02-061-1/+1
| | | | | | | | | | | Support for indirect registers is actually part of the common virtio code, the virtio-scsi code doesn't actually care or even know anything about it. Advertising the features greatly improves performance with some guest operating systems. Reviewed by: corvink Differential Revision: https://reviews.freebsd.org/D53467
* bhyve/virtio: check negotiated_caps for indirect descriptor supportHans Rosenfeld2026-02-051-1/+1
| | | | | | | | | | | vq_getchain() erroneously checked vc_hv_caps for indirect descriptor support when it encountered an indirect descriptor. vc_hv_caps is used in feature negotiation to advertise what features our device emulation supports, but we should really check what features we have negotiated with the driver. Reviewed by: corvink Differential Revision: https://reviews.freebsd.org/D53465
* bhyve: Use PCIOCGETCONF to find the host LPC bridgeMark Johnston2026-01-263-43/+60
| | | | | | | | | | | | | | | | | | | | pci_host_read_config() requires write access to /dev/pci so cannot be used with unprivileged bhyve. The lpc init code uses it to find the host system's LPC bridge device and so was generating warnings with bhyve running as a non-root user. Refactor the implementation to use PCIOCGETCONF instead, which doesn't require any special privileges. This isn't formally necessary, as we only care about copying the host system's identifiers in order to support Intel GPU passthrough (see commit f4ceaff56ddaa), but it's straightforward and lets an unprivileged user run bhyve without seeing warnings about failing to open /dev/pci with write permissions. Reviewed by: corvink, rew MFC after: 3 weeks Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D54851
* bhyve: Want walk_config_nodesHans Rosenfeld2026-01-162-16/+42
| | | | | | | | | | Add a function to all nodes under a config option node. This allows parsing an arbitrary number of similarly structured configuration options in a config option group. Reviewed by: corvink, markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D51551
* Fix NULL deref segfault in bhyve's usb_mouse.cJack Bendtsen2026-01-091-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the cases inside umouse_request() (usr.sbin/bhyve/usb_mouse.c) use the data component of an event, while only partially checking if it's NULL. 'data' has a NULL check, but then 'data' is immediately deferenced anyway after the check regardless of if it's NULL or not. For example: case UREQ(UR_GET_STATUS, UT_READ_INTERFACE): case UREQ(UR_GET_STATUS, UT_READ_ENDPOINT): DPRINTF(("umouse: (UR_GET_STATUS, UT_READ_INTERFACE)")); if (data != NULL && len > 1) { USETW(udata, 0); data->blen = len - 2; data->bdone += 2; } eshort = data->blen > 0; break; There are actually four occurrences of this same bug, each in a different case in this switch block. Signed-off-by: Jack Bendtsen <jackdbendtsen@gmail.com> PR: 282237 Reviewed by: imp, jhb, vexeduxr MFC After: 1 week Pull Request: https://github.com/freebsd/freebsd-src/pull/1728
* bhyve: support MTU configuration for SLIRP net backendRoman Bogorodskiy2026-01-083-14/+47
| | | | | | | | | | | | | | | Support configuring MTU for the SLIRP net backend, for example: -s 1:0,virtio-net,slirp,mtu=2048,open Update the manual page accordingly. While here, also document MAC address configuration. Reviewed by: markj Approved by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D54133
* bhyve: add UNIX domain socket support to rfbQuentin Thébault2026-01-085-19/+73
| | | | | | | | | | | | | This commit adds support for a UNIX domain socket to bhyve's remote framebuffer. It enables the use of the graphical console when the bhyve instance is running in a jail with no networking, for instance. A VNC client running on the host can then connect to the UNIX domain socket through the filesystem. Signed-off-by: Quentin Thébault <quentin.thebault@defenso.fr> Sponsored by: Defenso Reviewed by: kevans, markj MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D53814
* bhyve: improve console error reporting on arm64Roman Bogorodskiy2026-01-071-5/+8
| | | | | | | | | | | | | | Currently, on arm64, if bhyve fails to initialize the console, it falls into assert(), which does not look particularly pretty for users. Replace the assert with proper error handling so bhyve prints a meaningful error message and exits with status code 4 (error). That matches the behavior on amd64. Approved by: markj Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D54504
* bhyve: Use a blocking socket in the helper processMark Johnston2025-12-291-0/+2
| | | | | | | | | | The send_packet callback does not handle EAGAIN, and on the recv side we already use poll() and MSG_DONTWAIT to implement a non-blocking loop. PR: 291616 Tested by: novel Fixes: 0e62ebd20172 ("bhyve: Move the slirp backend out into a separate process") Differential Revision: https://reviews.freebsd.org/D54340
* bhyve: Document that MAC address has to be unicastMichael Osipov2025-12-262-5/+10
| | | | | | | | bhyve accepts any MAC address even foreign as long it is a unicast one. Reviewed by: ziaee MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54372
* bhyve_config.5: Fix consistency and terms in manpageMichael Osipov2025-12-261-8/+9
| | | | | | | | Correct inconsistent spelling of terms and duplication. Reviewed by: ziaee MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54370
* bhyve.8: Fix consistency and terms in manpageMichael Osipov2025-12-231-33/+34
| | | | | | | | Correct inconsistent spelling of terms and duplication. Reviewed by: ziaee MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54332
* bhyve: Introduce monitor modeBojan Novković2025-12-175-27/+87
| | | | | | | | | | | | | | | | | | | | | This change introduces "monitor mode", a mechanism for automatically releasing virtual machine resources when bhyve dies, bringing us closer towards making non-root bhyve viable. Under this regime bhyve will create a transient virtual machine using `vmmctl`'s `VMMCTL_CREATE_DESTROY_ON_CLOSE` flag and automatically reboot said virtual machine as long as it exits with "reboot" status. This is done by splitting bhyve into two processes. The parent process creates the virtual machine while the child process initializes and runs the virtual machine. When the child exits the parent inspects its exit status and either exits or forks again. `vmmctl` automatically destroys the underlying virtual machine once the parent process dies. Differential Revision: https://reviews.freebsd.org/D53731 Reviewed by: markj Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. MFC after: 3 months
* bhyve: Eliminate exit status magic numbersBojan Novković2025-12-1713-50/+62
| | | | | | | | | | | | | | | bhyve's exit status codes indicate how the VM was terminated. Unfortunately, their meaning within the source code is somewhat unclear since they are only used as magic numbers. Fix this by defining exit status macros and using them to replace the magic numbers in exit(3) function calls. Differential Revision: https://reviews.freebsd.org/D53730 Reviewed by: markj, corvink, emaste Sponsored by: The FreeBSD Foundation Sponsored by: Klara, Inc. MFC after: 3 months
* bhyve: change suspend exit codeRoman Bogorodskiy2025-12-132-2/+4
| | | | | | | | | | | Currently, after suspending, bhyve(8) exits with 0. This code is also used to indicate that a VM was rebooted. To differentiate reboot and suspend, use the next available exit code, 5, for suspend. Approved by: markj Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D54087
* bhyve: pci-uart needs to also set subclass and functionToomas Soome2025-12-111-0/+2
| | | | | | | | | | edk2 PciSioSerialDxe driver setup depends on subclass and function being set, adding them does make it possible to access pci-uart serial port from UEFI. Reviewed by: corvink Differential Revision: https://reviews.freebsd.org/D54167 Sponsored by: Edgecast Cloud LLC
* xhci: Correct name of HCCPARAMS RegisterTom Jones2025-12-051-1/+1
| | | | | | | | | | On inital import the name of HCCPARAMS1 was misnamed as HCSPARAMS0. HCCPARAMS1 is defined in section 5.3.6 of xHCI Specification 1.2b (April 2023). Reviewed by: adrian Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D53895
* libuvmem: usermode port of vmem(9)Konstantin Belousov2025-12-021-1/+1
| | | | | | | | | | | | The quantum cache is disabled, there is no uma. Intent is to use this for resource allocation in bhyve(8), for start. Addition of -luvmem to bhyve linking was done to test changes to share/mk. Reviewed by: bnovkov, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D27220
* bhyve/slirp: Drop privileges before entering capability modeMark Johnston2025-11-241-5/+5
| | | | | | | | | When in restricted mode, the slirp-helper process enters a capsicum sandbox, after which we cannot look up the uid for the "nobody" user. Reverse the order. Reported by: kp Fixes: 0e62ebd20172 ("bhyve: Move the slirp backend out into a separate process")
* bhyve/slirp: Avoid a nested declaration of environMark Johnston2025-11-241-1/+2
| | | | Fixes: 0e62ebd20172 ("bhyve: Move the slirp backend out into a separate process")
* bhyve: Move the slirp backend out into a separate processMark Johnston2025-11-196-538/+676
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous implementation implemented hostfwd rules which would allow the host to connect to the guest via a NATed TCP connection. libslirp also permits NAT in the other direction, but this was prevented by bhyve's capsicum sandbox. To make the slirp backend more useful, split the backend out into a separate process which does not enter capability mode if outbound connections are permitted (enabled by setting the new "open" keyword). The process communicates with the bhyve network frontend (typically a virtio network interface) using a unix SOCK_SEQPACKET socket pair. If the bhyve process exits, the helper will automatically exit. Aside from this restructuring, there is not much actual change. Many slirp parameters are still hard-coded for now, though this may change. The "restricted" feature is toggled by the new "open" keyword; in particular, the backend is restricted by default for compatibility with 15.0 and 14.3. Each packet now has to traverse an extra socket, but this overhead should be acceptable given that the slirp backend cannot be said to provide high-performance networking. With iperf3 I can get 4Gbps from the guest to the host on a Zen 4 system. MFC after: 1 month Sponsored by: CHERI Research Centre (EPSRC grant UKRI3001) Differential Revision: https://reviews.freebsd.org/D53454
* bhyve.8: Correct description for -c flag, tag spdxAlexander Ziaee2025-10-301-2/+5
| | | | | | | | | | | | The examples only show the usage of `-c <numcpus>`, as did the flag description, however the -c flag supports more complex cpu topology specifiers. These were documented correctly in SYNOPSIS, add them to the body of the DESCRIPTION as well. Someone could go further and do and example with using them. MFC after: 3 days Event: OpenZFS Developer Summit '25 Reported by: Levi Worley <levi@gainframe.com>
* bhyve: add support for ng_device network backendQuentin Thébault2025-10-272-3/+37
| | | | | | | | | | Signed-off-by: Quentin Thébault <quentin.thebault@defenso.fr> Reviewed by: markj MFC after: 1 month Sponsored by: Defenso Differential Revision: https://reviews.freebsd.org/D52542 Pull Request: https://github.com/freebsd/freebsd-src/pull/1880
* bhyve: assign a valid INTPIN to NVIDIA GPUsCorvin Köhne2025-09-162-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | When passing an NVIDIA GPU to a Linux VM, the GPU driver refuses to work and complains about a missing IRQ: [ 77.208984] NVRM: Can't find an IRQ for your NVIDIA card! [ 77.212697] NVRM: Please check your BIOS settings. [ 77.212699] NVRM: [Plug & Play OS] should be set to NO [ 77.212700] NVRM: [Assign IRQ to VGA] should be set to YES [ 77.212702] nvidia: probe of 0000:00:07.0 failed with error -1 By setting a valid INTPIN in the PCI config space those error messages disappear. Additionally, tools like nvidia-smi are able to detect the GPU and the GPU driver seems to work properly. Note that bhyve still doesn't support legacy interrupts. So, the guest shouldn't try to use it even though we're assigning an INTPIN. Reviewed by: jhb Tested by: chuck MFC after: 1 week Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D51892
* vmm: Suspend the VM before destroying itMark Johnston2025-09-105-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we don't do anything to kick vcpu threads out of a sleep state when destroying a VM. For instance, suppose a guest executes hlt on amd64 or wfi on arm64 with interrupts disabled. Then, bhyvectl --destroy will hang until the vcpu thread somehow comes out of vm_handle_hlt()/vm_handle_wfi() since destroy_dev() is waiting for vCPU threads to drain. Note that on amd64, if hw.vmm.halt_detection is set to 1 (the default), the guest will automatically exit in this case since it's treated as a shutdown. But, the above should not hang if halt_detection is set to 0. Here, vm_suspend() wakes up vcpu threads, and a subsequent attempt to run the vCPU will result in an error which gets propagated to userspace, allowing destroy_dev() to proceed. Add a new suspend code for this purpose. Modify bhyve to exit with status 4 ("exited due to an error") when it's received, since that's what'll happen generally when the VM is destroyed asynchronously. Reported by: def MFC after: 2 weeks Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D51761
* bhyve: insert VM name to the VNC screen titleYuichiro NAITO2025-09-031-4/+15
| | | | | | Reviewed by: markj MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D52329
* bhyve: Populate the device version from the backendShengYi Hung2025-08-103-13/+39
| | | | | | | | | | | | | | | | The pci_xhci driver requires the USB device version to be known before allocating a hub port. To support this, we split the original xHCI initialization into two phases: 1. Probe: Parse the nvlist and determine the device version. 2. Init: Complete initialization and set up the softc details. This change ensures proper hub port allocation based on accurate device version. Approved by: markj (mentor) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D51478
* bhyve/arm64: Implement PSCI_FNID_CPU_OFFAndrew Turner2025-08-071-0/+3
| | | | | | | | | Support PSCI CPU_OFF by suspending the CPU and removing it from the running CPU set. Reviewed by: markj Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D51768
* bhyve/arm64: Stop assuming the CPU index is MPIDRAndrew Turner2025-08-074-13/+35
| | | | | | | | | | We need the MPIDR value in a few places in userspace. Rather than calculate it ask the kernel to give it to us. This allows us to change how it is calculated without having to change userspace. Reviewed by: markj Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D51763
* bhyve/arm64: Tidy up a licence commentAndrew Turner2025-08-071-2/+2
| | | | | | | Remove an unneeded dash and add a missing space Reported by: des (missing space) Sponsored by: Arm Ltd
* bhyve/arm64: Add a missing header fileAndrew Turner2025-08-073-0/+14
| | | | | | | | This should have been added with 8ae1d55bfcd0 ("bhyve/arm64: Mark CPU0 as on at boot"). Fixes: 8ae1d55bfcd0 ("bhyve/arm64: Mark CPU0 as on at boot") Sponsored by: Arm Ltd
* bhyve/arm64: Mark CPU0 as on at bootAndrew Turner2025-08-072-1/+4
| | | | | | | | It was missed from the set. As it's the boot CPU it starts on. Reviewed by: markj Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D51767
generated by cgit v1.3 (git 2.53.0) at 2026-05-23 01:17:30 +0000