Question on virtio frontend backend drivers
Hello, I was under the impression that the each virtio driver will have a frontend and backend part. The frontend part would be loaded in the Guest OS and the backend driver will be loaded in the Host OS. These two drivers will communicate with each other. The backend driver will then retransmit the actual request to correct driver. But seems like my understanding is wrong. I attached a virtio disk to the Guest OS. When the Guest was booted, after creating a file system on the attached disk I mounted it. [pra...@prasad-fedora12-vm ~]$ lsmod | grep -i virtio virtio_blk 7352 1 virtio_pci 8680 0 virtio_ring 6080 1 virtio_pci virtio 5220 2 virtio_blk,virtio_pci But on the host machine no backend driver was loaded r...@prasad-desktop:~/VMDisks# lsmod | grep -i virtio r...@prasad-desktop:~/VMDisks# Does this mean there is no explicit backend driver? If I attach a raw disk as a virtio disk. The backend driver will be none other than the driver of the disk itself. Am I correct? Suppose I write a simple character device driver for Host OS. Now I want to make it available in the Guest OS. Would only writing the frontend driver suffice? Thanks and Regards, Prasad Joshi (Student ID: 19015523) MRes Systems Engineering-- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question on virtio frontend backend drivers
On Mon, Nov 22, 2010 at 2:05 PM, Prasad Joshi p.g.jo...@student.reading.ac.uk wrote: I was under the impression that the each virtio driver will have a frontend and backend part. The frontend part would be loaded in the Guest OS and the backend driver will be loaded in the Host OS. These two drivers will communicate with each other. The backend driver will then retransmit the actual request to correct driver. But seems like my understanding is wrong. I attached a virtio disk to the Guest OS. When the Guest was booted, after creating a file system on the attached disk I mounted it. [pra...@prasad-fedora12-vm ~]$ lsmod | grep -i virtio virtio_blk 7352 1 virtio_pci 8680 0 virtio_ring 6080 1 virtio_pci virtio 5220 2 virtio_blk,virtio_pci But on the host machine no backend driver was loaded r...@prasad-desktop:~/VMDisks# lsmod | grep -i virtio r...@prasad-desktop:~/VMDisks# Does this mean there is no explicit backend driver? A virtio device is a PCI adapter in the guest. That's why you see virtio_pci. The userspace QEMU process (called qemu-kvm or qemu) does device emulation and contains the virtio code you are looking for. See hw/virtio-blk.c in qemu-kvm.git. Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] question on virtio
Michael S. Tsirkin wrote: Hi! I see this in virtio_ring.c: /* Put entry in available array (but don't update avail-idx * until they do sync). */ Why is it done this way? It seems that updating the index straight away would be simpler, while this might allow the host to specilatively look up the buffer and handle it, without waiting for the kick. Even better, if the host updates a location containing which index it has seen recently, you can avoid the kick entirely during sustained flows - just like your recent patch to avoid sending irqs to the guest. -- Jamie -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
question on virtio
Hi! I see this in virtio_ring.c: /* Put entry in available array (but don't update avail-idx * until they do sync). */ Why is it done this way? It seems that updating the index straight away would be simpler, while this might allow the host to specilatively look up the buffer and handle it, without waiting for the kick. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question on virtio
On Wed, May 05, 2010 at 02:40:15PM -0500, Anthony Liguori wrote: On 05/05/2010 06:09 AM, Michael S. Tsirkin wrote: Hi! I see this in virtio_ring.c: /* Put entry in available array (but don't update avail-idx * until they do sync). */ Why is it done this way? It seems that updating the index straight away would be simpler, while this might allow the host to specilatively look up the buffer and handle it, without waiting for the kick. It should be okay as long as you don't update idx for partial vectors. Regards, Anthony Liguori Sorry, what do you mean by partial vectors here? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question on virtio
On Wed, 5 May 2010 08:39:47 pm Michael S. Tsirkin wrote: Hi! I see this in virtio_ring.c: /* Put entry in available array (but don't update avail-idx * until they do sync). */ Why is it done this way? It seems that updating the index straight away would be simpler, while this might allow the host to specilatively look up the buffer and handle it, without waiting for the kick. I agree. From my TODO: what if we actually expose in -add_buf? I don't *think* anyone adds buffers without being ready for them to be used, so changing this should be safe. Want to give it a try and report back? Thanks! Rusty. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
