GSoC virtio-rtc project

GSoC virtio-rtc project

[Ammar Yasser]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

Hi,

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.

I've been reading the virtio-rtc device spec, the kernel driver code, and
QEMU's virtual clock implementations. And i'd like to ask:

- Are there recommended starter issues or small tasks?
- Who would be the best maintainer to coordinate with?

Thanks,
Ammar

[-- Attachment #2: Type: text/html, Size: 527 bytes --]

Re: GSoC virtio-rtc project

[Thomas Huth]

On 01/03/2026 23.15, Ammar Yasser wrote:
> Hi,
> 
> 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.
> 
> I've been reading the virtio-rtc device spec, the kernel driver code, and 
> QEMU's virtual clock implementations. And i'd like to ask:
> 
> - Are there recommended starter issues or small tasks?

  Hi!

If you want to get started with contributing to QEMU, we've got a bunch of 
small task in the bug tracker here:

https://gitlab.com/qemu-project/qemu/-/issues?label_name%5B%5D=Bite%20Sized

> - Who would be the best maintainer to coordinate with?

Mentors are mentioned here:

  https://wiki.qemu.org/Internships/ProjectIdeas/VhostUserRTC

  HTH,
   Thomas

Re: GSoC virtio-rtc project

[Ammar Yasser]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

Hello maintainers

Re-introducing myself in case you missed my email to the mailing list.
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

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?

Thanks in advance

Ammar


On Mon, 2 Mar 2026 at 09:12, Thomas Huth <thuth@redhat.com> wrote:

> On 01/03/2026 23.15, Ammar Yasser wrote:
> > Hi,
> >
> > 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.
> >
> > I've been reading the virtio-rtc device spec, the kernel driver code,
> and
> > QEMU's virtual clock implementations. And i'd like to ask:
> >
> > - Are there recommended starter issues or small tasks?
>
>   Hi!
>
> If you want to get started with contributing to QEMU, we've got a bunch of
> small task in the bug tracker here:
>
> https://gitlab.com/qemu-project/qemu/-/issues?label_name%5B%5D=Bite%20Sized
>
> > - Who would be the best maintainer to coordinate with?
>
> Mentors are mentioned here:
>
>   https://wiki.qemu.org/Internships/ProjectIdeas/VhostUserRTC
>
>   HTH,
>    Thomas
>
>

[-- Attachment #2: Type: text/html, Size: 3080 bytes --]

Re: GSoC virtio-rtc project

[Francesco Valla]

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

Re: GSoC virtio-rtc project

[Ammar Yasser]

[-- Attachment #1: Type: text/plain, Size: 4527 bytes --]

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 <francesco@valla.it> 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 5367 bytes --]