New pages

New pages
Hide registered users | Show bots | Hide redirects
  • 13:03, 1 May 2025ChangeLog/10.1 (hist | edit) ‎[2,407 bytes]Pm215 (talk | contribs) (Created page with "Release schedule: Planning/10.1. == System emulation == === Removed features and incompatible changes === Consult the [https://qemu-project.gitlab.io/qemu/about/removed-features.html 'Removed features'] page for details of suggested replacement functionality. === New deprecated options and features === Consult the [https://qemu-project.gitlab.io/qemu/about/deprecated.html "Deprecated Features"] chapter of the QEMU System Emulation User's Guide for further detai...")
  • 15:09, 30 April 2025Planning/10.1 (hist | edit) ‎[901 bytes]DanielBerrange (talk | contribs) (Create 10.1 plan)
  • 15:53, 10 February 2025Internships/ProjectIdeas/RustVMMVhostUserMacOSBSD (hist | edit) ‎[3,670 bytes]Stefanha (talk | contribs) (Created page with "== vhost-user devices in Rust on macOS and *BSD == '''Expected outcome:''' Extend rust-vmm crates to support vhost-user devices running on POSIX system like macOS and *BSD. VIRTIO devices can be emulated in an external process to QEMU thanks to the vhost-user protocol, which allows QEMU to offload the entire emulation to a daemon. This is done through an AF_UNIX socket used as a control path between the frontend (i.e. QEMU) and the backend (i.e. the vhost-user daemon)....")
  • 15:59, 7 February 2025Internships/ProjectIdeas/HppaDevices (hist | edit) ‎[2,255 bytes]Stefanha (talk | contribs) (Created page with "== Implement LASI network card and/or NCR 710 SCSI controller device models == '''Summary:''' Develop device emulations of the HP PA-RISC LASI network card and/or NCR 710 SCSI controller QEMU can emulate a lot of physical machines. Beside widely used x86 machines as used with KVM, this includes historic machines based on PowerPC, Alpha or HP PA-RISC CPUs too. To emulate additional historic machine models, device models that emulate specific hardware like network or SCS...")
  • 13:36, 7 February 2025Internships/ProjectIdeas/VirtiofsdAio (hist | edit) ‎[2,171 bytes]Stefanha (talk | contribs) (Created page with "== Asynchronous request handling for virtiofsd == '''Summary:''' Make virtiofsd’s request handling asynchronous, allowing single-threaded parallel request processing. virtiofsd is a virtio-fs device implementation, i.e. grants VM guests access to host directories. In its current state, it processes guest requests one by one, which means operations of long duration will block processing of others that could be processed more quickly. With asynchronous request process...") originally created as "Internships/VirtiofsdAio"
  • 15:36, 6 February 2025Internships/ProjectIdeas/FUSEUringCmd (hist | edit) ‎[1,847 bytes]Stefanha (talk | contribs) (Created page with "== FUSE-over-io_uring == '''Summary:''' Extend QEMU's FUSE export type with FUSE-over-io_uring support FUSE-over-io_uring is a new high-performance interface for Filesystem in Userspace (FUSE) servers. The FUSE kernel code has added uring_cmd support so that FUSE servers can send and receive data directly over io_uring instead of reading/writing from/to the FUSE device. This reduces the number of system calls, as well as allowing for batching and polling, so that CPU o...")
  • 15:10, 6 February 2025Internships/ProjectIdeas/KaniProofsInRustVMM (hist | edit) ‎[2,684 bytes]Stefanha (talk | contribs) (Created page with "=== Adding Kani proofs for Virtqueues in Rust-vmm === '''Summary:''' Verify conformance of the virtqueue implementation in rust-vmm to the VirtIO specification. In the rust-vmm project, devices rely on the virtqueue implementation provided by the `vm-virtio` crate. This implementation is based on the VirtIO specification, which defines the behavior and requirements for virtqueues. To ensure that the implementation meets these specifications, we have been relying on uni...")