[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: VirtioSound device emulation implementation
From: |
Alex Bennée |
Subject: |
Re: Fwd: VirtioSound device emulation implementation |
Date: |
Mon, 11 Jan 2021 11:59:52 +0000 |
User-agent: |
mu4e 1.5.7; emacs 28.0.50 |
Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes:
> ---------- Forwarded message ---------
> From: Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com>
> Date: Mon, 11 Jan 2021 at 11:59
> Subject: Re: VirtioSound device emulation implementation
> To: Gerd Hoffmann <kraxel@redhat.com>
>
>
>
>
> On Sun, 10 Jan 2021 at 13:55, Shreyansh Chouhan <
> chouhan.shreyansh2702@gmail.com> wrote:
>
>> Hi,
>>
>> I have been reading about the virtio and vhost specifications, however I
>> have a few doubts. I tried looking for them but I still
>> do not understand them clearly enough. From what I understand, there are
>> two protocols:
>>
>> The virtio protocol: The one that specifies how we can have common
>> emulation for virtual devices. The front end drivers
>> interact with these devices, and these devices could then process the
>> information that they have received either in QEMU,
>> or somewhere else. From what I understand the front driver uses mmaps to
>> communicate with the virtio device.
>>
>> The vhost protocol: The one that specifies how we can _offload_ the
>> processing from QEMU to a separate process. We
>> want to offload so that we do not have to stop the guest when we are
>> processing information passed to a virtio device. This
>> service could either be implemented in the host kernel or the host
>> userspace. Now when we offload the processing, we map the
>> memory of the device to this vhost service, so that this service has all
>> the information that it should process.
>> Also, this process can generate the vCPU interrupts, and this process
>> responds to the ioeventfd notifications.
>>
>> What I do not understand is, once we have this vhost service, either in
>> userspace or in kernel space, which does the information processing,
>> why do we need a virtio device still emulated in QEMU? Is it only to pass
>> on the configurations between the driver and the
>> vhost service? I know that the vhost service doesn't emulate anything, but
>> then what is the difference between "processing" the
>> information and "emulating" a device?
>>
>> Also, from article[3], moving the vhost-net service to userspace was
>> faster somehow. I am assuming this was only the case for
>> networking devices, and would not be true in general. Since there would be
>> more context switches between user and kernel space?
>> (KVM receives the irq/ioevent notification and then transfers control back
>> to user space, as opposed to when vhost was in kernel
>> space.)
>>
>> For context, I've been reading the following:
>> [1]
>> https://www.redhat.com/en/blog/introduction-virtio-networking-and-vhost-net
>> [2]
>> https://www.redhat.com/en/blog/deep-dive-virtio-networking-and-vhost-net
>> [3] https://www.redhat.com/en/blog/journey-vhost-users-realm
>>
>>
> Found the answers in this blog:
> http://blog.vmsplice.net/2011/09/qemu-internals-vhost-architecture.html
> In short, yes, the configuration plane still remains with QEMU. The
> frontend driver interacts with the PCI
> adapter emulated in QEMU, for configurations and memory map setup. Only the
> data plane is forwarded
> to the vhost service. This makes sense since we would only want to
> configure the device once, and hence
> having that emulated in QEMU is not a performance issue, as much as having
> the data plane was.
Also if you are running a pure TCG emulation QEMU can pass along the
signalled events from the guest to the vhost-user daemon as well.
> There is still a little confusion in my mind regarding a few things, but I
> think looking at the source code
> of the already implemented drivers will clear that up for me. So that is
> what I will be doing next.
>
> I will start looking at the source code for in-QEMU and vhost
> implementations of other virtio drivers, and then decide which one I'd like
> to
> go with. I will probably follow that decision with an implementation
> plan/timeline so that everyone can follow the progress on the
> development of this project.
--
Alex Bennée
- VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/06
- Re: VirtioSound device emulation implementation, Alex Bennée, 2021/01/06
- Re: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/07
- Re: VirtioSound device emulation implementation, Gerd Hoffmann, 2021/01/07
- Re: VirtioSound device emulation implementation, Alex Bennée, 2021/01/07
- Re: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/08
- Re: VirtioSound device emulation implementation, Gerd Hoffmann, 2021/01/08
- Re: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/10
- Message not available
- Fwd: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/11
- Re: Fwd: VirtioSound device emulation implementation,
Alex Bennée <=
- Re: Fwd: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/14
- Re: Fwd: VirtioSound device emulation implementation, Alex Bennée, 2021/01/14
- Re: Fwd: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/15
- Re: Fwd: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/17
- Re: Fwd: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/18
- Re: Fwd: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/20
- Re: Fwd: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/25
- Re: Fwd: VirtioSound device emulation implementation, Alex Bennée, 2021/01/25
- Re: Fwd: VirtioSound device emulation implementation, Shreyansh Chouhan, 2021/01/27
- Re: Fwd: VirtioSound device emulation implementation, Alex Bennée, 2021/01/28