Hey Francesco Thanks for your guidance, Note that some of the phases highlighted can be discussed or thought of before the project starts, but will be revisited to a greater depth when the project starts if we didn't fully converge on them. If we do, then the planning phases should be on the shorter end of the range.
My core assumption is that there are two parts to the clock. The part that does the basic state keeping, hardware interaction and so on.. and the part that interprets that state into UTC, or TAI.. etc. that being said, here's my thought process for how we might structure the project: 1- Define the basic code structure for the device, what are its parameters and how it interacts with QEMU, how it takes inputs from multiple VMs and what are the basic data structures it uses for book keeping and so on (1~2 weeks) 2- Come up with a basic design for a clock and explore the core questions. like what state it keeps internally, how and when does this state change, what syscalls will it make to actually read the time, how the code would handle different architectures, how would cross timestamping work, and how would a typical translation layer from the fundamental state to one of the clock types in the spec look like (1~2 weeks) 3- Implement the core state of the clock + develop a strong test suite (2 weeks) 4- Pick one clock type and implement its full features (alarms, cross timestamping with VIRTIO_RTC_COUNTER_ARM_VCT and VIRTIO_RTC_COUNTER_X86_TSC), preferably the UTC_SMEARED clock as its the one with the most complexity. It's always expected that there might be some aspects that will balloon in time, so committing to finishing the most complex clock fully would help clear a lot of ambiguity. (2 weeks) 5- Write the QEMU glue code (1 week) 6- Test the clock developed at phase 4 with QEMU end-to-end on arm and x86_64, report any issues (1 week) 7- Complete as many as possible of the other clock types after sorting them by priority (till the end of the program) Let me know if this plan sounds or if it contains any gaps! Some of the questions i have to gauge priorities are: - Which matters more ? full spec coverage on a single architecture, or partial but consistent coverage across all architectures? - Are there any architectures that we should think of supporting apart from arm and x86_64 ? - Based on your experience, where do you believe the majority of the complexity will come from ? Thanks in advance Ammar On Tue, 3 Mar 2026 at 23:42, Francesco Valla <[email protected]> wrote: > Hello Ammar, > > On lunedì 2 marzo 2026 at 23:53, Ammar Yasser wrote: > > Hello maintainers > > > > Re-introducing myself in case you missed my email to the mailing list. > > I *did* lost your first e-mail, so thank you for writing this one. > > > I'm Ammar, a software engineer working with Linux kernel and > virtualization. > > I'm interested in contributing to QEMU for GSoC 2026, particularly the > > virtio-rtc vhost-user device project. If accepted, this would be my > second > > GSoC participation. I participated in 2024 with KubeVirt, which was my > > original introduction to QEMU. > > > > I have the following questions in order to formulate a successful > proposal: > > > > 1. What would you like to see from a successful proposal ? The current > > points i am studying and plan to include in mine are: > > > > - an overview of the RTC device spec > > - how it would interact with QEMU > > - some of the rust data types and enums we would introduce for requests, > > different error types.. etc > > - a breakdown for some of the RTC C implementations that currently exist > in > > QEMU (allwinner, aspeed, goldfish.. etc), and what ideas can we borrow > from > > them in our rust implementation > > > > I am leaving out implementation specific details out of the current > phase. > > Let me know if this sounds appropriate > > > > I'd include some details on how you intend to perform the activity (e.g.: > how > to split and order the various tasks). > > > 2. I am looking for issues I can tackle to familiarize myself with the > > vhost-device repo and how one device is structured. Any ones you have > that > > are relevant to the project or you think are important in general? > > > > No preferences there, please select the one(s) you think appropriate. > > > Thanks in advance > > > > Ammar > > > > > > Regards, > > Francesco > > >
