On Sat, Mar 16, 2024 at 9:27 PM Sahil <icegambi...@gmail.com> wrote: > > 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).
Now I realize we used a very misleading term there :). Without ioeventfd, when the guest writes to the PCI notification area the guest vCPU is totally paused there, and the control is handed to host's KVM first and QEMU after it. The same physical CPU of the machine needs to switch context because of that. Is an interruption of the execution and a context switch. Maybe "paused" is a better term. > 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. > They are different, but at that part of the blog is just the direction of who interrupts / notifies who :). > 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. > Good catch :). CCing Laurent, the author of the blog, in case he can modify the text. > > [...] > > 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 > >
