Para-virtualized audio drivers

Para-virtualized audio drivers

[Ughreja, Rakesh A]

Hi Takashi and all,

I have some need to develop para virtualized audio drivers which can
work with XEN hypervisor.

I see some attempt was made in the past.
https://lists.xen.org/archives/html/xen-devel/2015-01/msg02125.html

I see one more material but with no code.
http://rd.springer.com/chapter/10.1007%2F978-94-007-2105-0_46

I am thinking to develop pv-audio-frontend (running on Dom1) and 
pv-audio-backend (running on Dom0) drivers all at kernel level.
Backend driver owns the hardware. Frontend driver communicates with 
backend driver using XENbus framework just like storage and network PV
drivers.

Before I start, I wanted to check if there is any other
work that has been done which I can take as base ?

Regards,
Rakesh

Re: Para-virtualized audio drivers

[Liam Girdwood]

On Mon, 2016-10-17 at 03:01 +0000, Ughreja, Rakesh A wrote:
> Hi Takashi and all,
> 
> I have some need to develop para virtualized audio drivers which can
> work with XEN hypervisor.
> 
> I see some attempt was made in the past.
> https://lists.xen.org/archives/html/xen-devel/2015-01/msg02125.html
> 
> I see one more material but with no code.
> http://rd.springer.com/chapter/10.1007%2F978-94-007-2105-0_46
> 
> I am thinking to develop pv-audio-frontend (running on Dom1) and 
> pv-audio-backend (running on Dom0) drivers all at kernel level.
> Backend driver owns the hardware. Frontend driver communicates with 
> backend driver using XENbus framework just like storage and network PV
> drivers.
> 
> Before I start, I wanted to check if there is any other
> work that has been done which I can take as base ?
> 

Fwiw, I've done something similar over 2 VMs for the audio DSP on
Baytrail. i.e. one VM is x86 Qemu/KVM running the host OS and kernel,
whilst the other VM is xtensa Qemu running the DSP firmware.

Details here :-

http://alsa-project.org/main/index.php/Firmware#Using_the_Qemu_DSP_emulator

Liam

Re: Para-virtualized audio drivers

[Takashi Iwai]

On Mon, 17 Oct 2016 05:01:47 +0200,
Ughreja, Rakesh A wrote:
> 
> Hi Takashi and all,
> 
> I have some need to develop para virtualized audio drivers which can
> work with XEN hypervisor.
> 
> I see some attempt was made in the past.
> https://lists.xen.org/archives/html/xen-devel/2015-01/msg02125.html
> 
> I see one more material but with no code.
> http://rd.springer.com/chapter/10.1007%2F978-94-007-2105-0_46
> 
> I am thinking to develop pv-audio-frontend (running on Dom1) and 
> pv-audio-backend (running on Dom0) drivers all at kernel level.
> Backend driver owns the hardware. Frontend driver communicates with 
> backend driver using XENbus framework just like storage and network PV
> drivers.
> 
> Before I start, I wanted to check if there is any other
> work that has been done which I can take as base ?

I don't know of any other existing implementation for Xen.  The
question would be rather how you would implement the backend.

Is it about Intel hardware as Liam has been working on?  Or is it
targeted as a generic Xen stuff like the patches you mentioned in the
above?  The patchset above was about the user-space backend, IIRC.


Takashi

Re: Para-virtualized audio drivers

[Ughreja, Rakesh A]

>>
>> I am thinking to develop pv-audio-frontend (running on Dom1) and
>> pv-audio-backend (running on Dom0) drivers all at kernel level.
>> Backend driver owns the hardware. Frontend driver communicates with
>> backend driver using XENbus framework just like storage and network PV
>> drivers.
>>
>> Before I start, I wanted to check if there is any other
>> work that has been done which I can take as base ?
>
>I don't know of any other existing implementation for Xen.  The
>question would be rather how you would implement the backend.
>

My thinking is to have backend driver at kernel level. The backend
driver would receive requests from frontend driver. I agree that the
previous effort was to develop it in user space.

>Is it about Intel hardware as Liam has been working on?  Or is it

Liam's work is different.

>targeted as a generic Xen stuff like the patches you mentioned in the
>above?  The patchset above was about the user-space backend, IIRC.
>

I am trying to develop generic PV audio drivers for XEN. I see people 
have developed PV Storage and Network drivers in XEN and they
are up-streamed. So I was thinking to do that for audio as well.

Do you recall why the above patchset was not merged ?
any limitations or was it incomplete ? 

Regards,
Rakesh


>
>Takashi

Re: Para-virtualized audio drivers

[Takashi Iwai]

On Thu, 20 Oct 2016 19:02:42 +0200,
Ughreja, Rakesh A wrote:
> 
> >>
> >> I am thinking to develop pv-audio-frontend (running on Dom1) and
> >> pv-audio-backend (running on Dom0) drivers all at kernel level.
> >> Backend driver owns the hardware. Frontend driver communicates with
> >> backend driver using XENbus framework just like storage and network PV
> >> drivers.
> >>
> >> Before I start, I wanted to check if there is any other
> >> work that has been done which I can take as base ?
> >
> >I don't know of any other existing implementation for Xen.  The
> >question would be rather how you would implement the backend.
> >
> 
> My thinking is to have backend driver at kernel level. The backend
> driver would receive requests from frontend driver. I agree that the
> previous effort was to develop it in user space.
> 
> >Is it about Intel hardware as Liam has been working on?  Or is it
> 
> Liam's work is different.
> 
> >targeted as a generic Xen stuff like the patches you mentioned in the
> >above?  The patchset above was about the user-space backend, IIRC.
> >
> 
> I am trying to develop generic PV audio drivers for XEN. I see people 
> have developed PV Storage and Network drivers in XEN and they
> are up-streamed. So I was thinking to do that for audio as well.
> 
> Do you recall why the above patchset was not merged ?
> any limitations or was it incomplete ? 

I don't remember it well.  I guess I wasn't involved with that
discussion since I was off when it was posted or so.  Since then there
was little attention gathered, unfortunately.


Takashi