linux-kernel - Re: [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 26 Sep 2017 14:35:20 +0300
From:   Oleksandr Andrushchenko <andr2000@...il.com>
To:     Oleksandr Grytsov <al1img@...il.com>,
        Clemens Ladisch <clemens@...isch.de>,
        Takashi Sakamoto <o-takashi@...amocchi.jp>, tiwai@...e.com
Cc:     alsa-devel@...a-project.org,
        Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>,
        linux-kernel@...r.kernel.org, xen-devel@...ts.xen.org,
        Oleksandr Grytsov <oleksandr_grytsov@...m.com>
Subject: Re: [alsa-devel] [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen
 para-virtualized frontend driver

Clemens, Sakamoto-san,

could you please review the below if you by chance have a minute?

Thank you,
Oleksandr

On 09/19/2017 11:57 AM, Oleksandr Andrushchenko wrote:
> Hi, all!
>
> We did some work on implementing the idea with
>
> feedback events from the backend to the frontend.
>
> Please see attached the changes to the existing sndif protocol [1]:
>
> 1. Introduced a new event channel from back to front
>
> 2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS,
>
> to be used for sending snd_pcm_period_elapsed at frontend.
>
> Sent in bytes, not frames to make the protocol generic and consistent)
>
> 3. New request for playback/capture control (XENSND_OP_TRIGGER)
>
> with start/pause/stop/resume sub-ops.
>
> The implementation we have showed that this is sufficient to
> successfully play/capture w/o using emulated interrupts.
>
> Clemens, Sakamoto-san,
> could you please review the changes and confirm that these are ok to
> be upstreamed to the sndif protocol and are enough for the frontend
> driver we want to upstream (we have it implemented, just need to make
> sure the general approach is accepted by the ALSA community).
>
> Thank you very much for your time,
> Oleksandr Andrushchenko
> Oleksandr Grytsov
>
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h?h=v4.14-rc1
>
> On 09/12/2017 10:52 AM, Oleksandr Grytsov wrote:
>> On Tue, Sep 5, 2017 at 10:24 AM, Clemens Ladisch <clemens@...isch.de> 
>> wrote:
>>> Oleksandr Andrushchenko wrote:
>>>>>> We understand that emulated interrupt on the frontend side is 
>>>>>> completely not
>>>>>> acceptable
>>> Allow me to expand on that:  Proper synchronization requires that the
>>> exact position is communicated, not estimated.  Just because the 
>>> nominal
>>> rate of the stream is known does not imply that you know the actual 
>>> rate.
>>> Forget for the moment that there even is a nominal rate; assume that it
>>> works like, e.g., a storage controller, and that you can know that a 
>>> DMA
>>> buffer was consumed by the device only after it has told you.
>>>
>>> It's possible and likely that there is a latency when reporting the
>>> stream position, but that is still better than guessing what the DMA
>>> is doing.  (You would never just try to guess when writing data to
>>> disk, would you?)
>>>
>>>>>> and definitely we need to provide some feedback mechanism from
>>>>>> Dom0 to DomU.
>>>>>>
>>>>>> In our case it is technically impossible to provide precise 
>>>>>> period interrupt
>>>>>> (mostly because our backend is a user space application).
>>> As far as I can see, all audio APIs (ALSA, PulseAudio, etc.) have 
>>> poll()
>>> or callbacks or similar mechanisms to inform you when new data can be
>>> written, and always allow to query the current position.
>>>
>>>> [...]
>>>> ok, so the main concern here is that we cannot properly synchronize 
>>>> Dom0-DomU.
>>>> If we put this apart for a second are there any other concerns on 
>>>> having ALSA
>>>> frontend driver? If not, can we have the driver with timer 
>>>> implementation upstreamed
>>>> as experimental until we have some acceptable synchronization 
>>>> solution?
>>>> This will allow broader audience to try and feel the solution and 
>>>> probably contribute?
>>> I doubt that the driver architecture will stay completely the same, 
>>> so I
>>> do not think that this experimental driver would demonstrate how the
>>> solution would feel.
>>>
>>> As the first step, I would suggest creating a driver with proper
>>> synchronization, even if it has high latency.  Reducing the latency
>>> would then be 'just' an optimization.
>>>
>>>
>>> Regards,
>>> Clemens
>> Definitely feedback from the backend side is required. Currently
>> we are working on synchronized version on the backend
>> and frontend side. We will be back once we have the solution.
>>
>> Thanks.
>