- Rust-vmm - lists.opendev.org

Fwd: October 2022 PTG Dates & Registration
by Kendall Nelson 05 Jul '22

05 Jul '22

Hello Everyone! As you may have seen, we announced the next PTG[1] which will take place October 17-20, 2022 in Columbus, Ohio! Registration is now open[2]. We have also secured a limited, discounted hotel block for PTG attendees [3]. If your organization is interested in sponsoring the event, information on packages and pricing are now available on the PTG website [1] or feel free to reach out directly to ptg(a)openinfra.dev. Can't wait to SEE you all there! -Kendall Nelson (diablo_rojo) … [View More]

1 0

Fwd: October PTG 2022 Team Signup
by Kendall Nelson 29 Jun '22

29 Jun '22

Hi Everyone, At the Berlin Summit, we announced the next PTG will be held from Monday, October 17th to Thursday, October 20th, 2022 in Columbus, OH! To signup your team, you must complete the survey[1] by August 12th at 7:00 UTC. We NEED accurate contact information for the moderator of your team’s sessions. This is because the survey information will be used to organize the schedule signups which will be done via the PTGBot. If you are not on IRC, please get setup[2] on the OFTC network and … [View More]

1 0

Licensing Issue in rust-vmm crates
by Florescu, Andreea 17 Jun '22

17 Jun '22

