* VirtioSound device emulation implementation @ 2021-01-06 10:00 Shreyansh Chouhan 2021-01-06 11:40 ` Alex Bennée 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-06 10:00 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 551 bytes --] Hey everyone! I want to work on implementing the emulation for the VritioSound device. I contacted the mentor for the project, (Greg), who said it's fine and that I should declare it on the mailing list in order to find out if someone else is already working on this project. That is what this mail is for. I tried searching for "Virtio", "Sound", and "VirtioSound" in the qemu-devel mailing archives but couldn't find anything. If someone is already working on it, please let me know, and if not then I'll start working on it right away. Shreyansh [-- Attachment #2: Type: text/html, Size: 676 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: VirtioSound device emulation implementation 2021-01-06 10:00 VirtioSound device emulation implementation Shreyansh Chouhan @ 2021-01-06 11:40 ` Alex Bennée 2021-01-07 14:58 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Alex Bennée @ 2021-01-06 11:40 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: qemu-devel Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: > Hey everyone! > > I want to work on implementing the emulation for the VritioSound device. I > contacted the mentor for the project, (Greg), who said it's fine and that I > should declare it on the mailing list in order to find out if someone else > is already working on this project. That is what this mail is for. I tried > searching for "Virtio", "Sound", and "VirtioSound" in the qemu-devel > mailing archives but couldn't find anything. If someone is already working > on it, please let me know, and if not then I'll start working on it right > away. I'm not working on it but please feel free to CC me on discussion and patches. I have a general interest on Virtio IO implementations at the moment. Are you planning to make it an in-QEMU device or maybe a external vhost-user daemon? -- Alex Bennée ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: VirtioSound device emulation implementation 2021-01-06 11:40 ` Alex Bennée @ 2021-01-07 14:58 ` Shreyansh Chouhan 2021-01-07 15:58 ` Gerd Hoffmann 2021-01-07 17:17 ` Alex Bennée 0 siblings, 2 replies; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-07 14:58 UTC (permalink / raw) To: Alex Bennée; +Cc: qemu-devel, Gerd Hoffmann [-- Attachment #1: Type: text/plain, Size: 1577 bytes --] On Wed, 6 Jan 2021 at 17:12, Alex Bennée <alex.bennee@linaro.org> wrote: > > Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: > > > Hey everyone! > > > > I want to work on implementing the emulation for the VritioSound device. > I > > contacted the mentor for the project, (Greg), who said it's fine and > that I > > should declare it on the mailing list in order to find out if someone > else > > is already working on this project. That is what this mail is for. I > tried > > searching for "Virtio", "Sound", and "VirtioSound" in the qemu-devel > > mailing archives but couldn't find anything. If someone is already > working > > on it, please let me know, and if not then I'll start working on it right > > away. > > I'm not working on it but please feel free to CC me on discussion and > patches. I have a general interest on Virtio IO implementations at the > moment. > Sure! (Though I should mention that I do not know a lot about the virtio architecture yet. I am still reading up about it. So most of my mails might be (silly) queries. Though I hope to learn about it soon and send in some patches and tests :) > Are you planning to make it an in-QEMU device or maybe a external > vhost-user daemon? > The project page states that we need to use the QEMU audio subsystem for playing and capturing audio samples. I am not entirely sure if this implies that the device should be an in-QEMU device or if it could be an external daemon. What do you suggest? cc Gerd Hoffman > > -- > Alex Bennée > [-- Attachment #2: Type: text/html, Size: 2542 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: VirtioSound device emulation implementation 2021-01-07 14:58 ` Shreyansh Chouhan @ 2021-01-07 15:58 ` Gerd Hoffmann 2021-01-07 17:17 ` Alex Bennée 1 sibling, 0 replies; 36+ messages in thread From: Gerd Hoffmann @ 2021-01-07 15:58 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: Alex Bennée, qemu-devel Hi, > > Are you planning to make it an in-QEMU device or maybe a external > > vhost-user daemon? > > The project page states that we need to use the QEMU audio subsystem > for playing and capturing audio samples. I am not entirely sure if > this implies that the device should be an in-QEMU device or if it > could be an external daemon. What do you suggest? I think the easiest would be to make it an in-qemu device. All the infrastructure qemu has to play sound in various ways (alsa, pulse, jack, oss, ...) can be used without much effort then. That is not set in stone though. It is certainly possible to implement the device as separate process, using the vhost-user protocol for communication with qemu. On one side it is more effort as you have to handle the audio streams and sound devices without qemu helping with that. On the other side vhost-user is also supported by other hypervisors, so the implementation could be shared then. HTH, Gerd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: VirtioSound device emulation implementation 2021-01-07 14:58 ` Shreyansh Chouhan 2021-01-07 15:58 ` Gerd Hoffmann @ 2021-01-07 17:17 ` Alex Bennée 2021-01-08 7:53 ` Shreyansh Chouhan 2021-01-08 8:34 ` Gerd Hoffmann 1 sibling, 2 replies; 36+ messages in thread From: Alex Bennée @ 2021-01-07 17:17 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: qemu-devel, Gerd Hoffmann Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: > On Wed, 6 Jan 2021 at 17:12, Alex Bennée <alex.bennee@linaro.org> wrote: > >> >> Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: >> >> > Hey everyone! >> > >> > I want to work on implementing the emulation for the VritioSound device. >> I >> > contacted the mentor for the project, (Greg), who said it's fine and >> that I >> > should declare it on the mailing list in order to find out if someone >> else >> > is already working on this project. That is what this mail is for. I >> tried >> > searching for "Virtio", "Sound", and "VirtioSound" in the qemu-devel >> > mailing archives but couldn't find anything. If someone is already >> working >> > on it, please let me know, and if not then I'll start working on it right >> > away. >> >> I'm not working on it but please feel free to CC me on discussion and >> patches. I have a general interest on Virtio IO implementations at the >> moment. >> > > Sure! (Though I should mention that I do not know a lot about the virtio > architecture yet. I am still reading up about it. So most of my mails might > be (silly) queries. Though I hope to learn about it soon and send in > some patches and tests :) > > >> Are you planning to make it an in-QEMU device or maybe a external >> vhost-user daemon? > > The project page states that we need to use the QEMU audio subsystem > for playing and capturing audio samples. Is this one of the QEMU internship projects? > I am not entirely sure if this implies that the device should be an > in-QEMU device or if it could be an external daemon. I think it implies having the entire emulation in-QEMU. > What do you suggest? > > cc Gerd Hoffman > > > > >> >> -- >> Alex Bennée >> -- Alex Bennée ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: VirtioSound device emulation implementation 2021-01-07 17:17 ` Alex Bennée @ 2021-01-08 7:53 ` Shreyansh Chouhan 2021-01-08 8:34 ` Gerd Hoffmann 1 sibling, 0 replies; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-08 7:53 UTC (permalink / raw) To: Alex Bennée; +Cc: qemu-devel [-- Attachment #1: Type: text/plain, Size: 2252 bytes --] On Thu, 7 Jan 2021 at 22:49, Alex Bennée <alex.bennee@linaro.org> wrote: > > Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: > > > On Wed, 6 Jan 2021 at 17:12, Alex Bennée <alex.bennee@linaro.org> wrote: > > > >> > >> Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: > >> > >> > Hey everyone! > >> > > >> > I want to work on implementing the emulation for the VritioSound > device. > >> I > >> > contacted the mentor for the project, (Greg), who said it's fine and > >> that I > >> > should declare it on the mailing list in order to find out if someone > >> else > >> > is already working on this project. That is what this mail is for. I > >> tried > >> > searching for "Virtio", "Sound", and "VirtioSound" in the qemu-devel > >> > mailing archives but couldn't find anything. If someone is already > >> working > >> > on it, please let me know, and if not then I'll start working on it > right > >> > away. > >> > >> I'm not working on it but please feel free to CC me on discussion and > >> patches. I have a general interest on Virtio IO implementations at the > >> moment. > >> > > > > Sure! (Though I should mention that I do not know a lot about the virtio > > architecture yet. I am still reading up about it. So most of my mails > might > > be (silly) queries. Though I hope to learn about it soon and send in > > some patches and tests :) > > > > > >> Are you planning to make it an in-QEMU device or maybe a external > >> vhost-user daemon? > > > > The project page states that we need to use the QEMU audio subsystem > > for playing and capturing audio samples. > > Is this one of the QEMU internship projects? > Yes, it is one of the GSoC projects. > > > I am not entirely sure if this implies that the device should be an > > in-QEMU device or if it could be an external daemon. > > I think it implies having the entire emulation in-QEMU. > I see, after reading yours and Gerd's response, I think I will study/think about the implementation details and then decide which will be the best route for me. > > > What do you suggest? > > > > cc Gerd Hoffman > > > > > > > > > >> > >> -- > >> Alex Bennée > >> > > > -- > Alex Bennée > [-- Attachment #2: Type: text/html, Size: 3517 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: VirtioSound device emulation implementation 2021-01-07 17:17 ` Alex Bennée 2021-01-08 7:53 ` Shreyansh Chouhan @ 2021-01-08 8:34 ` Gerd Hoffmann 2021-01-10 8:25 ` Shreyansh Chouhan 1 sibling, 1 reply; 36+ messages in thread From: Gerd Hoffmann @ 2021-01-08 8:34 UTC (permalink / raw) To: Alex Bennée; +Cc: Shreyansh Chouhan, qemu-devel Hi, > >> Are you planning to make it an in-QEMU device or maybe a external > >> vhost-user daemon? > > > > The project page states that we need to use the QEMU audio subsystem > > for playing and capturing audio samples. > > Is this one of the QEMU internship projects? one of last years gsoc project ideas take care, Gerd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: VirtioSound device emulation implementation 2021-01-08 8:34 ` Gerd Hoffmann @ 2021-01-10 8:25 ` Shreyansh Chouhan [not found] ` <CAAQ-SiPiq5NQN=2mvP3isZ9PtYO2Bu64kVEvE6T+3OJd5B-U5A@mail.gmail.com> 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-10 8:25 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Alex Bennée, qemu-devel [-- Attachment #1: Type: text/plain, Size: 2253 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 2897 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <CAAQ-SiPiq5NQN=2mvP3isZ9PtYO2Bu64kVEvE6T+3OJd5B-U5A@mail.gmail.com>]
* Fwd: VirtioSound device emulation implementation [not found] ` <CAAQ-SiPiq5NQN=2mvP3isZ9PtYO2Bu64kVEvE6T+3OJd5B-U5A@mail.gmail.com> @ 2021-01-11 6:29 ` Shreyansh Chouhan 2021-01-11 11:59 ` Alex Bennée 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-11 6:29 UTC (permalink / raw) To: qemu-devel, Alex Bennée [-- Attachment #1: Type: text/plain, Size: 3685 bytes --] ---------- 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. 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. [-- Attachment #2: Type: text/html, Size: 5170 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-11 6:29 ` Fwd: " Shreyansh Chouhan @ 2021-01-11 11:59 ` Alex Bennée 2021-01-14 15:00 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Alex Bennée @ 2021-01-11 11:59 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-11 11:59 ` Alex Bennée @ 2021-01-14 15:00 ` Shreyansh Chouhan 2021-01-14 17:41 ` Alex Bennée 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-14 15:00 UTC (permalink / raw) To: Alex Bennée, Gerd Hoffmann; +Cc: qemu-devel [-- Attachment #1: Type: text/plain, Size: 1745 bytes --] Just an update: I've studied the virtio specification along with the source code and I now understand what the device implementation is going to look like. Also I understand the source code a lot better. I am now reading about the qemu vhost-user protocol. Although I haven't read about the vhost-user daemon in detail, from what little I have read, I would say that the daemon would get the virtqueues from the virtio device and forward it to the sound device of the host. (This is the hard part I think, since an in QEMU device would use code already written for processing these queues.) I think only the tx and rx queues would be shared, and although I do not know exactly how the sharing will be implemented, I think the memory will be shared to the vhost-user daemon too? So now the virtqueue memory is shared between the virtio driver in guest OS, the virtio device in QEMU, and the vhost-user daemon running in the host userspace. As for the configuration part, the driver will negotiate features with the virtio device in QEMU, which in turn will communicate with the vhost-user daemon (via sockets) to get the features supported I think. This is what I think it will roughly look like. (Of course modulo the implementation details.) I do not yet understand how much more difficult will implementing the vhost-user daemon be, and since I was already warned about the difficulty, I will not risk making any hasty decisions that later hinder the project. I will read up about the vhost-user daemon and how it's implemented to get a better idea, and then make the final call. Anyways I am super excited about the project. I got to learn about some really cool things in the past couple of days, and I can not wait to implement it. :) [-- Attachment #2: Type: text/html, Size: 2062 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-14 15:00 ` Shreyansh Chouhan @ 2021-01-14 17:41 ` Alex Bennée 2021-01-15 8:00 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Alex Bennée @ 2021-01-14 17:41 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: Gerd Hoffmann, qemu-devel Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: > Just an update: > > I've studied the virtio specification along with the source code and I now > understand what the device implementation is > going to look like. Also I understand the source code a lot better. I am > now reading about the qemu vhost-user protocol. > > Although I haven't read about the vhost-user daemon in detail, from what > little I have read, I would say that the daemon > would get the virtqueues from the virtio device and forward it to the sound > device of the host. (This is the hard part > I think, since an in QEMU device would use code already written for > processing these queues.) I can't comment on the difficulty there but this does point more towards using the in-QEMU approach given we have a bunch of utility functions already. > I think only the tx and rx > queues would be shared, and although I do not know exactly how the sharing > will be implemented, I think the memory > will be shared to the vhost-user daemon too? So now the virtqueue memory is > shared between the virtio driver in guest > OS, the virtio device in QEMU, and the vhost-user daemon running in the > host userspace. QEMU uses a memfd file descriptor to share the guests entire memory map with the daemon. > As for the configuration part, the driver will negotiate features with the > virtio device in QEMU, which in turn will communicate > with the vhost-user daemon (via sockets) to get the features supported I > think. > > This is what I think it will roughly look like. (Of course modulo the > implementation details.) I do not yet understand how > much more difficult will implementing the vhost-user daemon be, and since I > was already > warned about the difficulty, I will not risk making any hasty decisions > that later hinder the project. I will read up > about the vhost-user daemon and how it's implemented to get a better idea, > and then make the final call. If you want to see an example of a branch new vhost-user daemon being built up from scratch see my recent virtio-rpmb series. The first few patches of in-QEMU code will be the same boilerplate either way I think: https://patchew.org/QEMU/20200925125147.26943-1-alex.bennee@linaro.org/ > Anyways I am super excited about the project. I got to learn about some > really cool things in the past couple of days, > and I can not wait to implement it. :) -- Alex Bennée ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-14 17:41 ` Alex Bennée @ 2021-01-15 8:00 ` Shreyansh Chouhan 2021-01-17 10:30 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-15 8:00 UTC (permalink / raw) To: Alex Bennée; +Cc: Gerd Hoffmann, qemu-devel [-- Attachment #1: Type: text/plain, Size: 2793 bytes --] On Thu, 14 Jan 2021 at 23:17, Alex Bennée <alex.bennee@linaro.org> wrote: > > Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: > > > Just an update: > > > > I've studied the virtio specification along with the source code and I > now > > understand what the device implementation is > > going to look like. Also I understand the source code a lot better. I am > > now reading about the qemu vhost-user protocol. > > > > Although I haven't read about the vhost-user daemon in detail, from what > > little I have read, I would say that the daemon > > would get the virtqueues from the virtio device and forward it to the > sound > > device of the host. (This is the hard part > > I think, since an in QEMU device would use code already written for > > processing these queues.) > > I can't comment on the difficulty there but this does point more towards > using the in-QEMU approach given we have a bunch of utility functions > already. > > > I think only the tx and rx > > queues would be shared, and although I do not know exactly how the > sharing > > will be implemented, I think the memory > > will be shared to the vhost-user daemon too? So now the virtqueue memory > is > > shared between the virtio driver in guest > > OS, the virtio device in QEMU, and the vhost-user daemon running in the > > host userspace. > > QEMU uses a memfd file descriptor to share the guests entire memory map > with the daemon. > Oh I see. > > > As for the configuration part, the driver will negotiate features with > the > > virtio device in QEMU, which in turn will communicate > > with the vhost-user daemon (via sockets) to get the features supported I > > think. > > > > This is what I think it will roughly look like. (Of course modulo the > > implementation details.) I do not yet understand how > > much more difficult will implementing the vhost-user daemon be, and > since I > > was already > > warned about the difficulty, I will not risk making any hasty decisions > > that later hinder the project. I will read up > > about the vhost-user daemon and how it's implemented to get a better > idea, > > and then make the final call. > > If you want to see an example of a branch new vhost-user daemon being > built up from scratch see my recent virtio-rpmb series. The first few > patches of in-QEMU code will be the same boilerplate either way I think: > > https://patchew.org/QEMU/20200925125147.26943-1-alex.bennee@linaro.org/ This looks super helpful! Thanks a lot for this. > > > > Anyways I am super excited about the project. I got to learn about some > > really cool things in the past couple of days, > > and I can not wait to implement it. :) > > > -- > Alex Bennée > - Shreyansh Chouhan [-- Attachment #2: Type: text/html, Size: 3841 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-15 8:00 ` Shreyansh Chouhan @ 2021-01-17 10:30 ` Shreyansh Chouhan 2021-01-18 18:53 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-17 10:30 UTC (permalink / raw) To: Alex Bennée; +Cc: Gerd Hoffmann, qemu-devel [-- Attachment #1: Type: text/plain, Size: 737 bytes --] > > If you want to see an example of a branch new vhost-user daemon being >> built up from scratch see my recent virtio-rpmb series. The first few >> patches of in-QEMU code will be the same boilerplate either way I think: >> >> https://patchew.org/QEMU/20200925125147.26943-1-alex.bennee@linaro.org/ > > This really clears everything about vhost-user daemons. Thanks a lot. I am currently looking at how the sound subsystem is implemented in QEMU. If I can recreate something similar for the vhost-user daemon, I'll make it a vhost-user daemon. Else I will implement it as an in-QEMU device. Either ways, I'll provide an implementation plan with a loose timeline tomorrow. I will start writing the code for the device from tomorrow. [-- Attachment #2: Type: text/html, Size: 1342 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-17 10:30 ` Shreyansh Chouhan @ 2021-01-18 18:53 ` Shreyansh Chouhan 2021-01-20 11:41 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-18 18:53 UTC (permalink / raw) To: Alex Bennée; +Cc: Gerd Hoffmann, qemu-devel [-- Attachment #1: Type: text/plain, Size: 2218 bytes --] I will make it an in-QEMU pci device. After it is done and the device is working, I can write a vhost-user daemon and move the device out of QEMU should it be needed. This way I'd already have the virtio-pci device tested out by the time I get to the vhost-user daemon. Also I'll be a lot more familiar to sound and virtio devices by then hopefully. I hope this is fine? As for the implementation plan, I will start out by writing the structure for the device, `VirtIOSnd` or `VirtIOSound`. Since QEMU already has a base `VirtIODevice` with common implementation along with the `VirtQueue`s, this shouldn't be very difficult. Following this I will start implementing the methods mentioned in the `VirtIODeviceClass`. This would include creating a separate `virtio-sound-pci.c` file with the `realize`, `unrealize` and various init functions. After that, I will start writing the `get`, `set` and validate functions mentioned in the `VirtioDeviceClass`. QEMU already has an implementation for `start_ioeventfd` and `stop_ioeventfd`. This should get us done with the configuration plane. I am thinking of writing a few tests at this point. I will have to read about the qtest framework first though. This should take at most around a month. I am hoping to get it done earlier than that time (~3 weeks) if things go well. From this most of the time goes to tests. I am taking a bit of a margin to err on the side of caution. This now brings us to the dataplane and processing of the data. I think once the data plane is successfully implemented, processing shouldn't take a lot of time. Once the control queue, event queue, tx queue and rx queues are implemented, I can start implementing the Jack and PCM control requests. I can write tests after completing each of these phases. As of right now, I am not awake enough to give a clear plan on the data plane implementation. I will clear the plan out tomorrow. The dataplane along with the processing should at most take a little over a month to implement I'd guess. I will make sure I write a follow up mail tomorrow with a clearer and complete plan. Apologies for any statements that weren't very clear or mistakes in the language that I used. - Shreyansh Chouhan [-- Attachment #2: Type: text/html, Size: 2656 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-18 18:53 ` Shreyansh Chouhan @ 2021-01-20 11:41 ` Shreyansh Chouhan 2021-01-25 6:02 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-20 11:41 UTC (permalink / raw) To: Alex Bennée; +Cc: Gerd Hoffmann, qemu-devel [-- Attachment #1: Type: text/plain, Size: 351 bytes --] I wasn't really able to clearly understand how I will use QEMU VIrtqueues exactly. So, I decided that I will start implementing the part that I already understand. I think once I have something implemented I'll have a better chance at understanding this. I am currently writing the boilerplate code for the device, using `virtio-net` as a reference. [-- Attachment #2: Type: text/html, Size: 442 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-20 11:41 ` Shreyansh Chouhan @ 2021-01-25 6:02 ` Shreyansh Chouhan 2021-01-25 11:23 ` Alex Bennée 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-25 6:02 UTC (permalink / raw) To: Alex Bennée; +Cc: Gerd Hoffmann, qemu-devel [-- Attachment #1: Type: text/plain, Size: 299 bytes --] Just a follow up. Still working on device initialization. I am trying to understand the relation between virtio-net and net device in qemu in hopes of recreating something similar with the audio device. Once I have the device initialization part ready I will send in a couple of patches for review. [-- Attachment #2: Type: text/html, Size: 372 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-25 6:02 ` Shreyansh Chouhan @ 2021-01-25 11:23 ` Alex Bennée 2021-01-28 4:28 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Alex Bennée @ 2021-01-25 11:23 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: Gerd Hoffmann, qemu-devel Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: > Just a follow up. > Still working on device initialization. I am trying to understand the > relation between virtio-net and net device in qemu > in hopes of recreating something similar with the audio device. All QEMU devices have two parts, a frontend (which the guest sees) and a backend (which is how the data gets to somewhere in the host). Some of the command line options in QEMU elide the details for convenience (-nic and -drive are examples). The -netdev device is all about configuring the backend of the network part for a paired -device front end. There is a similar setup for audio (-audiodev) although I'll defer to Gerd's expertise on how the two interact. > Once I have > the device initialization part > ready I will send in a couple of patches for review. Good stuff. -- Alex Bennée ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-25 11:23 ` Alex Bennée @ 2021-01-28 4:28 ` Shreyansh Chouhan 2021-01-28 10:42 ` Alex Bennée 2021-01-28 11:25 ` Gerd Hoffmann 0 siblings, 2 replies; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-28 4:28 UTC (permalink / raw) To: Alex Bennée; +Cc: Gerd Hoffmann, qemu-devel [-- Attachment #1: Type: text/plain, Size: 1499 bytes --] Thanks a lot Alex! > All QEMU devices have two parts, a frontend (which the guest sees) and a > backend (which is how the data gets to somewhere in the host). Some of > the command line options in QEMU elide the details for convenience (-nic > and -drive are examples). The -netdev device is all about configuring > the backend of the network part for a paired -device front end. There is > a similar setup for audio (-audiodev) although I'll defer to Gerd's > expertise on how the two interact. This helped me understand a bit more about how the devices work. In the source code, I found the `virtio-net-pci.c` and `virtio-net.c` files, I think the pci device is what is visible to the guest. So `virtio-net-pci.c` should be the front end? For the realize function, I saw that the `virtio_net_device_realize` function initializes the `net_conf` for the device. So I am guessing that the `virtio_snd_device_realize` function should initialize the number of jacks and streams a device has, along with the configuration for all these jacks and streams? The thing is I do not understand `net` devices all that well so I get a bit confused with what is specific to a net device and what should I actually be worried about :) The device initalization step mentions that the jack and streams should be read and a query should be made for the config of all jacks and streams. What should be the default values of these configurations? I think the realize function is responsible for setting these up. [-- Attachment #2: Type: text/html, Size: 1798 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-28 4:28 ` Shreyansh Chouhan @ 2021-01-28 10:42 ` Alex Bennée 2021-01-28 15:40 ` Shreyansh Chouhan 2021-01-28 11:25 ` Gerd Hoffmann 1 sibling, 1 reply; 36+ messages in thread From: Alex Bennée @ 2021-01-28 10:42 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: Gerd Hoffmann, qemu-devel Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: > Thanks a lot Alex! > >> All QEMU devices have two parts, a frontend (which the guest sees) and a >> backend (which is how the data gets to somewhere in the host). Some of >> the command line options in QEMU elide the details for convenience (-nic >> and -drive are examples). The -netdev device is all about configuring >> the backend of the network part for a paired -device front end. There is >> a similar setup for audio (-audiodev) although I'll defer to Gerd's >> expertise on how the two interact. > > This helped me understand a bit more about how the devices work. In the > source > code, I found the `virtio-net-pci.c` and `virtio-net.c` files, I think the > pci device is what is visible to the guest. > So `virtio-net-pci.c` should be the front end? No - they are both front-ends. In VirtIO you have two transports. The first is virtio-mmio which is a simple set of memory mapped IO registers. There is no discovery (well there is some but the guest needs to find where in memory the mmio bus is via some method like hardcoded address or DTB). The second is virtio-pci. Here the virtio devices are encapsulated in a PCI bus so you get the benefits of discovery and bus enumeration. > For the realize function, I saw that the `virtio_net_device_realize` > function initializes > the `net_conf` for the device. So I am guessing that the > `virtio_snd_device_realize` function > should initialize the number of jacks and streams a device has, along with > the configuration > for all these jacks and streams? No those are all front-end configuration knobs. > The thing is I do not understand `net` devices all that well so I get a bit > confused with > what is specific to a net device and what should I actually be worried > about :) > > The device initalization step mentions that the jack and streams should be > read and > a query should be made for the config of all jacks and streams. What should > be the > default values of these configurations? I think the realize function is > responsible > for setting these up. Gerd? -- Alex Bennée ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-28 10:42 ` Alex Bennée @ 2021-01-28 15:40 ` Shreyansh Chouhan 0 siblings, 0 replies; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-28 15:40 UTC (permalink / raw) To: Alex Bennée; +Cc: Gerd Hoffmann, qemu-devel [-- Attachment #1: Type: text/plain, Size: 3061 bytes --] On Thu, 28 Jan 2021 at 16:54, Alex Bennée <alex.bennee@linaro.org> wrote: > > Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> writes: > > > Thanks a lot Alex! > > > >> All QEMU devices have two parts, a frontend (which the guest sees) and a > >> backend (which is how the data gets to somewhere in the host). Some of > >> the command line options in QEMU elide the details for convenience (-nic > >> and -drive are examples). The -netdev device is all about configuring > >> the backend of the network part for a paired -device front end. There is > >> a similar setup for audio (-audiodev) although I'll defer to Gerd's > >> expertise on how the two interact. > > > > This helped me understand a bit more about how the devices work. In the > > source > > code, I found the `virtio-net-pci.c` and `virtio-net.c` files, I think > the > > pci device is what is visible to the guest. > > So `virtio-net-pci.c` should be the front end? > > No - they are both front-ends. In VirtIO you have two transports. The > first is virtio-mmio which is a simple set of memory mapped IO > registers. There is no discovery (well there is some but the guest needs > to find where in memory the mmio bus is via some method like hardcoded > address or DTB). > > The second is virtio-pci. Here the virtio devices are encapsulated in a > PCI bus so you get the benefits of discovery and bus enumeration. > So I am a bit confused here. First of there are two parts to a virtio device in general. One is the front end that the guest sees, and one is where the processing happens, which could be either in QEMU or as a separate daemon. In case of an in QEMU virtio device, the QEMU front end is replaced by the virtio-front end. Is that true? That's what I think should happen if both of those files are front ends. When you said earlier that all QEMU devices have two parts, I somehow thought that the in-QEMU backend for the audio device will itself have two parts. > > > For the realize function, I saw that the `virtio_net_device_realize` > > function initializes > > the `net_conf` for the device. So I am guessing that the > > `virtio_snd_device_realize` function > > should initialize the number of jacks and streams a device has, along > with > > the configuration > > for all these jacks and streams? > > No those are all front-end configuration knobs. > I am assuming these are set from the command-line or the configuration files. > > > The thing is I do not understand `net` devices all that well so I get a > bit > > confused with > > what is specific to a net device and what should I actually be worried > > about :) > > > > The device initalization step mentions that the jack and streams should > be > > read and > > a query should be made for the config of all jacks and streams. What > should > > be the > > default values of these configurations? I think the realize function is > > responsible > > for setting these up. > > Gerd? > > > > -- > Alex Bennée > -- Shreyansh [-- Attachment #2: Type: text/html, Size: 4049 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-28 4:28 ` Shreyansh Chouhan 2021-01-28 10:42 ` Alex Bennée @ 2021-01-28 11:25 ` Gerd Hoffmann 2021-01-28 15:50 ` Shreyansh Chouhan 1 sibling, 1 reply; 36+ messages in thread From: Gerd Hoffmann @ 2021-01-28 11:25 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: Alex Bennée, qemu-devel On Thu, Jan 28, 2021 at 09:58:23AM +0530, Shreyansh Chouhan wrote: > Thanks a lot Alex! > > > All QEMU devices have two parts, a frontend (which the guest sees) and a > > backend (which is how the data gets to somewhere in the host). Some of > > the command line options in QEMU elide the details for convenience (-nic > > and -drive are examples). The -netdev device is all about configuring > > the backend of the network part for a paired -device front end. There is > > a similar setup for audio (-audiodev) although I'll defer to Gerd's > > expertise on how the two interact. > > This helped me understand a bit more about how the devices work. In the > source > code, I found the `virtio-net-pci.c` and `virtio-net.c` files, I think the > pci device is what is visible to the guest. > So `virtio-net-pci.c` should be the front end? Well, virtio can have different transports, thats why the separation. pci is the most common one, but there are also mmio (supported by x86 microvm and arm/aarch64 virt) and ccw (used on s390x). virtio-net.c is the actual virtio device, virtio-net-pci.c has mostly glue code to make the virtio device visible on the pci bus. > For the realize function, I saw that the `virtio_net_device_realize` > function initializes > the `net_conf` for the device. So I am guessing that the > `virtio_snd_device_realize` function > should initialize the number of jacks and streams a device has, along with > the configuration > for all these jacks and streams? Yes. net_conf is common config (backend, mac address, maybe more) for network devices. For sound devices that would audiodev (link the device to a backend which then handles alsa/pulse/jack/oss/sdl/whatever). Configuration can be done either using device properties, or by having different devices. Using device properties is probably the easier way to go. An example for the latter are the qemu hda codecs. We have three different devices: (1) hda-output: playback-only, offering a virtual line-out. (2) hda-duplex: record/playback, offering line-in and line-out. (3) hda-micro: record/playback, offering microphone and speaker. The difference between (2) and (3) is just the jack labeling, otherwise the behavior is 100% identical (and they share the emulation code of course). But some windows VoIP apps didn't like the line-in and complained about a missing microphone, so we added that ... > The thing is I do not understand `net` devices all that well so I get a bit > confused with > what is specific to a net device and what should I actually be worried > about :) The only thing really required is the audiodev property. Everything else can be hard-coded initially, and once the basics are working refined (like adding properties for jack labels, ...). > The device initalization step mentions that the jack and streams > should be read and a query should be made for the config of all jacks > and streams. What should be the default values of these > configurations? I think the realize function is responsible for > setting these up. I'd start with offering a single 48000, 16bit, stereo, line-out pcm playback channel. HTH, Gerd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-28 11:25 ` Gerd Hoffmann @ 2021-01-28 15:50 ` Shreyansh Chouhan 2021-01-28 16:30 ` Gerd Hoffmann 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-28 15:50 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Alex Bennée, qemu-devel [-- Attachment #1: Type: text/plain, Size: 2318 bytes --] (Gerd, I wasn't able to get gmail to quote your email, so I have just copy pasted the relavant parts.) > Yes. net_conf is common config (backend, mac address, maybe more) for > network devices. For sound devices that would audiodev (link the device > to a backend which then handles alsa/pulse/jack/oss/sdl/whatever). Ah I see, so the net_conf corresponds to audiodev? I thought it would correspond to `virtio_snd_conf`. So as alex said, `virtio_snd_conf` is the front end configuration. > Configuration can be done either using device properties, or by having > different devices. Using device properties is probably the easier way > to go. An example for the latter are the qemu hda codecs. We have > three different devices: > (1) hda-output: playback-only, offering a virtual line-out. > (2) hda-duplex: record/playback, offering line-in and line-out. > (3) hda-micro: record/playback, offering microphone and speaker. > The difference between (2) and (3) is just the jack labeling, otherwise > the behavior is 100% identical (and they share the emulation code of > course). But some windows VoIP apps didn't like the line-in and > complained about a missing microphone, so we added that ... >> The thing is I do not understand `net` devices all that well so I get a bit >> confused with >> what is specific to a net device and what should I actually be worried >> about :) > The only thing really required is the audiodev property. Everything > else can be hard-coded initially, and once the basics are working > refined (like adding properties for jack labels, ...). So in the realize function I set up the audiodev, right? Also in that case why the difference between the net and sound devices? In the net device we set up the common config in net_conf. Does the net_conf somehow later sets up NetDev too? And what is a NetClientState? Is the NetClient the emulated guest? This confuses me a lot. I can't understand what will be the parellel audio device property. Also I can't seem to find where we parse the command line options passed to qemu. The code structure is a bit different from what I had expected. In virtio_net_device_realize we set duplex to half or full depending on the value of the net_conf.duplex_str. But I couldn't find where we actually set it. cc Alex -- Shreyansh [-- Attachment #2: Type: text/html, Size: 3962 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-28 15:50 ` Shreyansh Chouhan @ 2021-01-28 16:30 ` Gerd Hoffmann 2021-01-28 17:34 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Gerd Hoffmann @ 2021-01-28 16:30 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: Alex Bennée, qemu-devel On Thu, Jan 28, 2021 at 09:20:31PM +0530, Shreyansh Chouhan wrote: > (Gerd, I wasn't able to get gmail to quote your email, so I have just copy > pasted the relavant parts.) > > > Yes. net_conf is common config (backend, mac address, maybe more) for > > network devices. For sound devices that would audiodev (link the device > > to a backend which then handles alsa/pulse/jack/oss/sdl/whatever). > > Ah I see, so the net_conf corresponds to audiodev? Oops. Confused that. nic_conf (struct NICConf) is the common config for all network devices, not net_conf. See DEFINE_NIC_PROPERTIES() in include/net/net.h NICConf.peers (exposed as "netdev" property) links the emulated device (frontend) to a netdev (backend) which actually processes the packets sent by the guest. In a simliar way the audiodev property links the emulated audio device to a backend which handles the host-side audio playback using alsa, pulseaudio or something else. > I thought it would correspond to `virtio_snd_conf`. So as alex said, > `virtio_snd_conf` is the front end configuration. Correct. The backend is configured separately, i.e. -netdev user,id=net0,$moreargs or -audiodev alsa,id=snd0,$moreargs Then the two are linked by id, i.e. -device virtio-net-pci,netdev=net0 or -device virtio-sound-pci,audiodev=snd0 > > The only thing really required is the audiodev property. Everything > > else can be hard-coded initially, and once the basics are working > > refined (like adding properties for jack labels, ...). > > So in the realize function I set up the audiodev, right? Also in that case > why the difference between the net and sound devices? In the net > device we set up the common config in net_conf. Does the net_conf > somehow later sets up NetDev too? > > And what is a NetClientState? Is the NetClient the emulated guest? This > confuses me a lot. I can't understand what will be the parellel audio device > property. Not fully sure what NetClientState is, I guess it is shared struct for both frontend and backend to manage the connection state. The audio subsystem has simliar structs, SWVoiceIn and SWVoiceOut for example. There also is QEMUSoundCard. I'd suggest to check out the source code of other audio devices for code examples. > Also I can't seem to find where we parse the command line options > passed to qemu. The code structure is a bit different from what I had > expected. In virtio_net_device_realize we set duplex to half or full > depending on the value of the net_conf.duplex_str. But I couldn't find > where we actually set it. See virtio_net_properties[]. There is a line in the array: DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), And the whole array is registered using: device_class_set_props(dc, virtio_net_properties); That is enough to make those properties work, the qemu core handles everything for you. See hw/core/qdev-properties.c if you are curious, but you can also just consider that a black box at service for you ;) take care, Gerd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-28 16:30 ` Gerd Hoffmann @ 2021-01-28 17:34 ` Shreyansh Chouhan 2021-02-11 4:59 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-01-28 17:34 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Alex Bennée, qemu-devel [-- Attachment #1: Type: text/plain, Size: 3758 bytes --] On Thu, 28 Jan 2021 at 22:00, Gerd Hoffmann <kraxel@redhat.com> wrote: > On Thu, Jan 28, 2021 at 09:20:31PM +0530, Shreyansh Chouhan wrote: > > (Gerd, I wasn't able to get gmail to quote your email, so I have just > copy > > pasted the relavant parts.) > > > > > Yes. net_conf is common config (backend, mac address, maybe more) for > > > network devices. For sound devices that would audiodev (link the > device > > > to a backend which then handles alsa/pulse/jack/oss/sdl/whatever). > > > > Ah I see, so the net_conf corresponds to audiodev? > > Oops. Confused that. nic_conf (struct NICConf) is the common config > for all network devices, not net_conf. > > See DEFINE_NIC_PROPERTIES() in include/net/net.h > > NICConf.peers (exposed as "netdev" property) links the emulated device > (frontend) to a netdev (backend) which actually processes the packets > sent by the guest. > > In a simliar way the audiodev property links the emulated audio device > to a backend which handles the host-side audio playback using alsa, > pulseaudio or something else. > > > I thought it would correspond to `virtio_snd_conf`. So as alex said, > > `virtio_snd_conf` is the front end configuration. > > Correct. > > The backend is configured separately, i.e. > > -netdev user,id=net0,$moreargs > > or > > -audiodev alsa,id=snd0,$moreargs > > Then the two are linked by id, i.e. > > -device virtio-net-pci,netdev=net0 > > or > > -device virtio-sound-pci,audiodev=snd0 > Ah ha! So `virtio-snd-conf` corresponds to the `-device` configuration and `audiodev` to the backend configuration. I think the audio code now makes more sense to me. I will give it another read. > > The only thing really required is the audiodev property. Everything > > > else can be hard-coded initially, and once the basics are working > > > refined (like adding properties for jack labels, ...). > > > > So in the realize function I set up the audiodev, right? Also in that > case > > why the difference between the net and sound devices? In the net > > device we set up the common config in net_conf. Does the net_conf > > somehow later sets up NetDev too? > > > > And what is a NetClientState? Is the NetClient the emulated guest? This > > confuses me a lot. I can't understand what will be the parellel audio > device > > property. > > Not fully sure what NetClientState is, I guess it is shared struct for > both frontend and backend to manage the connection state. > > The audio subsystem has simliar structs, SWVoiceIn and SWVoiceOut for > example. There also is QEMUSoundCard. I'd suggest to check out the > source code of other audio devices for code examples. > I will read it and revert back if I have any queries. > > > Also I can't seem to find where we parse the command line options > > passed to qemu. The code structure is a bit different from what I had > > expected. In virtio_net_device_realize we set duplex to half or full > > depending on the value of the net_conf.duplex_str. But I couldn't find > > where we actually set it. > > See virtio_net_properties[]. There is a line in the array: > > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), > I thought this just declared a property, and didn't set it. But now that in retrospect we already declared the variable when we defined the struct so that doesn't make sense. > > And the whole array is registered using: > > device_class_set_props(dc, virtio_net_properties); > > That is enough to make those properties work, the qemu core handles > everything for you. See hw/core/qdev-properties.c if you are curious, > but you can also just consider that a black box at service for you ;) > I think I will give it a quick look :P > > take care, > Gerd > > Thanks a lot! -- Shreyansh [-- Attachment #2: Type: text/html, Size: 5193 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-01-28 17:34 ` Shreyansh Chouhan @ 2021-02-11 4:59 ` Shreyansh Chouhan 2021-02-15 14:39 ` Gerd Hoffmann 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-02-11 4:59 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Alex Bennée, qemu-devel [-- Attachment #1: Type: text/plain, Size: 3808 bytes --] On Thu, 28 Jan 2021 at 23:04, Shreyansh Chouhan < chouhan.shreyansh2702@gmail.com> wrote: > I think I will give it a quick look :P > This certainly wasn't quick I admit. > Thanks a lot! > -- > Shreyansh > > Hey! I hope you people are doing fine. :) So colleges reopened and I was a bit busy for the past 2 weeks. Although I did get to work on this on weekends. So about the audiodev setup, I checked the source code on how it is setup, and I found out I did not really have to do a lot for that. QEMU already registers the audiodev passed on command line and later makes it to an audiostate, and adds it to the list of audiostates. And when the device option is parsed, all its properties are set via the visitors iirc. So all I had to do was make a new device type, define a QEMUSoundCard property and register it, and this should be enough to set the audio state for the QEMUSoundCard in this new device. Do correct me if I am wrong here. (audiostates in turn contain the audiodev) I have some code written, but it is a bit incomplete and I would like to complete at least the initialization part before sending in patches for review. I wanted to ask some questions (again :P) regarding a few things. I read the source code for the `gus` sound device. (gus.c) And set up the audiosettings and SWVoiceOut from there. Here is my first question, I feel as if SWVoiceOut should be available per stream. So the `VirtIOSound` device would have a list of `SWVoiceOut`? Secondly I saw in the `ac97.c` source, (which is a PCI sound device,) a lot of PCIDev related set up in the realize function, but they were not present in the `virtio-net.c` source. Do I need them? (`ac97.c` set up PCI_COMMAND, PCI_STATUS, PCI_BASE_ADDRESS and similar things in PCIDev. For now the pci setup in `virtio-snd-pci.c` basically mimics `virtio-net-pci.c` which uses a `VirtIOPCIProxy` obj.) Thirdly, the properties are registered at two different places, once in the `virtio-net.c` source and once in the `virtio-net-pci.c` source. I understand the the ones in `virito-net.c`/`virtio-snd.c` they are the device properties, as in the configurations we can set for the device and other, well, properties. But what exactly are the properties defined in the `virtio-net-pci.c` source file? I have a vague idea of what they are, but I can't exactly put my finger on it. It's almost as if `virtio-net` and `virito-net-pci` are two different devices each with thier own properties, and the virtio-net-pci helps communication between virtio-net and QEMU guest. It registers using the same `type_init` macro, and that macro registers modules which can later be initialized by QEMU if I am not wrong. Since I didn't get a lot of time I was not able to really dig into the PCI code, and taking a look at it might make things clearer, but once I started writing this mail, I thought I could ask this too. Since there can be more than on streams and more than one jacks, we need to have a list of configurations for them, and since they should be index adressable, should I use an array for them? When I was reading the source I did not come across a QEMU list structure with indexed adressing. If there is one please let me know. Finally, I do understand what the pcm streams are, and I have been able to set them up with hardcoded initial configs (modulo the hda part). But I do not understand what exactly are `jacks` and what should I do to set them up. Which source file should I look at for this? I came across a few jack related structs, but didn't see a device using them. (I did not search for it as vigorously, I only tried grepping in `hw/audio` and the only results were from `intel-hda-defs`. They were comments on enums. Again since I was writing this mail I thought I should ask it here too.) Regards, Shreyansh Chouhan [-- Attachment #2: Type: text/html, Size: 4990 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-02-11 4:59 ` Shreyansh Chouhan @ 2021-02-15 14:39 ` Gerd Hoffmann 2021-04-04 13:55 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Gerd Hoffmann @ 2021-02-15 14:39 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: Alex Bennée, qemu-devel Hi, > I read the source code for the `gus` sound device. (gus.c) And set up the > audiosettings and SWVoiceOut > from there. Here is my first question, I feel as if SWVoiceOut should be > available per stream. Correct. > So the `VirtIOSound` device would have a list of `SWVoiceOut`? In the simplest case just one, most devices have two (one 'out' for playback, one 'in' for recording). Can be more. > Secondly I saw in the `ac97.c` source, (which is a PCI sound device,) a lot > of PCIDev related set up in > the realize function, but they were not present in the `virtio-net.c` > source. Do I need them? (`ac97.c` set > up PCI_COMMAND, PCI_STATUS, PCI_BASE_ADDRESS and similar things in PCIDev. > For now the pci > setup in `virtio-snd-pci.c` basically mimics `virtio-net-pci.c` which uses > a `VirtIOPCIProxy` obj.) In case of a virtio-pci device VirtIOPCIProxy will deal with all the pci details, no need for you to set this up. > Thirdly, the properties are registered at two different places, once in the > `virtio-net.c` source and once > in the `virtio-net-pci.c` source. I understand the the ones in > `virito-net.c`/`virtio-snd.c` they are the device > properties, as in the configurations we can set for the device and other, > well, properties. But what > exactly are the properties defined in the `virtio-net-pci.c` source file? I > have a vague idea of > what they are, but I can't exactly put my finger on it. It's almost as if > `virtio-net` and `virito-net-pci` > are two different devices each with thier own properties, and the > virtio-net-pci helps communication > between virtio-net and QEMU guest. virtio-net-pci.c is a small wrapper which combines virtio-net.c and VirtIOPCIProxy. Most properties virtio-net-pci.c has are just aliases and come from either VirtIOPCIProxy or virtio-net.c > Since there can be more than on streams and more than one jacks, we > need to have a list of configurations for them, and since they should > be index adressable, should I use an array for them? When I was > reading the source I did not come across a QEMU list structure with > indexed adressing. If there is one please let me know. I'd suggest to simply use an array. > Finally, I do understand what the pcm streams are, and I have been able to > set them up with hardcoded > initial configs (modulo the hda part). But I do not understand what exactly > are `jacks` and what should I do to set them up. > Which source file should I look at for this? I came across a few jack > related structs, but didn't see > a device using them. (I did not search for it as vigorously, I only tried > grepping in `hw/audio` and the > only results were from `intel-hda-defs`. They were comments on enums. Again > since I was writing > this mail I thought I should ask it here too.) Jacks are modeled after hda specification. See also hda-codec-common.h They basically describe the inputs and outputs, along the lines of "this output is a green line-out jack / blue line-out jack / speaker / ...". In case of qemu it is all virtual anyway and doesn't matter that much. The guest might show this in the audio config tools though, so it should be something commonly used. hda-duplex for example uses "red line-in" for recording and "green line-out" for playback because those are the colors typically used for these jacks on your laptop. HTH, Gerd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-02-15 14:39 ` Gerd Hoffmann @ 2021-04-04 13:55 ` Shreyansh Chouhan 2021-04-16 11:32 ` Gerd Hoffmann 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-04-04 13:55 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Alex Bennée, qemu-devel [-- Attachment #1: Type: text/plain, Size: 4778 bytes --] Hey everyone! I wrote code for PCM streams, which I'd like to discuss here. But since it isn't really complete yet, I thought I'd ask if I can copy paste the functions that I want to ask about and clear things that way. For now I will just write my queries here and try to explain them as best as I can. Starting off with the get config function for pcm streams. Initially I thought I was supposed to store those configs in the VirtIOSound struct but then I realized these configurations should be queried from the backend and then be presented to the driver/guest. Now, the virtio sound card supports multiple formats and bit rates. If we have fixed settings turned on in the audiodev, the virtio sound card should support only a single freq and frame rate depending upon what was passed to the command line which we can get from audio_get_pdo_out. Is this correct? Secondly if fixed settings was not set, what should the get config query return with for supported formats and bitrates? For now I am returning the formats defined in the enum for the qemu audio subsystem. I read in the man pages that if the mixing engine is off, qemu assumes that the backend supports the the multiple streams and channels that are supported by the virtual card. So should I return everything that the virito sound card can support? Thirdly, for the set params function, how do I change the params for an SWVoiceOut stream? I could not find a function for changing the audsettings for a stream. Should I close the stream and reopen it? Should I directly change the values in the pcm info struct inside the stream? I learned that the callback passed in AUD_open_out, (lets call it the write audio callback,) is supposed to mix and write the buffers to HWVoiceOut. I have written that, the basic algorithm being: 1. Pop element from tx virtqueue. 2. Get the xfer header from the elem->out_sg (iov_to_buf(elem->out_sg, 1, 0, &hdr, sizeof(hdr))) 3. Get the buffer from elem->out_sg (iov_to_buf(elem->out_sg, 1, sizeof(hdr), &mixbuf, period_bytes)) 4. AUD_write the buffer 5. Initialize an VIRTIO_SND_S_OK response. 6. Write the response to elem->in_sg (iov_from_buf(elem->in_sg, elem->in_num, 0, &resp, sizeof(resp))) 7. If tx queue is not empty go back to step 1. I think I can send a period elapsed notification too after reading period_bytes from the tx_virtqueue. Will this be enough? From other sound card implementations I found out about a lot of pointers which I think were read and write pointers for the buffer. But since we are doing this via a virtqueue, I don't feel as if those pointers will be necessary. Also I do not understand what the tx virtqueue handler is supposed to do. I have written a handler for the control queue. But I don't know what to do about the tx queue for now. I thought it would be something similar to what the callback does, it wouldn't play the audio though. Also since the callback does so many things, I do not understand how I can implement the pcm stream prepare, start, stop and release functions. The prepare function is supposed to allocate resources for the stream, but we already do that in the realize_fn for the device (AUD_open_out). So should I move that part out of the realize function and into the prepare stream function? I can then have the write audio callback called in the start stream function. The release function would just g_free the stream. This version would have set_params store the params of the streams in the device itself, or in a new device state structure. Then when prepare is called for a stream, we use the stored audsettings for AUD_open_out. The start function would simply call the virtio_snd_callback and write the audio using AUD_write. I still do not know what I would have to write in the stop stream function. Another thing that I wanted to ask was about the hda codec. The specification mentions that the virtio sound card has a single codec device in it. I saw a lot of codec device related code in hda-codec.c which I think can be re-used for this. But there were no headers that exposed the code elsewhere. After reading through the hda specification I realized that these function group nids all come under the codec, so the jacks will be pin widgets attached to this codec. And the streams will be the streams associated with this codec. But I do not understand how I should go about implementing the codec, or if I need to implement it considering the already existing source from intel-hda and hda-codec.c. Also sorry for the late response, I had fallen ill. Also I had to move thrice in the past month, so I couldn't really work on this a lot, and I didn't want to write a mail without having any work to show to you guys. Thanks a lot for being patient with me. :) Regards, Shreyansh [-- Attachment #2: Type: text/html, Size: 5722 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-04-04 13:55 ` Shreyansh Chouhan @ 2021-04-16 11:32 ` Gerd Hoffmann 2021-04-19 12:30 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Gerd Hoffmann @ 2021-04-16 11:32 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: Alex Bennée, qemu-devel Hi, > Starting off with the get config function for pcm streams. Initially I > thought I was supposed to store those configs in the VirtIOSound > struct but then I realized these configurations should be queried from > the backend and then be presented to the driver/guest. No. The device can completely ignore the backend capabilities. We have mixing-engine and fixed-settings. With mixing-engine=on and fixed-settings=on (default) qemu will mix all streams, resample if needed, and pass a single stream to the backend. mixing-engine=off will turn disable the qemu mixer, the streams are passed as-is to the backend then. This requires fixed-settings=off too (see documentation comments in qapi/audio.json). The backend must handle the settings the device asks for, either by configuring the audio hardware accordingly (oss/alsa), or by passing on the settings to the sound daemon (pulseaudio). > Now, the virtio sound card supports multiple formats and bit rates. If > we have fixed settings turned on in the audiodev, the virtio sound > card should support only a single freq and frame rate depending upon > what was passed to the command line which we can get from > audio_get_pdo_out. Is this correct? No, see above, qemu will resample if needed. > Secondly if fixed settings was not set, what should the get config > query return with for supported formats and bitrates? For now I am > returning the formats defined in the enum for the qemu audio > subsystem. The device can support every format and sample rate which is supported by both qemu and the virtio spec. Whenever it actually makes sense to support outdated formats like S8 is questionable. On the other hand not supporting it will not simplify the code much. Your choice. > Thirdly, for the set params function, how do I change the params for > an SWVoiceOut stream? I could not find a function for changing the > audsettings for a stream. Should I close the stream and reopen it? Call AUD_open_out() again with the new settings. > I learned that the callback passed in AUD_open_out, (lets call it the write > audio callback,) is supposed to mix and write the > buffers to HWVoiceOut. I have written that, the basic algorithm being: > > 1. Pop element from tx virtqueue. > 2. Get the xfer header from the elem->out_sg (iov_to_buf(elem->out_sg, 1, > 0, &hdr, sizeof(hdr))) > 3. Get the buffer from elem->out_sg (iov_to_buf(elem->out_sg, 1, > sizeof(hdr), &mixbuf, period_bytes)) > 4. AUD_write the buffer AUD_write returns the number of bytes actually accepted. In case the audio backend consumed the complete buffer you can go ahead as described. Otherwise stop here and resume (try AUD_write() the remaining data) when the callback is called again. > Also I do not understand what the tx virtqueue handler is supposed to > do. I have written a handler for the control queue. But I don't know > what to do about the tx queue for now. I thought it would be something > similar to what the callback does, it wouldn't play the audio though. The tx handler probably doesn't need to do much if anything in case you do the virtqueue processing in the audio callback as described above. > Also since the callback does so many things, I do not understand how I > can implement the pcm stream prepare, start, stop and release > functions. The prepare function is supposed to allocate resources for > the stream, but we already do that in the realize_fn for the device > (AUD_open_out). So should I move that part out of the realize function > and into the prepare stream function? start/stop maps to AUD_set_active_out(card, true/false); You can probably just ignore prepare + release. > Another thing that I wanted to ask was about the hda codec. The > specification mentions that the virtio sound card has a single codec > device in it. I saw a lot of codec device related code in hda-codec.c > which I think can be re-used for this. But there were no headers that > exposed the code elsewhere. After reading through the hda > specification I realized that these function group nids all come under > the codec, so the jacks will be pin widgets attached to this codec. > And the streams will be the streams associated with this codec. But I > do not understand how I should go about implementing the codec, or if > I need to implement it considering the already existing source from > intel-hda and hda-codec.c. I don't think you can reuse much code, if any. The AC_* #defines in intel-hda-defs.h should be useful though (jack colors etc). Move them to a separate header file is probably a good idea. > Also sorry for the late response, I had fallen ill. Also I had to move > thrice in the past month, so I couldn't really work on this a lot, and > I didn't want to write a mail without having any work to show to you > guys. Thanks a lot for being patient with me. :) No problem. I'm likewise busy or on (easter) vacation at times and fail to send timely answers (sorry for that). HTH & take care, Gerd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-04-16 11:32 ` Gerd Hoffmann @ 2021-04-19 12:30 ` Shreyansh Chouhan 2021-04-19 12:33 ` Shreyansh Chouhan 2021-04-19 13:10 ` Gerd Hoffmann 0 siblings, 2 replies; 36+ messages in thread From: Shreyansh Chouhan @ 2021-04-19 12:30 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Alex Bennée, qemu-devel [-- Attachment #1: Type: text/plain, Size: 2107 bytes --] On Fri, 16 Apr 2021 at 17:02, Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi, > > > I learned that the callback passed in AUD_open_out, (lets call it the > write > > audio callback,) is supposed to mix and write the > > buffers to HWVoiceOut. I have written that, the basic algorithm being: > > > > 1. Pop element from tx virtqueue. > > 2. Get the xfer header from the elem->out_sg (iov_to_buf(elem->out_sg, 1, > > 0, &hdr, sizeof(hdr))) > > 3. Get the buffer from elem->out_sg (iov_to_buf(elem->out_sg, 1, > > sizeof(hdr), &mixbuf, period_bytes)) > > 4. AUD_write the buffer > > AUD_write returns the number of bytes actually accepted. > > In case the audio backend consumed the complete buffer you can go ahead > as described. Otherwise stop here and resume (try AUD_write() the > remaining data) when the callback is called again. > The callback that is supposed to write the buffers to HWVoiceOut has to do it such that it only writes the buffers for the streams that it was called by. The tx virtqueue is going to have buffers for all the streams. How do I handle this situation? Say, I have 3 output streams 0, 1 and 2, the callback was called on stream 0, how do I only play buffers corresponding to this stream? Is there a way by which I could iterate over the virtqeueue? If not then I should probably store the VirtQueueElements corresponding to a specific stream in the stream itself. I have to store the elements because I'd have to write to the response and mark these elements as used, (via virtqueue_push i think.) Also, is virtqueue a 'queue'? I remember reading in the specs that the device can consume the buffers in any order it prefers unless a feature bit is negotiated. So does virtqueue_pop always return the first element that entered the queue? (FIFO?) If it is FIFO, then I think the only way would be to iterate over the virtqueue. However if `virtqueu_pop` does return the last inserted element, I can use `handle_tx > No problem. I'm likewise busy or on (easter) vacation at times and fail > to send timely answers (sorry for that). > > HTH & take care, > Gerd > > [-- Attachment #2: Type: text/html, Size: 2894 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-04-19 12:30 ` Shreyansh Chouhan @ 2021-04-19 12:33 ` Shreyansh Chouhan 2021-04-19 13:10 ` Gerd Hoffmann 1 sibling, 0 replies; 36+ messages in thread From: Shreyansh Chouhan @ 2021-04-19 12:33 UTC (permalink / raw) To: Gerd Hoffmann; +Cc: Alex Bennée, qemu-devel [-- Attachment #1: Type: text/plain, Size: 2614 bytes --] On Mon, 19 Apr 2021 at 18:00, Shreyansh Chouhan < chouhan.shreyansh2702@gmail.com> wrote: > > On Fri, 16 Apr 2021 at 17:02, Gerd Hoffmann <kraxel@redhat.com> wrote: > >> Hi, >> >> > I learned that the callback passed in AUD_open_out, (lets call it the >> write >> > audio callback,) is supposed to mix and write the >> > buffers to HWVoiceOut. I have written that, the basic algorithm being: >> > >> > 1. Pop element from tx virtqueue. >> > 2. Get the xfer header from the elem->out_sg (iov_to_buf(elem->out_sg, >> 1, >> > 0, &hdr, sizeof(hdr))) >> > 3. Get the buffer from elem->out_sg (iov_to_buf(elem->out_sg, 1, >> > sizeof(hdr), &mixbuf, period_bytes)) >> > 4. AUD_write the buffer >> >> AUD_write returns the number of bytes actually accepted. >> >> In case the audio backend consumed the complete buffer you can go ahead >> as described. Otherwise stop here and resume (try AUD_write() the >> remaining data) when the callback is called again. >> > The callback that is supposed to write the buffers to HWVoiceOut has to > do it such that it only writes the buffers for the streams that it was > called by. The tx > virtqueue is going to have buffers for all the streams. How do I handle > this situation? > > Say, I have 3 output streams 0, 1 and 2, the callback was called on stream > 0, how do > I only play buffers corresponding to this stream? Is there a way by which > I could iterate over > the virtqeueue? > > If not then I should probably store the VirtQueueElements corresponding to > a specific stream > in the stream itself. I have to store the elements because I'd have to > write to the response and > mark these elements as used, (via virtqueue_push i think.) > > Also, is virtqueue a 'queue'? I remember reading in the specs that the > device can consume > the buffers in any order it prefers unless a feature bit is negotiated. So > does virtqueue_pop > always return the first element that entered the queue? (FIFO?) > > If it is FIFO, then I think the only way would be to iterate over the > virtqueue. However if `virtqueu_pop` > does return the last inserted element, I can use `handle_tx` > to get the last element inserted and then add it to the corresponding stream. Sorry for the incomplete mail. I don't know how I hit send. > > >> No problem. I'm likewise busy or on (easter) vacation at times and fail >> to send timely answers (sorry for that). >> > Also that's fine, I just got a bit worried :) I think once this `tx` part is done I'll have the pcm streams ready, and I can send in patches by tonight or tomorrow evening latest. > >> HTH & take care, >> Gerd >> >> [-- Attachment #2: Type: text/html, Size: 4255 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-04-19 12:30 ` Shreyansh Chouhan 2021-04-19 12:33 ` Shreyansh Chouhan @ 2021-04-19 13:10 ` Gerd Hoffmann [not found] ` <CAAQ-SiMf=BV-HUudRayZkRPJjmkYWuiBuKqYHHLzYjcFnPOgLQ@mail.gmail.com> 1 sibling, 1 reply; 36+ messages in thread From: Gerd Hoffmann @ 2021-04-19 13:10 UTC (permalink / raw) To: Shreyansh Chouhan; +Cc: Alex Bennée, qemu-devel > > AUD_write returns the number of bytes actually accepted. > > > > In case the audio backend consumed the complete buffer you can go ahead > > as described. Otherwise stop here and resume (try AUD_write() the > > remaining data) when the callback is called again. > > > The callback that is supposed to write the buffers to HWVoiceOut has to > do it such that it only writes the buffers for the streams that it was > called by. The tx > virtqueue is going to have buffers for all the streams. How do I handle > this situation? Well, maybe splitting the streams is a good job for the tx handler, i.e. take the queue element out of the queue, check stream, stick into a stream-specific buffer list. The have the AUD_write callback check the stream buffer list. instead of the virt queue. Make sure you only complete the virtqueue elements after the buffers have been passed to the qemu audiodev completely. Yes, it is perfectly fine to process multiple virtqueue elements at the same time, and out-of-order completion is fine too. HTH, Gerd ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <CAAQ-SiMf=BV-HUudRayZkRPJjmkYWuiBuKqYHHLzYjcFnPOgLQ@mail.gmail.com>]
[parent not found: <20210419135627.dlerwnswhfxt6ciz@sirius.home.kraxel.org>]
[parent not found: <CAAQ-SiM6uWUgHTS5PQ-hSkuXNOoKC7fw6Y1ZHhJ0MCUE3oaBqg@mail.gmail.com>]
[parent not found: <20210420071304.gmndase3r6mwp5yt@sirius.home.kraxel.org>]
[parent not found: <CAAQ-SiPPNK0xqnPPSjNZgwQCs+Vj0_A5koq5xK8HzhZKDgqVJw@mail.gmail.com>]
* Re: Fwd: VirtioSound device emulation implementation [not found] ` <CAAQ-SiPPNK0xqnPPSjNZgwQCs+Vj0_A5koq5xK8HzhZKDgqVJw@mail.gmail.com> @ 2021-12-29 5:52 ` Shreyansh Chouhan 2022-01-20 10:39 ` Laurent Vivier 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2021-12-29 5:52 UTC (permalink / raw) To: Gerd Hoffmann, qemu-devel [-- Attachment #1: Type: text/plain, Size: 869 bytes --] Hi, I am sorry for the absence of activity on this. A couple of people very close to me died, and I also got busy with the linux kernel mentorship program for a while. It was a weird year. But I am back on this now. I have the basic functionality of the sound card working. I tested it on an ubuntu vm and it plays audio just fine. I'd like to test other things like changing stream parameters and channel maps. Also the VIRTIO_SND_PCM_F_MSG_POLLING, VIRTIO_SND_PCM_F_EVT_SHMEM_PERIODS, VIRTIO_SND_PCM_F_EVT_XRUNS features aren't implemented yet. Implementing VIRTIO_SND_PCM_F_EVT_SHMEM_PERIODS hopefully shouldn't be much of a challenge. We can send a notification when we have processed period bytes (if I correctly understand this). I will send another rfc patch series once I have channel maps and jacks ready. And one more when I have these PCM features ready. [-- Attachment #2: Type: text/html, Size: 1047 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2021-12-29 5:52 ` Shreyansh Chouhan @ 2022-01-20 10:39 ` Laurent Vivier 2022-02-07 4:06 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Laurent Vivier @ 2022-01-20 10:39 UTC (permalink / raw) To: Shreyansh Chouhan, Gerd Hoffmann, qemu-devel Le 29/12/2021 à 06:52, Shreyansh Chouhan a écrit : > Hi, > > I am sorry for the absence of activity on this. A couple of people very close to me died, and I also > got busy > with the linux kernel mentorship program for a while. It was a weird year. But I am back on this now. > > I have the basic functionality of the sound card working. I tested it on an ubuntu vm and it plays > audio just fine. I'd like to test > other things like changing stream parameters and channel maps. Also the VIRTIO_SND_PCM_F_MSG_POLLING, > VIRTIO_SND_PCM_F_EVT_SHMEM_PERIODS, VIRTIO_SND_PCM_F_EVT_XRUNS features aren't implemented yet. > Implementing VIRTIO_SND_PCM_F_EVT_SHMEM_PERIODS hopefully shouldn't be much of a challenge. We can > send a notification > when we have processed period bytes (if I correctly understand this). > > I will send another rfc patch series once I have channel maps and jacks ready. And one more when I > have these PCM features > ready. Hi, I'm trying to test your RFC series but I have a core dump (using alsa-utils speaker-test), do you have an updated branch I could pull? Thanks, Laurent ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2022-01-20 10:39 ` Laurent Vivier @ 2022-02-07 4:06 ` Shreyansh Chouhan 2022-02-08 17:26 ` Shreyansh Chouhan 0 siblings, 1 reply; 36+ messages in thread From: Shreyansh Chouhan @ 2022-02-07 4:06 UTC (permalink / raw) To: Laurent Vivier; +Cc: Gerd Hoffmann, qemu-devel On Thu, 20 Jan 2022 at 16:09, Laurent Vivier <laurent@vivier.eu> wrote: > > Le 29/12/2021 à 06:52, Shreyansh Chouhan a écrit : > > Hi, > > > > I am sorry for the absence of activity on this. A couple of people very close to me died, and I also > > got busy > > with the linux kernel mentorship program for a while. It was a weird year. But I am back on this now. > > > > I have the basic functionality of the sound card working. I tested it on an ubuntu vm and it plays > > audio just fine. I'd like to test > > other things like changing stream parameters and channel maps. Also the VIRTIO_SND_PCM_F_MSG_POLLING, > > VIRTIO_SND_PCM_F_EVT_SHMEM_PERIODS, VIRTIO_SND_PCM_F_EVT_XRUNS features aren't implemented yet. > > Implementing VIRTIO_SND_PCM_F_EVT_SHMEM_PERIODS hopefully shouldn't be much of a challenge. We can > > send a notification > > when we have processed period bytes (if I correctly understand this). > > > > I will send another rfc patch series once I have channel maps and jacks ready. And one more when I > > have these PCM features > > ready. > Hi, > > Hi, > > I'm trying to test your RFC series but I have a core dump (using alsa-utils speaker-test), do you > have an updated branch I could pull? Yes, I will send the updated RFC by tomorrow (Tuesday). Thanks, Shreyansh Chouhan > > > Thanks, > Laurent ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Fwd: VirtioSound device emulation implementation 2022-02-07 4:06 ` Shreyansh Chouhan @ 2022-02-08 17:26 ` Shreyansh Chouhan 0 siblings, 0 replies; 36+ messages in thread From: Shreyansh Chouhan @ 2022-02-08 17:26 UTC (permalink / raw) To: Laurent Vivier; +Cc: Gerd Hoffmann, qemu-devel On Mon, 7 Feb 2022 at 09:36, Shreyansh Chouhan <chouhan.shreyansh2702@gmail.com> wrote: > > On Thu, 20 Jan 2022 at 16:09, Laurent Vivier <laurent@vivier.eu> wrote: > > > > > > Hi, > > > > I'm trying to test your RFC series but I have a core dump (using alsa-utils speaker-test), do you > > have an updated branch I could pull? > > Yes, I will send the updated RFC by tomorrow (Tuesday). > Sorry I won't be able to send it in today. I have the sound card ready but I have yet to fix some things from the comments on the previous RFC. I joined at a new position today and was expecting to be able to work on this after work ended. I still haven't been able to complete the patches. I will send the updated patch series latest by Friday. Thanks, Shreyansh Chouhan > Thanks, > Shreyansh Chouhan > > > > > > > Thanks, > > Laurent ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2022-02-08 17:54 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-06 10:00 VirtioSound device emulation implementation Shreyansh Chouhan 2021-01-06 11:40 ` Alex Bennée 2021-01-07 14:58 ` Shreyansh Chouhan 2021-01-07 15:58 ` Gerd Hoffmann 2021-01-07 17:17 ` Alex Bennée 2021-01-08 7:53 ` Shreyansh Chouhan 2021-01-08 8:34 ` Gerd Hoffmann 2021-01-10 8:25 ` Shreyansh Chouhan [not found] ` <CAAQ-SiPiq5NQN=2mvP3isZ9PtYO2Bu64kVEvE6T+3OJd5B-U5A@mail.gmail.com> 2021-01-11 6:29 ` Fwd: " Shreyansh Chouhan 2021-01-11 11:59 ` Alex Bennée 2021-01-14 15:00 ` Shreyansh Chouhan 2021-01-14 17:41 ` Alex Bennée 2021-01-15 8:00 ` Shreyansh Chouhan 2021-01-17 10:30 ` Shreyansh Chouhan 2021-01-18 18:53 ` Shreyansh Chouhan 2021-01-20 11:41 ` Shreyansh Chouhan 2021-01-25 6:02 ` Shreyansh Chouhan 2021-01-25 11:23 ` Alex Bennée 2021-01-28 4:28 ` Shreyansh Chouhan 2021-01-28 10:42 ` Alex Bennée 2021-01-28 15:40 ` Shreyansh Chouhan 2021-01-28 11:25 ` Gerd Hoffmann 2021-01-28 15:50 ` Shreyansh Chouhan 2021-01-28 16:30 ` Gerd Hoffmann 2021-01-28 17:34 ` Shreyansh Chouhan 2021-02-11 4:59 ` Shreyansh Chouhan 2021-02-15 14:39 ` Gerd Hoffmann 2021-04-04 13:55 ` Shreyansh Chouhan 2021-04-16 11:32 ` Gerd Hoffmann 2021-04-19 12:30 ` Shreyansh Chouhan 2021-04-19 12:33 ` Shreyansh Chouhan 2021-04-19 13:10 ` Gerd Hoffmann [not found] ` <CAAQ-SiMf=BV-HUudRayZkRPJjmkYWuiBuKqYHHLzYjcFnPOgLQ@mail.gmail.com> [not found] ` <20210419135627.dlerwnswhfxt6ciz@sirius.home.kraxel.org> [not found] ` <CAAQ-SiM6uWUgHTS5PQ-hSkuXNOoKC7fw6Y1ZHhJ0MCUE3oaBqg@mail.gmail.com> [not found] ` <20210420071304.gmndase3r6mwp5yt@sirius.home.kraxel.org> [not found] ` <CAAQ-SiPPNK0xqnPPSjNZgwQCs+Vj0_A5koq5xK8HzhZKDgqVJw@mail.gmail.com> 2021-12-29 5:52 ` Shreyansh Chouhan 2022-01-20 10:39 ` Laurent Vivier 2022-02-07 4:06 ` Shreyansh Chouhan 2022-02-08 17:26 ` Shreyansh Chouhan
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 NNTP newsgroup(s).