From: Sahil <icegambit91@gmail.com>
To: Eugenio Perez Martin <eperezma@redhat.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>,
qemu-level <qemu-devel@nongnu.org>
Subject: Re: Intention to work on GSoC project
Date: Sun, 17 Mar 2024 01:56:47 +0530 [thread overview]
Message-ID: <9252283.CDJkKcVGEf@valdaarhun> (raw)
In-Reply-To: <CAJaqyWdmGbYj1KjN6zcu-fRij9X6mNG-xKHqQiaVsY1zu1T-Ag@mail.gmail.com>
Hi,
Thank you for your reply.
On Friday, March 15, 2024 4:57:39 PM IST Eugenio Perez Martin wrote:
> [...]
> > Some sections in the above docs were difficult to grasp. For the time
> > being, I have focused on those parts that I thought were relevant
> > to the project.
>
> Please feel free to ask any questions, maybe we can improve the doc :).
I understood the introductory sections of the documentation such as the
"About QEMU" section and the first half of the "system emulation". Sections
and subsections that went into greater detail were a little overwhelming
such as the "QEMU virtio-net standby" subsection [1] or the "migration
features" [2] subsection. But the red hat blogs and deep-dive articles helped
cover a lot of ground conceptually.
I feel once I start getting my hands dirty, I'll be able to absorb these concepts
much better.
I did have two questions that I would like to ask.
Q1.
Regarding the "Deep dive into Virtio-networking and vhost-net" article [3],
the "Introduction" subsection of the "Vhost protocol" section mentions that
sending the available buffer notification involves a vCPU interrupt (4th bullet
point). But in figure 2, the arrow for the "available buffer notification" indicates
a PCI interrupt. Initially I thought they were two different interrupts but I am
a little confused about this now.
Q2.
In the "Virtio-net failover operation" section of the "Virtio-net failover: An
introduction" article [4], there are five bullet points under the first figure.
The second point states that the guest kernel needs the ability to switch
between the VFIO device and the vfio-net device. I was wondering if
"vfio-net" is a typo and if it should be "virtio-net" instead.
> [...]
> There is a post before the first in the series:
> https://www.redhat.com/en/blog/virtio-devices-and-drivers-overview-headjack-
> and-phone
Got it. I didn't know this was the first in the series. I have now covered this as
well, so I can move on to "Virtqueues and virtio ring: How the data travels" [3] :)
> > 1. Virtqueues and virtio ring: How the data travels [8]
> > 2. Packed virtqueue: How to reduce overhead with virtio [9]
> > 3. Virtio live migration technical deep dive [10]
> > 4. Hands on vDPA: what do you do when you ain't got the hardware v2 (Part
> > 1) [11]
> I think it's a good plan!
>
> If you feel like you're reading a lot of theory and want to get your
> hands dirty already, you can also start messing with the code with the
> blogs you already read. Or, maybe, after reading the Packed virtqueue
> one, your call.
>
> In a very brute-forced description, you can start trying to copy all
> the *packed* stuff of kernel's drivers/virtio/virtio_ring.c into
> vhost_shadow_virtqueue.c.
I would love to start with some hands-on tasks. I'll take a look at
the kernel's "drivers/virtio/virtio_ring.c". I think I should also start
going through the "vhost_shadow_virtqueue.c" [4] source code.
> There is a lot more in the task, and I can get into more detail
> if you want either here or in a meeting.
Thank you. Either means of communication works for me although
the latter will require some coordination.
> If you prefer to continue with the theory it is ok too.
A good balance of theory and practice would be nice at this stage.
It'll keep my brains from getting too muddled up.
Thanks,
Sahil
[1] https://www.qemu.org/docs/master/system/virtio-net-failover.html
[2] https://www.qemu.org/docs/master/devel/migration/features.html
[3] https://www.redhat.com/en/blog/deep-dive-virtio-networking-and-vhost-net
[4] https://www.redhat.com/en/blog/virtio-net-failover-introduction
[5] https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels
next prev parent reply other threads:[~2024-03-16 20:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-25 21:38 Intention to work on GSoC project Sahil
2024-02-29 8:32 ` Stefano Garzarella
2024-02-29 19:02 ` Sahil
2024-03-01 7:40 ` Eugenio Perez Martin
2024-03-01 18:29 ` Sahil
2024-03-14 15:09 ` Eugenio Perez Martin
2024-03-15 7:14 ` Sahil
2024-03-15 11:27 ` Eugenio Perez Martin
2024-03-16 20:26 ` Sahil [this message]
2024-03-18 19:47 ` Sahil
2024-03-20 16:29 ` Eugenio Perez Martin
2024-03-25 13:20 ` Sahil
2024-04-01 18:23 ` daleyoung4242
2024-04-02 4:58 ` Sahil
2024-04-02 11:38 ` Eugenio Perez Martin
2024-04-03 14:36 ` Sahil
2024-04-03 18:37 ` Eugenio Perez Martin
2024-04-04 19:06 ` Sahil
2024-04-14 18:52 ` Sahil
2024-04-15 8:57 ` Eugenio Perez Martin
2024-04-15 19:42 ` Sahil
2024-04-16 8:41 ` Eugenio Perez Martin
2024-04-17 4:23 ` Sahil
2024-05-06 19:00 ` Sahil
2024-05-07 7:14 ` Eugenio Perez Martin
2024-05-08 3:23 ` Sahil
2024-05-13 13:49 ` Sahil
2024-05-13 14:23 ` Eugenio Perez Martin
2024-05-13 18:04 ` Sahil
2024-03-20 15:57 ` Eugenio Perez Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9252283.CDJkKcVGEf@valdaarhun \
--to=icegambit91@gmail.com \
--cc=eperezma@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).