Hey folks, afaria(a)redhat.com<mailto:afaria@redhat.com> reported an issue [1] with the license of some of the rust-vmm crates. In our first rust-vmm meetup we decided the license for the crates to be BSD-3-Clause OR Apache 2.0 (as it's also specified in the meeting notes available here [2]), but when we did the implementation of the crate it looks like we wrote the license for some of the files and crates as "Apache-2.0 AND BSD-3-Clause" instead. This license is unfortunately … [View More]

1 0

2022 Grace Hopper Celebration Open Source Day - Call for Projects
by Open Source Day AnitaB GHC 08 Jun '22

08 Jun '22

*Hello,We're excited to announce that the 2022 Grace Hopper Celebration Open Source Day is open for projects <https://bit.ly/osd22-cfp>!Open Source Day (OSD) is an all-day hack-a-thon at Grace Hopper Celebration in which participants of all levels contribute and learn about Open Source while working on projects designed to solve real-world problems. OSD provides an opportunity for attendees of all skill levels and backgrounds to learn and experience open source contributions with the … [View More]

1 0

Moderation queue flushed
by Jeremy Stanley 01 Jun '22

01 Jun '22

Just a heads up that I flushed some several dozen messages which were waiting for a moderator to approve, so if you received a sudden flood of messages for the ML (some dating back to February), that's why. The majority were held because they were being sent from or cross-posted by people who aren't subscribed to this list, or because they had very large recipient lists (>10 addresses), or were over the default 40KB size limit. On a related note, if anyone is interested in helping check the … [View More]

2 1

Remaining Xen enabling work for rust-vmm
by Alex Bennée 23 May '22

23 May '22

Hi, This is one of several emails to follow up on Linaro's internal KWG sprint last week in Cambridge where a number of Project Stratos hackers discussed what next steps we have and started to think about future work. I am splitting the update into several emails so I can freely CC the relevant lists for each without too much cross-posting spam. Intro ===== We've made good progress over the last year and have up-streamed a number of device models as vhost-user daemons. We have also gotten … [View More]our first proof of concept build of the xen-vhost-master which has allowed us to reuse these backends on the Xen hypervisor. https://github.com/vireshk/xen-vhost-master Remaining Work ============== Scope out the remainder of APIs needed for oxerun ------------------------------------------------- The current xen-vhost-master uses a combination of the native rust oxerun and a bindgen import of libxensys (https://github.com/vireshk/libxen-sys) and a number of xen libraries built directly in the xen-vhost-master repository. Our intention for the Stratos work is to remove any C dependency for the rust backend and use native rust bindings to talk to the hypervisor control ioctl. Identifying what is needed should be easy enough as we can see where in master repository C calls are being made. This work should be broken down into groups in JIRA so the work can be efficiently divided up. Currently our focus for the rust-vmm repo is to support the vhost-user daemons but a wider conversation needs to be had with the community about the rest of the tooling involved in the creation and control of DomU guests. For Stratos we would like to explore the possibilities of bare metal monitor programs for dom0-less (or dom0-light?) setups. Strategy for testing oxerun in the rust-vmm project --------------------------------------------------- Currently the rust-vmm projects rely heavily on unit tests and a (mostly) x86 build farm. While building for non-x86 architectures isn't insurmountable doing blackbox testing on real hypervisors isn't currently supported. Given the low level nature of the interactions simply mocking the ioctl interface to the kernel will not likely sufficiently exercise things. We need a way to execute tests on a real system with a real Xen hypervisor and dom0 setup. We can either: - somehow add Xen hosts to the Buildkite runner pool for rust-vmm or - investigate using QEMU TCG as a portable system in a box to run Xen and guests Currently this is blocking wider up-streaming of the oxerun code to https://github.com/rust-vmm/xen-sys in the same way other rust-vmm repos work. See also ======== Other subjects discussed will be the subject of other emails today with different distribution lists. These are: - Remaining work for vhost-device - Additional virtio devices - Integrating rust-vmm with QEMU Happy reading ;-) -- Alex Bennée [View Less]

1 0

vhost-device outstanding tasks
by Alex Bennée 23 May '22

23 May '22

Hi, This is one of several emails to follow up on Linaro's internal KWG sprint last week in Cambridge where a number of Project Stratos hackers discussed what next steps we have and started to think about future work. I am splitting the update into several emails so I can freely CC the relevant lists for each without too much cross-posting spam. Intro ===== We've made good progress over the last year and have up-streamed a number of device models as vhost-user daemons. We have also gotten … [View More]our first proof of concept build of the xen-vhost-master which has allowed us to reuse these backends on the Xen hypervisor. Outstanding work ================ vm-virtio definitions --------------------- Given our vhost-user daemons were not re-implementing existing virtio device models a number of the queue handling definitions are in the vhost-device repository itself. As discussed before now we have these working we should migrate common definitions to the vm-virtio crate so in-VMM virtio emulation can re-use this code. Get outstanding vsock PR merged ------------------------------- We actually have two outstanding PR's against the vhost-device repository which implement virtio-vsock and virtio-scsi. They were done as GSoC projects but didn't get merged at the time due to lack of review. They currently have outstanding requests for code changes but due to the nature of GSoC it looks like the original authors don't have time to make the changes which is understandable given changes the repository has gone through over the last two years. I'm agnostic about virtio-scsi but given the usefulness of virtio-vsock it seems a shame to leave an implementation to wither on a branch. There has been some work on vm-virtio to improve the queue handling and with Andreea's help I have a branch that uses that. Should we just pick up the branch and finish the pull request process? Sort out an official vhost-master repository in rust-vmm -------------------------------------------------------- The rust-vmm project has the vhost-user-backend which implements the core backend behaviour for handling vhost-user messages. There is also an abstraction for vhost (user and kernel handling) from the VMM side in the vhost repository. However it doesn't provide everything needed to implement a full vhost-master. Currently Viresh is using: https://github.com/vireshk/vhost-user-master is the xen-vhost-master project which is constructed from the in-VMM vhost-master bits from Cloud Hypervisor. We should get this properly up-streamed into the rust-vmm project. Should this be merged into the existing rust-vmm/vhost repository or does it require it's own repository? Properly document and support cross-compilation ----------------------------------------------- Currently most of our testing is on Arm systems and currently we are either: - hacking up the local repo for cross-compilation or - doing a "native" build in an QEMU emulated Aarch64 system the second option is potentially quite slow, at least for the first build. Given building backends for non-x86 systems is core to Linaro's goals we should properly support cross compilation for the vhost-device repository and document it. This should be also be enabled in the CI to ensure the configuration doesn't bitrot. See Also ======== Other subjects discussed will be the subject of other emails today with different distribution lists. These are: - Xen specific enabling work - Additional virtio devices - Integrating rust-vmm with QEMU Happy reading ;-) -- Alex Bennée [View Less]

1 0

CFP Reminder: KVM Forum 2022
by Peter Maydell 18 May '22

18 May '22

================================================================ KVM Forum 2022 September 12-14, 2022 Dublin, Ireland & Virtual All submissions must be received before *** Friday June 3rd, 2022 at 23:59 PDT *** ================================================================ KVM Forum is an annual event that presents a rare opportunity for developers and users to discuss the state of Linux virtualization technology and plan for the challenges ahead. This highly technical conference … [View More]

1 0

Re: [Rust-VMM] Virtio on Xen with Rust
by Viresh Kumar 19 Apr '22

19 Apr '22

+rust-vmm(a)lists.opendev.org On Thu, 14 Apr 2022 at 14:54, Viresh Kumar <viresh.kumar(a)linaro.org> wrote: > > +xen-devel > > On 14-04-22, 14:45, Viresh Kumar wrote: > > Hello, > > > > We verified our hypervisor-agnostic Rust based vhost-user backends with Qemu > > based setup earlier, and there was growing concern if they were truly > > hypervisor-agnostic. > > > > In order to prove that, we decided to give it a try with Xen, a type-… [View More]1 > > bare-metal hypervisor. > > > > We are happy to announce that we were able to make progress on that front and > > have a working setup where we can test our existing Rust based backends, like > > I2C, GPIO, RNG (though only I2C is tested as of now) over Xen. > > > > Key components: > > -------------- > > > > - Xen: https://github.com/vireshk/xen > > > > Xen requires MMIO and device specific support in order to populate the > > required devices at the guest. This tree contains four patches on the top of > > mainline Xen, two from Oleksandr (mmio/disk) and two from me (I2C). > > > > - libxen-sys: https://github.com/vireshk/libxen-sys > > > > We currently depend on the userspace tools/libraries provided by Xen, like > > xendevicemodel, xenevtchn, xenforeignmemory, etc. This crates provides Rust > > wrappers over those calls, generated automatically with help of bindgen > > utility in Rust, that allow us to use the installed Xen libraries. Though we > > plan to replace this with Rust based "oxerun" (find below) in longer run. > > > > - oxerun (WIP): https://gitlab.com/mathieupoirier/oxerun/-/tree/xen-ioctls > > > > This is Rust based implementations for Ioctl and hypercalls to Xen. This is WIP > > and should eventually replace "libxen-sys" crate entirely (which are C based > > implementation of the same). > > > > - vhost-device: https://github.com/vireshk/vhost-device > > > > These are Rust based vhost-user backends, maintained inside the rust-vmm > > project. This already contain support for I2C and RNG, while GPIO is under > > review. These are not required to be modified based on hypervisor and are > > truly hypervisor-agnostic. > > > > Ideally the backends are hypervisor agnostic, as explained earlier, but > > because of the way Xen maps the guest memory currently, we need a minor update > > for the backends to work. Xen maps the memory via a kernel file > > /dev/xen/privcmd, which needs calls to mmap() followed by an ioctl() to make > > it work. For this a hack has been added to one of the rust-vmm crates, > > vm-virtio, which is used by vhost-user. > > > > https://github.com/vireshk/vm-memory/commit/54b56c4dd7293428edbd7731c4dbe57… > > > > The update to vm-memory is responsible to do ioctl() after the already present > > mmap(). > > > > - vhost-user-master (WIP): https://github.com/vireshk/vhost-user-master > > > > This implements the master side interface of the vhost protocol, and is like > > the vhost-user-backend (https://github.com/rust-vmm/vhost-user-backend) crate > > maintained inside the rust-vmm project, which provides similar infrastructure > > for the backends to use. This shall be hypervisor independent and provide APIs > > for the hypervisor specific implementations. This will eventually be > > maintained inside the rust-vmm project and used by all Rust based hypervisors. > > > > - xen-vhost-master (WIP): https://github.com/vireshk/xen-vhost-master > > > > This is the Xen specific implementation and uses the APIs provided by > > "vhost-user-master", "oxerun" and "libxen-sys" crates for its functioning. > > > > This is designed based on the EPAM's "virtio-disk" repository > > (https://github.com/xen-troops/virtio-disk/) and is pretty much similar to it. > > > > One can see the analogy as: > > > > Virtio-disk == "Xen-vhost-master" + "vhost-user-master" + "oxerun" + "libxen-sys" + "vhost-device". > > > > > > > > Test setup: > > ---------- > > > > 1. Build Xen: > > > > $ ./configure --libdir=/usr/lib --build=x86_64-unknown-linux-gnu --host=aarch64-linux-gnu --disable-docs --disable-golang --disable-ocamltools --with-system-qemu=/root/qemu/build/i386-softmmu/qemu-system-i386; > > $ make -j9 debball CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64 > > > > 2. Run Xen via Qemu on X86 machine: > > > > $ qemu-system-aarch64 -machine virt,virtualization=on -cpu cortex-a57 -serial mon:stdio \ > > -device virtio-net-pci,netdev=net0 -netdev user,id=net0,hostfwd=tcp::8022-:22 \ > > -device virtio-scsi-pci -drive file=/home/vireshk/virtio/debian-bullseye-arm64.qcow2,index=0,id=hd0,if=none,format=qcow2 -device scsi-hd,drive=hd0 \ > > -display none -m 8192 -smp 8 -kernel /home/vireshk/virtio/xen/xen \ > > -append "dom0_mem=5G,max:5G dom0_max_vcpus=7 loglvl=all guest_loglvl=all" \ > > -device guest-loader,addr=0x46000000,kernel=/home/vireshk/kernel/barm64/arch/arm64/boot/Image,bootargs="root=/dev/sda2 console=hvc0 earlyprintk=xen" \ > > -device ds1338,address=0x20 # This is required to create a virtual I2C based RTC device on Dom0. > > > > This should get Dom0 up and running. > > > > 3. Build rust crates: > > > > $ cd /root/ > > $ git clone https://github.com/vireshk/xen-vhost-master > > $ cd xen-vhost-master > > $ cargo build > > > > $ cd ../ > > $ git clone https://github.com/vireshk/vhost-device > > $ cd vhost-device > > $ cargo build > > > > 4. Setup I2C based RTC device > > > > $ echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device; echo 0-0020 > /sys/bus/i2c/devices/0-0020/driver/unbind > > > > 5. Lets run everything now > > > > # Start the I2C backend in one terminal (open new terminal with "ssh > > # root@localhost -p8022"). This tells the I2C backend to hook up to > > # "/root/vi2c.sock0" socket and wait for the master to start transacting. > > $ /root/vhost-device/target/debug/vhost-device-i2c -s /root/vi2c.sock -c 1 -l 0:32 > > > > # Start the xen-vhost-master in another terminal. This provides the path of > > # the socket to the master side and the device to look from Xen, which is I2C > > # here. > > $ /root/xen-vhost-master/target/debug/xen-vhost-master --socket-path /root/vi2c.sock0 --name i2c > > > > # Start guest in another terminal, i2c_domu.conf is attached. The guest kernel > > # should have Virtio related config options enabled, along with i2c-virtio > > # driver. > > $ xl create -c i2c_domu.conf > > > > # The guest should boot fine now. Once the guest is up, you can create the I2C > > # RTC device and use it. Following will create /dev/rtc0 in the guest, which > > # you can configure with 'hwclock' utility. > > > > $ echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device > > > > > > Hope this helps. > > > > -- > > viresh > > i2c_domu.conf > > > kernel="/root/Image" > > memory=512 > > vcpus=2 > > command="console=hvc0 earlycon=xenboot" > > name="domu" > > i2c = [ "virtio=true, irq=1, base=1" ] > > -- > viresh [View Less]

1 0

Xen Rust VirtIO demos work breakdown for Project Stratos
by Alex Bennée 15 Apr '22

15 Apr '22

Hi, The following is a breakdown (as best I can figure) of the work needed to demonstrate VirtIO backends in Rust on the Xen hypervisor. It requires work across a number of projects but notably core rust and virtio enabling in the Xen project (building on the work EPAM has already done) and the start of enabling rust-vmm crate to work with Xen. The first demo is a fairly simple toy to exercise the direct hypercall approach for a unikernel backend. On it's own it isn't super impressive but … [View More]hopefully serves as a proof of concept for the idea of having backends running in a single exception level where latency will be important. The second is a much more ambitious bridge between Xen and vhost-user to allow for re-use of the existing vhost-user backends with the bridge acting as a proxy for what would usually be a full VMM in the type-2 hypervisor case. With that in mind the rust-vmm work is only aimed at doing the device emulation and doesn't address the larger question of how type-1 hypervisors can be integrated into the rust-vmm hypervisor model. A quick note about the estimates. They are exceedingly rough guesses plucked out of the air and I would be grateful for feedback from the appropriate domain experts on if I'm being overly optimistic or pessimistic. The links to the Stratos JIRA should be at least read accessible to all although they contain the same information as the attached document (albeit with nicer PNG renderings of my ASCII art ;-). There is a Stratos sync-up call next Thursday: https://calendar.google.com/event?action=TEMPLATE&tmeid=MWpidm5lbzM5NjlydnA… and I'm sure there will also be discussion in the various projects (hence the wide CC list). The Stratos calls are open to anyone who wants to attend and we welcome feedback from all who are interested. So on with the work breakdown: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ STRATOS PLANNING FOR 21 TO 22 Alex Bennée ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents ───────────────── 1. Xen Rust Bindings ([STR-51]) .. 1. Upstream an "official" rust crate for Xen ([STR-52]) .. 2. Basic Hypervisor Interactions hypercalls ([STR-53]) .. 3. [#10] Access to XenStore service ([STR-54]) .. 4. VirtIO support hypercalls ([STR-55]) 2. Xen Hypervisor Support for Stratos ([STR-56]) .. 1. Stable ABI for foreignmemory mapping to non-dom0 ([STR-57]) .. 2. Tweaks to tooling to launch VirtIO guests 3. rust-vmm support for Xen VirtIO ([STR-59]) .. 1. Make vm-memory Xen aware ([STR-60]) .. 2. Xen IO notification and IRQ injections ([STR-61]) 4. Stratos Demos .. 1. Rust based stubdomain monitor ([STR-62]) .. 2. Xen aware vhost-user master ([STR-63]) 1 Xen Rust Bindings ([STR-51]) ══════════════════════════════ There exists a [placeholder repository] with the start of a set of x86_64 bindings for Xen and a very basic hello world uni-kernel example. This forms the basis of the initial Xen Rust work and will be available as a [xen-sys crate] via cargo. [STR-51] <https://linaro.atlassian.net/browse/STR-51> [placeholder repository] <https://gitlab.com/cardoe/oxerun.git> [xen-sys crate] <https://crates.io/crates/xen-sys> 1.1 Upstream an "official" rust crate for Xen ([STR-52]) ──────────────────────────────────────────────────────── To start with we will want an upstream location for future work to be based upon. The intention is the crate is independent of the version of Xen it runs on (above the baseline version chosen). This will entail: • ☐ agreeing with upstream the name/location for the source • ☐ documenting the rules for the "stable" hypercall ABI • ☐ establish an internal interface to elide between ioctl mediated and direct hypercalls • ☐ ensure the crate is multi-arch and has feature parity for arm64 As such we expect the implementation to be standalone, i.e. not wrapping the existing Xen libraries for mediation. There should be a close (1-to-1) mapping between the interfaces in the crate and the eventual hypercall made to the hypervisor. Estimate: 4w (elapsed likely longer due to discussion) [STR-52] <https://linaro.atlassian.net/browse/STR-52> 1.2 Basic Hypervisor Interactions hypercalls ([STR-53]) ─────────────────────────────────────────────────────── These are the bare minimum hypercalls implemented as both ioctl and direct calls. These allow for a very basic binary to: • ☐ console_io - output IO via the Xen console • ☐ domctl stub - basic stub for domain control (different API?) • ☐ sysctl stub - basic stub for system control (different API?) The idea would be this provides enough hypercall interface to query the list of domains and output their status via the xen console. There is an open question about if the domctl and sysctl hypercalls are way to go. Estimate: 6w [STR-53] <https://linaro.atlassian.net/browse/STR-53> 1.3 [#10] Access to XenStore service ([STR-54]) ─────────────────────────────────────────────── This is a shared configuration storage space accessed via either Unix sockets (on dom0) or via the Xenbus. This is used to access configuration information for the domain. Is this needed for a backend though? Can everything just be passed direct on the command line? Estimate: 4w [STR-54] <https://linaro.atlassian.net/browse/STR-54> 1.4 VirtIO support hypercalls ([STR-55]) ──────────────────────────────────────── These are the hypercalls that need to be implemented to support a VirtIO backend. This includes the ability to map another guests memory into the current domains address space, register to receive IOREQ events when the guest knocks at the doorbell and inject kicks into the guest. The hypercalls we need to support would be: • ☐ dmop - device model ops (*_ioreq_server, setirq, nr_vpus) • ☐ foreignmemory - map and unmap guest memory The DMOP space is larger than what we need for an IOREQ backend so I've based it just on what arch/arm/dm.c exports which is the subset introduced for EPAM's virtio work. Estimate: 12w [STR-55] <https://linaro.atlassian.net/browse/STR-55> 2 Xen Hypervisor Support for Stratos ([STR-56]) ═══════════════════════════════════════════════ These tasks include tasks needed to support the various different deployments of Stratos components in Xen. [STR-56] <https://linaro.atlassian.net/browse/STR-56> 2.1 Stable ABI for foreignmemory mapping to non-dom0 ([STR-57]) ─────────────────────────────────────────────────────────────── Currently the foreign memory mapping support only works for dom0 due to reference counting issues. If we are to support backends running in their own domains this will need to get fixed. Estimate: 8w [STR-57] <https://linaro.atlassian.net/browse/STR-57> 2.2 Tweaks to tooling to launch VirtIO guests ───────────────────────────────────────────── There might not be too much to do here. The EPAM work already did something similar for their PoC for virtio-block. Essentially we need to ensure: • ☐ DT bindings are passed to the guest for virtio-mmio device discovery • ☐ Our rust backend can be instantiated before the domU is launched This currently assumes the tools and the backend are running in dom0. Estimate: 4w 3 rust-vmm support for Xen VirtIO ([STR-59]) ════════════════════════════════════════════ This encompasses the tasks required to get a vhost-user server up and running while interfacing to the Xen hypervisor. This will require the xen-sys.rs crate for the actual interface to the hypervisor. We need to work out how a Xen configuration option would be passed to the various bits of rust-vmm when something is being built. [STR-59] <https://linaro.atlassian.net/browse/STR-59> 3.1 Make vm-memory Xen aware ([STR-60]) ─────────────────────────────────────── The vm-memory crate is the root crate for abstracting access to the guests memory. It currently has multiple configuration builds to handle difference between mmap on Windows and Unix. Although mmap isn't directly exposed the public interfaces support a mmap like interface. We would need to: • ☐ work out how to expose foreign memory via the vm-memory mechanism I'm not sure if this just means implementing the GuestMemory trait for a GuestMemoryXen or if we need to present a mmap like interface. Estimate: 8w [STR-60] <https://linaro.atlassian.net/browse/STR-60> 3.2 Xen IO notification and IRQ injections ([STR-61]) ───────────────────────────────────────────────────── The KVM world provides for ioeventfd (notifications) and irqfd (injection) to signal asynchronously between the guest and the backend. As far a I can tell this is currently handled inside the various VMMs which assume a KVM backend. While the vhost-user slave code doesn't see the register_ioevent/register_irqfd events it does deal with EventFDs throughout the code. Perhaps the best approach here would be to create a IOREQ crate that can create EventFD descriptors which can then be passed to the slaves to use for notification and injection. Otherwise there might be an argument for a new crate that can encapsulate this behaviour for both KVM/ioeventd and Xen/IOREQ setups? Estimate: 8w? [STR-61] <https://linaro.atlassian.net/browse/STR-61> 4 Stratos Demos ═══════════════ These tasks cover the creation of demos that brig together all the previous bits of work to demonstrate a new area of capability that has been opened up by Stratos work. 4.1 Rust based stubdomain monitor ([STR-62]) ──────────────────────────────────────────── This is a basic demo that is a proof of concept for a unikernel style backend written in pure Rust. This work would be a useful precursor for things such as the RTOS Dom0 on a safety island ([STR-11]) or as a carrier for the virtio-scmi backend. The monitor program will periodically poll the state of the other domains and echo their status to the Xen console. Estimate: 4w #+name: stub-domain-example #+begin_src ditaa :cmdline -o :file stub_domain_example.png Dom0 | DomU | DomStub | | : /-------------\ : | |cPNK | | | | | | | | | | /------------------------------------\ | | GuestOS | | |cPNK | | | | | EL0 | Dom0 Userspace (xl tools, QEMU) | | | | | /---------------\ | | | | | | |cYEL | \------------------------------------/ | | | | | | +------------------------------------+ | | | | | Rust Monitor | EL1 |cA1B Dom0 Kernel | | | | | | | +------------------------------------+ | \-------------/ | \---------------/ -------------------------------------------------------------------------------=------------------ +-------------------------------------------------------------------------------------+ EL2 |cC02 Xen Hypervisor | +-------------------------------------------------------------------------------------+ #+end_src [STR-62] <https://linaro.atlassian.net/browse/STR-62> [STR-11] <https://linaro.atlassian.net/browse/STR-11> 4.2 Xen aware vhost-user master ([STR-63]) ────────────────────────────────────────── Usually the master side of a vhost-user system is embedded directly in the VMM itself. However in a Xen deployment their is no overarching VMM but a series of utility programs that query the hypervisor directly. The Xen tooling is also responsible for setting up any support processes that are responsible for emulating HW for the guest. The task aims to bridge the gap between Xen's normal HW emulation path (ioreq) and VirtIO's userspace device emulation (vhost-user). The process would be started with some information on where the virtio-mmio address space is and what the slave binary will be. It will then: • map the guest into Dom0 userspace and attach to a MemFD • register the appropriate memory regions as IOREQ regions with Xen • create EventFD channels for the virtio kick notifications (one each way) • spawn the vhost-user slave process and mediate the notifications and kicks between the slave and Xen itself #+name: xen-vhost-user-master #+begin_src ditaa :cmdline -o :file xen_vhost_user_master.png Dom0 DomU | | | | | | +-------------------+ +-------------------+ | | |----------->| | | | vhost-user | vhost-user | vhost-user | : /------------------------------------\ | slave | protocol | master | | | | | (existing) |<-----------| (rust) | | | | +-------------------+ +-------------------+ | | | ^ ^ | ^ | | Guest Userspace | | | | | | | | | | | IOREQ | | | | | | | | | | | v v V | | \------------------------------------/ +---------------------------------------------------+ | +------------------------------------+ | ^ ^ | ioctl ^ | | | | | | iofd/irqfd eventFD | | | | | | Guest Kernel | | +---------------------------+ | | | | | +-------------+ | | | | | | | | virtio-dev | | | Host Kernel V | | | | +-------------+ | +---------------------------------------------------+ | +------------------------------------+ | ^ | | ^ | hyper | | | ----------------------=------------- | -=--- | ----=------ | -----=- | --------=------------------ | call | Trap | | IRQ V | V | +-------------------------------------------------------------------------------------+ | | ^ | ^ | | | +-------------+ | | EL2 | Xen Hypervisor | | | | +-------------------------------+ | | | +-------------------------------------------------------------------------------------+ #+end_src [STR-63] <https://linaro.atlassian.net/browse/STR-63> -- Alex Bennée [View Less]

8 15

Call for GSoC and Outreachy project ideas for summer 2022
by Stefan Hajnoczi 29 Mar '22

29 Mar '22

Dear QEMU, KVM, and rust-vmm communities, QEMU will apply for Google Summer of Code 2022 (https://summerofcode.withgoogle.com/) and has been accepted into Outreachy May-August 2022 (https://www.outreachy.org/) You can now submit internship project ideas for QEMU, KVM, and rust-vmm! If you have experience contributing to QEMU, KVM, or rust-vmm you can be a mentor. It's a great way to give back and you get to work with people who are just starting out in open source. Please reply to this email … [View More]

11 28

Fwd: Forum Submissions Open for Berlin Summit 2022!
by Kendall Nelson 21 Mar '22

21 Mar '22

Hello Everyone! We are now accepting Forum [1] submissions for the 2022 Open Infrastructure Summit Forum [2]. Please submit your ideas through the Summit CFP tool [3] through April 8th. Don't forget to put your brainstorming etherpad up on the Berlin Forum page [4]. This is not a classic conference track with speakers and presentations. OpenInfra community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they … [View More]

1 1

Fwd: Reminder! PTG April 2022 Team Signup Deadline
by Kendall Nelson 07 Mar '22

07 Mar '22

Hello Everyone, Don't forget to sign your team up for the next Project Teams Gathering (PTG), which will be held virtually from Monday, April 4 to Friday, April 8, 2022! If you haven't already done so and your team is interested in participating, please complete BOTH the survey[1] AND reserve time in the ethercalc[2] by end of day March 11. Then make sure to register[3] for the PTG because that's how you'll receive event details, passwords, and other relevant information about the PTG. … [View More]

1 0

PTG April 2022 Team Signup
by Kendall Nelson 03 Feb '22

03 Feb '22

Hello! Last week, we announced the next virtual PTG will be held virtually from Monday, April 4th to Friday, April 8th, 2022. We will have the same schedule set up available as last time with three windows of time spread across the day to cover all timezones with breaks in between. To signup your team, you must complete BOTH the survey[1] AND reserve time in the ethercalc[2] by end of day March 11th. We ask that the PTL/SIG Chair/Team lead sign up for time to have their discussions with 3 … [View More]

1 0

Re: [Rust-VMM] rust-vmm sync meeting
by Florescu, Andreea 25 Nov '21

25 Nov '21

?Hey folks, I will not be able to join the meeting on Monday. Can someone else be the MC (and pls take meeting notes)? Thanks, Andreea ________________________________ From: Florescu, Andreea Sent: Wednesday, March 3, 2021 3:21 PM To: Loghin, Laura; Ochescu, Catalin; Iordache, Alexandra; Agache, Alexandru; meet(a)chime.aws; pin+6592165432(a)chime.aws; rust-vmm(a)lists.opendev.org; liuwe(a)microsoft.com; slp(a)redhat.com; samuel.e.ortiz(a)protonmail.com; alex.bennee(a)linaro.org; Cihodaru, … [View More]Alexandru-Ciprian; Berciu, Liviu-Marian; Sardan, Alexandru-cezar; gsserge(a)amazon.nl Cc: Catangiu, Adrian Costin; M. Dodson; Ceyhun Ertürk; eli(a)patch.sh; Zach Reizner; Popa, Diana-Maria; Wise, Bob; luka.perkov(a)sartura.hr; Brendan Burns; Gowdar, Meena; borna.blazevic(a)sartura.hr; Boeuf, Sebastien; Liguori, Anthony; Dima, Alin; Sandu, Andrei; liuj97(a)gmail.com; Iliescu, Radu; bogdangrigoruta(a)gmail.com; misla011(a)fiu.edu; Muminul Islam; Voicu, Luminita; Liang Yan; Meyerhans, Noah; Lucian Petrut; Eftime, Petre; Stanciu, Adrian Subject: rust-vmm sync meeting When: Monday, November 29, 2021 6:00 PM-7:00 PM. Where: Update: refreshing the series. Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.aws/6592165432 Join via phone (US): +1-929-432-4463,,,6592165432#<tel:+1-929-432-4463,,,6592165432#> Join via phone (US toll-free): +1-855-552-4463,,,6592165432#<tel:+1-855-552-4463,,,6592165432#> International dial-in: https://chime.aws/dialinnumbers/ In-room video system: Ext: 62000, Meeting PIN: 6592165432# ================================================= ================Before your meeting:================ * Learn how to use the touch panel<https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>. * Prefer a video? Watch these touch panel how-to videos<https://broadcast.amazon.com/videos/98363>. * Find out more about room layouts<https://it.amazon.com/en/help/articles/conference-room-configurations>. * Get more information at it.amazon.com/meetings<https://it.amazon.com/en/servicecatalog/meetings>. ================================================ Created with Amazon Meetings<https://meetings.amazon.com> (fandree@, edit this series<https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777589627-fa…>) Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. [View Less]

1 0

rust-vmm sync meeting
by Florescu, Andreea 04 Oct '21

04 Oct '21

Update: refreshing the series. Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via … [View More]

1 0

rust-vmm sync meeting
by Florescu, Andreea 27 Sep '21

27 Sep '21

Update: refreshing the series. Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via … [View More]

1 0

Is it time to start implementing Xen bindings for rust-vmm?
by Alex Bennée 22 Sep '21

22 Sep '21

Hi, As we consider the next cycle for Project Stratos I would like to make some more progress on hypervisor agnosticism for our virtio backends. While we have implemented a number of virtio vhost-user backends using C we've rapidly switched to using rust-vmm based ones for virtio-i2c, virtio-rng and virtio-gpio. Given the interest in Rust for implementing backends does it make sense to do some enabling work in rust-vmm to support Xen? There are two chunks of work I can think of: 1. Enough … [View More]of libxl/hypervisor interface to implement an IOREQ end point. This would require supporting enough of the hypervisor interface to support the implementation of an IOREQ server. We would also need to think about how we would map the IOREQ view of the world into the existing vhost-user interface so we can re-use the current vhost-user backends code base. The two approaches I can think of are: a) implement a vhost-user master that speaks IOREQ to the hypervisor and vhost-user to the vhost-user slave. In this case the bridge would be standing in for something like QEMU. b) implement some variants of the vhost-user slave traits that can talk directly to the hypervisor to get/send the equivalent kick/notify events. I don't know if this might be too complex as the impedance matching between the two interfaces might be too great. This assumes most of the setup is done by the existing toolstack, so the existing libxl tools are used to create, connect and configure the domains before the backend is launched. which leads to: 2. The rest of the libxl/hypervisor interface. This would be the rest of the interface to allow rust-vmm tools to be written that could create, configure and manage Xen domains with pure rust tools. My main concern about this is how rust-vmm's current model (which is very much KVM influenced) will be able to handle the differences for a type-1 hypervisor. Wei's pointed me to the Linux support that was added to expose a Hyper-V control interface via the Linux kernel. While I can see support has been merged on other rust based projects I think the rust-vmm crate is still outstanding: https://github.com/rust-vmm/community/issues/50 and I guess this would need revisiting for Xen to see if the proposed abstraction would scale across other hypervisors. Finally there is the question of how/if any of this would relate to the concept of bare-metal rust backends? We've talked about bare metal backends before but I wonder if the programming model for them is going to be outside the scope of rust-vmm? Would be program just be hardwired to IRQs and be presented a doorbell port to kick or would we want to have at least some of the higher level rust-vmm abstractions for dealing with navigating the virtqueues and responding and filling in data? Thoughts? -- Alex Bennée [View Less]

4 6

rust-vmm sync meeting
by Florescu, Andreea 22 Sep '21

22 Sep '21

Update: refreshing the series. Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via … [View More]

1 0

Fw: vm-virtio: discuss next steps
by Florescu, Andreea 10 Sep '21

10 Sep '21

FYI. We discussed on Slack about publishing the queue implementation. In this meeting we plan to see what are some appropriate next steps. ________________________________ From: Florescu, Andreea Sent: Friday, September 10, 2021 2:01 PM To: Agache, Alexandru; Loghin, Laura; meet(a)chime.aws; pin+8949618186(a)chime.aws; slp(a)redhat.com; liuj97(a)gmail.com Cc: Dumitru, Catalin-andrei Subject: vm-virtio: discuss next steps When: Monday, September 13, 2021 4:30 PM-5:30 PM. Where: I'm … [View More]

1 0

Reduce OPS Load on Maintaining Repos
by Florescu, Andreea 07 Sep '21

07 Sep '21

Hey folks, We discussed at the sync meeting about the high operational load that we currently have, and the main root cause. One of the pain points is that we have many repositories we need to maintain, which need regular CI updates. There is also an associated cost with merging dependabot PRs. We want to improve the load by working on 3 areas: - [DONE] archive unused repositories; repositories that do not yet have useful code are now archived; repositories to which this applies: io-rate-… [View More]

1 0

rust-vmm sync meeting
by Florescu, Andreea 07 Sep '21

07 Sep '21

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.… [View More]

1 0

Branch rename
by Florescu, Andreea 02 Sep '21

02 Sep '21

Hey everyone, We just completed an effort of renaming the master branch to main for all rust-vmm repositories. This topic was discussed during the last rust-vmm sync meeting as well. Then we decided that we'll mark the master branch as deprecated, and add a new branch called main so we don't break customers that are consuming the master branch [1]. We reverted this decision as we got new input from Rob, letting us know that GitHub provides a redirect from master to main. This simplified the … [View More]

1 0

Canceled: rust-vmm sync meeting
by Florescu, Andreea 21 Jul '21

21 Jul '21

Cancelling this meeting as we'll have all meeting in the European evening (by popular demand). I'll shortly send an update for the other meeting series to update it to every 2-weeks. Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 2352511775 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter … [View More]

1 0

Canceled: rust-vmm sync meeting
by Florescu, Andreea 21 Jul '21

21 Jul '21

? Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.

1 0

Canceled: rust-vmm sync meeting
by Florescu, Andreea 21 Jul '21

21 Jul '21

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.aws/… [View More]

1 0

Canceled: rust-vmm sync meeting
by Florescu, Andreea 21 Jul '21

21 Jul '21

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.… [View More]

1 0

rust-vmm sync meeting
by Florescu, Andreea 21 Jul '21

21 Jul '21

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.… [View More]

1 0

rust-vmm sync meeting
by Florescu, Andreea 21 Jul '21

21 Jul '21

Cancelling this meeting as we'll have all meeting in the European evening (by popular demand). I'll shortly send an update for the other meeting series to update it to every 2-weeks. Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 2352511775 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter … [View More]

1 0

rust-vmm sync meeting
by Florescu, Andreea 21 Jul '21

21 Jul '21

Cancelling this meeting as we'll have all meeting in the European evening (by popular demand). I'll shortly send an update for the other meeting series to update it to every 2-weeks. Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 2352511775 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter … [View More]

1 0

rust-vmm sync meetings
by Florescu, Andreea 05 Jul '21

05 Jul '21

?Hey everyone, In the last sync meeting Sebastien (in CC) proposed to move all occurrences of the rust-vmm meeting at the same hour. He proposed we use the US friendly time as it has more attendees, and having meetings at irregular times is confusing. [Context: the rust-vmm sync meetings occur every 2 weeks on Monday, with one meeting at an European-friendly hour (11:00 AM to 12:00 PM EEST), and one at an US-friendly hour (6:00 PM to 7:00 PM EEST)]. I wanted to check with you what do you … [View More]

1 0

rust-vmm sync meeting
by Florescu, Andreea 26 May '21

26 May '21

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.aws/… [View More]

1 0

rust-vmm sync meeting
by Florescu, Andreea 26 May '21

26 May '21

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 2352511775 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 2352511775 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.aws/… [View More]

1 0

rust-vmm sync meetings
by Florescu, Andreea 26 May '21

26 May '21

Hey, We had a few new subscribers to the rust-vmm email list recently. In case you want to attend the rust-vmm sync meeting, and do not have it in the calendar, let me know by dropping me and email and I'll just forward you the meeting invites.? ? Samuel and I added a few details about the meetings in the notes as well, but it might be hard to digest: https://etherpad.opendev.org/p/rust-vmm-sync-2021 Thanks, Andreea Amazon Development Center (Romania) S.R.L. registered office: 27A Sf.… [View More]

1 0

[RUST] Add crate for generic vhost-user-i2c backend daemon
by Viresh Kumar 20 May '21

20 May '21

Hello, In my earlier attempt [1], I implemented the vhost-user-i2c backend deamon for QEMU (though the code was generic enough to be used with any hypervisor). And here is a Rust implementation of the vhost-user-i2c backend daemon. Again this is generic enough to be used with any hypervisor and can live in its own repository now: https://github.com/vireshk/vhost-user-i2c I am not sure what's the process to get this merged to Rust-vmm. Can someone help ? Is that the right thing to do ? ---… [View More]----------------------8<------------------------- Here are other details (which are same since the earlier Qemu attempt): This is an initial implementation of a generic vhost-user backend for the I2C bus. This is based of the virtio specifications (already merged) for the I2C bus. The kernel virtio I2C driver is still under review, here [2] is the latest version (v10): The backend is implemented as a vhost-user device because we want to experiment in making portable backends that can be used with multiple hypervisors. We also want to support backends isolated in their own separate service VMs with limited memory cross-sections with the principle guest. This is part of a wider initiative by Linaro called "project Stratos" for which you can find information here: https://collaborate.linaro.org/display/STR/Stratos+Home I2C Testing: ------------ I didn't have access to a real hardware where I can play with a I2C client device (like RTC, eeprom, etc) to verify the working of the backend daemon, so I decided to test it on my x86 box itself with hierarchy of two ARM64 guests. The first ARM64 guest was passed "-device ds1338,address=0x20" option, so it could emulate a ds1338 RTC device, which connects to an I2C bus. Once the guest came up, ds1338 device instance was created within the guest kernel by doing: echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device [ Note that this may end up binding the ds1338 device to its driver, which won't let our i2c daemon talk to the device. For that we need to manually unbind the device from the driver: echo 0-0020 > /sys/bus/i2c/devices/0-0020/driver/unbind ] After this is done, you will get /dev/rtc1. This is the device we wanted to emulate, which will be accessed by the vhost-user-i2c backend daemon via the /dev/i2c-0 file present in the guest VM. At this point we need to start the backend daemon and give it a socket-path to talk to from qemu (you can pass -v to it to get more detailed messages): target/debug/vhost-user-i2c --socket-path=vi2c.sock -l 0:32 [ Here, 0:32 is the bus/device mapping, 0 for /dev/i2c-0 and 32 (i.e. 0x20) is client address of ds1338 that we used while creating the device. ] Now we need to start the second level ARM64 guest (from within the first guest) to get the i2c-virtio.c Linux driver up. The second level guest is passed the following options to connect to the same socket: -chardev socket,path=vi2c.sock,id=vi2c \ -device vhost-user-i2c-pci,chardev=vi2c,id=i2c Once the second level guest boots up, we will see the i2c-virtio bus at /sys/bus/i2c/devices/i2c-X/. From there we can now make it emulate the ds1338 device again by doing: echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device [ This time we want ds1338's driver to be bound to the device, so it should be enabled in the kernel as well. ] And we will get /dev/rtc1 device again here in the second level guest. Now we can play with the rtc device with help of hwclock utility and we can see the following sequence of transfers happening if we try to update rtc's time from system time. hwclock -w -f /dev/rtc1 (in guest2) -> Reaches i2c-virtio.c (Linux bus driver in guest2) -> transfer over virtio -> Reaches the qemu's vhost-i2c device emulation (running over guest1) -> Reaches the backend daemon vhost-user-i2c started earlier (in guest1) -> ioctl(/dev/i2c-0, I2C_RDWR, ..); (in guest1) -> reaches qemu's hw/rtc/ds1338.c (running over host) SMBUS Testing: -------------- I wasn't required to have such a tedious setup for testing out with SMBUS devices. I was able to emulate a SMBUS device on my x86 machine using i2c-stub driver. $ modprobe i2c-stub chip_addr=0x20 //Boot the arm64 guest now with i2c-virtio driver and then do: $ echo al3320a 0x20 > /sys/class/i2c-adapter/i2c-0/new_device $ cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw That's it. I hope I was able to give a clear picture of my test setup here :) -- viresh [1] https://lore.kernel.org/qemu-devel/cover.1617278395.git.viresh.kumar@linaro… [2] https://lore.kernel.org/lkml/226a8d5663b7bb6f5d06ede7701eedb18d1bafa1.16164… [View Less]

2 6

Support for additional hypervisors
by Srivatsa Vaddagiri 19 May '21

19 May '21

I noticed some discussions on supporting hypervisors other than KVM. https://github.com/rust-vmm/community/issues/50 https://github.com/cloud-hypervisor/cloud-hypervisor/pull/1225 Is anyone working on them? I noticed that in 2021 roadmap, there is no mention of adding support for other hypervisors. Thanks vatsa -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

1 0

CFP Reminder: KVM Forum 2021
by Paolo Bonzini 15 May '21

15 May '21

================================================================ KVM Forum 2021 virtual experience September 15-16, 2021 (All submissions must be received before May 31, 2021 at 23:59 PST) ================================================================= KVM Forum is an annual event that presents a rare opportunity for developers and users to discuss the state of Linux virtualization technology and plan for the challenges ahead. This highly technical conference unites the developers who drive … [View More]KVM development and the users who depend on KVM as part of their offerings, or to power their data centers and clouds. Sessions include updates on the state of the KVM virtualization stack, planning for the future, and many opportunities for attendees to collaborate. Over the years since its inclusion in the mainline kernel, KVM has become a critical part of the FOSS cloud infrastructure. Come join us in continuing to improve the KVM ecosystem. Due to continuing COVID-19 safety concerns, KVM Forum 2021 will be presented as a virtual experience. You will have the ability to network with other attendees, attend sessions with live speaker Q&A, interact with sponsors in real-time, and much more – all virtually, from anywhere. We encourage you to submit and reach out to us should you have any questions. The program committee may be contacted as a group via email: kvm-forum-2021-pc(a)redhat.com. SUGGESTED TOPICS ---------------- * Scalability and Optimization * High Availability and Fault Tolerance * Hardening and security * Testing KVM and the Linux Kernel: * New Features and Architecture Ports * Resource Management (CPU, I/O, Memory) and Scheduling * Device Passthrough: VFIO, mdev, vDPA * Network Virtualization * Virtio and vhost Virtual Machine Monitors and Management * VMM Implementation: APIs, Live Migration, Performance Tuning, etc. * Multi-process VMMs: vhost-user, vfio-user, QEMU Storage Daemon, SPDK * QEMU without KVM: Hypervisor.framework, Windows Hypervisor Platform, etc. * Managing KVM: Libvirt, KubeVirt, Kata Containers Emulation * New Devices, Boards and Architectures * CPU Emulation and Binary Translation SUBMITTING YOUR PROPOSAL ------------------------ Abstracts due: May 31, 2021 Please submit a short abstract (~150 words) describing your presentation proposal. Slots vary in length up to 45 minutes. Submit your proposal here: https://events.linuxfoundation.org/kvm-forum/program/cfp/ Please only use the categories "presentation" and "panel discussion" You will receive a notification whether or not your presentation proposal was accepted by August 17, 2021. Speakers will receive a complimentary pass for the event. In case your submission has multiple presenters, only the primary speaker for a proposal will receive a complimentary event pass. For panel discussions, all panelists will receive a complimentary event pass. TECHNICAL TALKS A good technical talk should not just report on what has happened over the last year; it should present a concrete problem and how it impacts the user and/or developer community. Whenever applicable, focus on work that needs to be done, difficulties that haven't yet been solved, and on decisions that other developers should be aware of. Summarizing recent developments is okay but it should not be more than a small portion of the overall talk. END-USER TALKS One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user talk. As an end user, this is a unique opportunity to get your input to developers. PANEL DISCUSSIONS If you are proposing a panel discussion, please make sure that you list all of your potential panelists in your the abstract. We will request full biographies if a panel is accepted. HANDS-ON / BOF SESSIONS We will reserve some time for people to get together and discuss strategic decisions as well as other topics that are best solved within smaller groups. These sessions will be announced during the event. If you are interested in organizing such a session, please add it to the list at http://www.linux-kvm.org/page/KVM_Forum_2021_BOF Let people you think who might be interested know about your BOF, and encourage them to add their names to the wiki page as well. Please add your ideas to the list before KVM Forum starts. HOTEL / TRAVEL -------------- This year's event will take place at the Conference Center Dublin. For information on hotels close to the conference, please visit https://events.linuxfoundation.org/kvm-forum/attend/venue-travel/. Information on conference hotel blocks will be available later in Spring 2021. DATES TO REMEMBER ----------------- * CFP Closes: Monday, May 31 at 11:59 PM PST * CFP Notifications: Monday, July 6 * Schedule Announcement: Thursday, July 8 * Slide Due Date: Monday, September 13 * Event Dates: Wednesday, September 15 – Thursday, September 16 Thank you for your interest in KVM. We're looking forward to your submissions and, if the conditions will permit it, to seeing you at the KVM Forum 2021 in September! -your KVM Forum 2021 Program Committee Please contact us with any questions or comments at kvm-forum-2021-pc(a)redhat.com [View Less]

1 0

vPTG April 2021 Team Signup
by Kendall Nelson 23 Mar '21

23 Mar '21

Greetings! As you hopefully already know, our next PTG will be virtual again, and held from Monday, April 19 to Friday, April 23. We will have the same schedule set up available as last time with three windows of time spread across the day to cover all timezones with breaks in between. To signup your team, you must complete BOTH the survey[1] AND reserve time in the ethercalc[2] by March 25 at 7:00 UTC. We ask that the PTL/SIG Chair/Team lead sign up for time to have their discussions in … [View More]

1 0

Hosting vhost-user servers in rust-vmm?
by Sergio Lopez 17 Mar '21

17 Mar '21

Hi, It's very likely that, along this year, we'll start seeing a number of new vhost-user device implementations based on rust-vmm crates. I think it'd be very valuable to have a centralized place to host those crates, so both final users and developers can easily find them, and I have the feeling that rust-vmm can be that place. Do you think rust-vmm is the right place for them? Would we need to update the Community docs to reflect the presence of such components? Thanks, Sergio.

3 2

Re: [Rust-VMM] rust-vmm sync meeting
by Florescu, Andreea 09 Mar '21

09 Mar '21

Thanks everyone for joining! Here are the meeting minutes: * Logging: https://github.com/rust-vmm/vhost-user-backend/issues/4 * whats the idomatic way to do logging across the various crates? * typically people use the log crate and build on top of it: https://crates.io/crates/log * alternative proposal: hide all logging & metrics behind an interface that defines relevant events * example of usage: https://github.com/rust-vmm/vm-superio/blob/… [View More]c9ecf106d4d8d38fdc8e91e254a7f78… * for now this is used only for metrics * CH is using a macro for events: https://github.com/cloud-hypervisor/cloud-hypervisor/blob/master/event_moni… * let's use this issue to continue the discussion: https://github.com/rust-vmm/community/issues/104 * for debugging & developing we can use the log crate * also an open question about metrics (what/where/how many/how filtered) * Public roadmap for 2021: * https://github.com/orgs/rust-vmm/projects/3 * Use label: "roadmap 2021" * Search for roadmap issues: https://github.com/search?q=org%3Arust-vmm+label%3A%22roadmap+2021%22&type=… * Branching policy for crates and release lifecycle management * we've been doing branch releases for security vulnerabilities * we do not have a policy for releases (how long do we support them)? * QEMU: * dev on master * before releases they're looking more into what gets into master (i.e. only bug fixes) * release branch * 3 release/year * CH: * release every 6 weeks * use dependabot * does not support older versions of CH (only support for latest version) * Proposal: * Handle releases on a case by case basis * Proposal for branches: branch when need to (i.e. breaking changes & security releases) * fandree@ add this to the community readme * master support? * only when there is a new change that is needed or when crates are not published * releases on demand to support different projects (release just a versioned tag on master, ad-hoc branch for security backports on a release tag) * obviously master tries to stay stable with CI keeping tests green - cost of a release should be small * kvm-bindings * CH tried to autogenerate new bindings, and it did not work * we need to add documentation (if it does not exist) on how to generate them * State of AArch64 support? * crate support should be complete: kvm-ioctls, linux-loader; used in production Firecracker & Cloud Hypervisor * removing dependency on libfdt options: * rust crate for generating the DT (only static FDT) * ACPI: there is a push to use it by default * adding support to vmm-reference for ARM: https://github.com/rust-vmm/vmm-reference/issues/90 * Support for other hypervisors (!KVM): * did not have time to discuss this; we'll discuss it at the next sync meeting ________________________________ From: Florescu, Andreea Sent: Wednesday, March 3, 2021 3:19 PM To: Barbu, Iulian; Loghin, Laura; Ochescu, Catalin; Horobeanu, Dan; Iordache, Alexandra; Agache, Alexandru; meet(a)chime.aws; pin+2352511775(a)chime.aws; rust-vmm(a)lists.opendev.org Cc: M. Dodson; Ceyhun Ertürk; Catangiu, Adrian Costin; Zach Reizner; Wise, Bob; Liguori, Anthony; Trilok Soni; Dylan Reid; luka.perkov(a)sartura.hr; Brendan Burns; Alex Bennée Subject: rust-vmm sync meeting When: Monday, March 8, 2021 11:00 AM-12:00 PM. Where: Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 2352511775 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 2352511775 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.aws/2352511775 Join via phone (US): +1-929-432-4463,,,2352511775#<tel:+1-929-432-4463,,,2352511775#> Join via phone (US toll-free): +1-855-552-4463,,,2352511775#<tel:+1-855-552-4463,,,2352511775#> International dial-in: https://chime.aws/dialinnumbers/ In-room video system: Ext: 62000, Meeting PIN: 2352511775# ================================================= ================Before your meeting:================ * Learn how to use the touch panel<https://it.amazon.com/en/help/articles/use-the-meeting-room-touch-panel>. * Prefer a video? Watch these touch panel how-to videos<https://broadcast.amazon.com/videos/98363>. * Find out more about room layouts<https://it.amazon.com/en/help/articles/conference-room-configurations>. * Get more information at it.amazon.com/meetings<https://it.amazon.com/en/servicecatalog/meetings>. ================================================ Created with Amazon Meetings<https://meetings.amazon.com> (fandree@, edit this series<https://meetings.amazon.com/#/meeting/new?entryID=Meetings-1614777141769-fa…>) Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. [View Less]

3 4

rust-vmm sync meeting
by Florescu, Andreea 08 Mar '21

08 Mar '21

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.aws/… [View More]

1 0

rust-vmm sync meeting
by Florescu, Andreea 08 Mar '21

08 Mar '21

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.aws/… [View More]

1 0

[Action Required] rust-vmm sync meetings
by Florescu, Andreea 03 Mar '21

03 Mar '21

Hey folks, In the last week sync meeting we discussed about recreating the bi-weekly rust-vmm sync meeting. I created a poll to see when most people can join: https://doodle.com/poll/nrrsivwytgc5zy9n?utm_source=poll&utm_medium=link ? The poll will close on 2021-03-01 so please choose your preferred hour by then. I'll schedule recurring meetings (every 2 weeks, on Monday) starting with ?2021-03-08. Thanks, Andreea Amazon Development Center (Romania) S.R.L. registered office: 27A … [View More]

3 4

rust-vmm sync meeting
by Florescu, Andreea 03 Mar '21

03 Mar '21

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 6592165432 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 6592165432 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.aws/… [View More]

1 0

rust-vmm sync meeting
by Florescu, Andreea 03 Mar '21

03 Mar '21

Meeting Agenda: https://etherpad.opendev.org/p/rust-vmm-sync-2021 ==============Conference Bridge Information============== You have been invited to an online meeting, powered by Amazon Chime. Chime meeting ID: 2352511775 Join via Chime clients (manually): Select 'Meetings > Join a Meeting', and enter 2352511775 Join via Chime clients (auto-call): If you invite auto-call as attendee, Chime will call you when the meeting starts, select 'Answer' Join via browser screen share: https://chime.aws/… [View More]

1 0

April 2021 PTG Dates & Registration
by Kendall Waters 01 Mar '21

01 Mar '21

Hello Everyone! I'm sure you all have been anxiously awaiting the announcement of the dates for the next virtual PTG[1]! The PTG will take place April 19-23, 2021! PTG registration is now open[2]. Like last time, it is free, but we will again be using it to communicate details about the event (schedules, passwords, etc), so please take two minutes to register! Early next week we will send out info to mailing lists about signing up teams. Also, the same as last time, we will have an … [View More]

1 0

[VHOST USER SPEC PATCH] vhost-user.rst: add clarifying language about protocol negotiation
by Alex Bennée 01 Mar '21

01 Mar '21

In practice the protocol negotiation between vhost master and slave occurs before the final feature negotiation between backend and frontend. This has lead to an inconsistency between the rust-vmm vhost implementation and the libvhost-user library in their approaches to checking if all the requirements for REPLY_ACK processing were met. As this is purely a function of the protocol negotiation and not of interest to the frontend lets make the language clearer about the requirements for a … [View More]

4 5

vhost reply_ack negotiation (a.k.a differences in vhost-user behaviour with libvhost-user and vhost-user-backend.rs)
by Alex Bennée 27 Feb '21

27 Feb '21

Hi, I finally got a chance to get down into the guts of vhost-user while attempting to port my original C RPMB daemon to Rust using the vhost-user-backend and related crates. I ended up with this hang during negotiation: startup vhost_user_write req:1 flags:0x1 vhost_user_read_start vhost_user_read req:1 flags:0x5 vhost_user_backend_init: we got 170000000 vhost_user_write req:15 flags:0x1 vhost_user_read_start vhost_user_read req:15 flags:0x5 … [View More]vhost_user_set_protocol_features: 2008 vhost_user_write req:16 flags:0x1 vhost_user_write req:3 flags:0x1 vhost_user_write req:1 flags:0x1 vhost_user_read_start vhost_user_read req:1 flags:0x5 vhost_user_write req:13 flags:0x1 kernel initialises device virtio_rpmb virtio1: init done! vhost_user_write req:13 flags:0x1 vhost_dev_set_features: 130000000 vhost_user_set_features: 130000000 vhost_user_write req:2 flags:0x1 vhost_user_write req:5 flags:0x9 vhost_user_read_start The proximate cause is the vhost crate handling: MasterReq::SET_MEM_TABLE => { let res = self.set_mem_table(&hdr, size, &buf, rfds); self.send_ack_message(&hdr, res)?; } which gates on the replay_ack_enabled flag: fn send_ack_message( &mut self, req: &VhostUserMsgHeader<MasterReq>, res: Result<()>, ) -> Result<()> { if dbg!(self.reply_ack_enabled) { let hdr = self.new_reply_header::<VhostUserU64>(req, 0)?; let val = match res { Ok(_) => 0, Err(_) => 1, }; let msg = VhostUserU64::new(val); self.main_sock.send_message(&hdr, &msg, None)?; } Ok(()) } which is only set when we have all the appropriate acknowledged flags: fn update_reply_ack_flag(&mut self) { let vflag = VhostUserVirtioFeatures::PROTOCOL_FEATURES.bits(); let pflag = VhostUserProtocolFeatures::REPLY_ACK; if (self.virtio_features & vflag) != 0 && (self.acked_virtio_features & vflag) != 0 && self.protocol_features.contains(pflag) && (self.acked_protocol_features & pflag.bits()) != 0 { self.reply_ack_enabled = true; } else { self.reply_ack_enabled = false; } } which from above you can see QEMU helpfully dropped those bits in the reply. It does however work in the C/libvhost version: virtio_rpmb virtio1: init done! vhost_user_write req:13 flags:0x1 vhost_dev_set_features: 130000000 vhost_user_set_features: 130000000 vhost_user_write req:2 flags:0x1 vhost_user_write req:37 flags:0x9 vhost_user_read_start vhost_user_read req:37 flags:0x5 vhost_user_write req:8 flags:0x1 vhost_user_write req:10 flags:0x1 vhost_user_write req:9 flags:0x1 vhost_user_write req:12 flags:0x1 vhost_user_write req:13 flags:0x1 albeit with a slightly different message sequence (VHOST_USER_ADD_MEM_REG instead of VHOST_USER_SET_MEM_TABLE). Reading the C code you can see why: need_reply = vmsg.flags & VHOST_USER_NEED_REPLY_MASK; reply_requested = vu_process_message(dev, &vmsg); if (!reply_requested && need_reply) { vmsg_set_reply_u64(&vmsg, 0); reply_requested = 1; } So regardless of what may have been negotiated it will always reply with something if the master requested it do so. This points us at the specification which reads: - Bit 3 is the need_reply flag - see :ref:`REPLY_ACK <reply_ack>` for details. which says in VHOST_USER_PROTOCOL_F_REPLY_ACK that this bit should only be honoured when the feature has been negotiated. Which brings us to a series of questions: - Should QEMU have preserved VhostUserVirtioFeatures::PROTOCOL_FEATURES when doing the eventual VHOST_USER_SET_FEATURES reply? - Is vhost.rs being to strict or libvhost-user too lax in interpreting the negotiated features before processing the ``need_reply`` [Bit 3] field of the messages? - are VHOST_USER_SET_MEM_TABLE to VHOST_USER_SET_INFLIGHT_FD included in the "list of the ones that do" require replies or do they only reply when REPLY_ACK has been negotiated as the ambiguous "seealso::" box out seems to imply? Currently I have some hacks in: https://github.com/stsquad/vhost/tree/my-hacks which gets my daemon booting up to the point we actually need to do a transaction. However I won't submit a PR until I've worked out exactly where the problems are. -- Alex Bennée [View Less]

7 10

[RFC PATCH] vhost_user/slave_reg_handler: relax the reply_ack_flag test
by Alex Bennée 25 Feb '21

25 Feb '21

In reality the real guest may never see PROTOCOL_FEATURES bit when it probes the device configuration. It shouldn't matter to it anyway as they details of reply acknowledgement have already been negotiated between the two ends of the vhost-user protocol having been advertised by the backend on start-up. This prevents a hang with the QEMU remote end which makes it's determination to ask for a reply based only on the negotiated protocol feature set: bool reply_supported = virtio_has_feature(… [View More]

1 0

Enabling automatic dependency updates
by Florescu, Andreea 22 Feb '21

22 Feb '21

Hey everyone, I've enabled automatic dependency updates for all rust-vmm repositories. These are performed by Dependabot [1]. The main reason for that is making sure we uniformly test all the rust-vmm crates using the latest version of the rust-vmm-ci (which is pulled as a git submodule). Initially I've set it up such that is also updates the Rust dependencies, but it seems that is not very wise for some repositories where we need to use strict dependencies (for example we need to use a … [View More]

1 0