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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.