linux-kernel - Re: [Xen-devel] [RFC v1] ALSA: xen-front: 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]

Message-ID: <9031a8b0-88c2-bd86-548c-7dbcf8967856@gmail.com>
Date:   Mon, 11 Dec 2017 10:45:27 +0200
From:   Oleksandr Andrushchenko <andr2000@...il.com>
To:     Oleksandr Andrushchenko <Oleksandr_Andrushchenko@...m.com>,
        tiwai@...e.com, alsa-devel@...a-project.org,
        linux-kernel@...r.kernel.org,
        xen-devel <xen-devel@...ts.xenproject.org>,
        Clemens Ladisch <clemens@...isch.de>,
        Takashi Sakamoto <o-takashi@...amocchi.jp>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [Xen-devel] [RFC v1] ALSA: xen-front: Add Xen para-virtualized
 frontend driver

ping

On 11/17/2017 10:08 AM, Oleksandr Andrushchenko wrote:
> ping
>
> On 11/02/2017 03:11 PM, Oleksandr Andrushchenko wrote:
>> Hi, all!
>>
>> Foreword
>> ========
>>
>> This RFC is aimed to introduce support of para-virtualized sound 
>> frontend
>> driver for Xen [1] and gather opinions from the relevant communities
>> (ALSA, Xen). It implements the protocol from [2] with the
>> following limitations:
>>   - mute/unmute is not supported
>>   - get/set volume is not supported
>> Volume control is not supported for the reason that most of the 
>> use-cases
>> (at the moment) are based on scenarios where unprivileged OS
>> (e.g. Android, AGL etc) uses software mixers.
>> Both capture and playback are supported.
>>
>> The relevant backend is implemented as a user-space application [3]
>> and uses accompanying helper library [4].
>>
>> Both frontend driver and backend were tested on real HW running Xen 
>> hypervisor
>> (Renesas R-Car ARM based H3/M3 boards, x86).
>>
>> Discussion
>> ==========
>>
>> During the first attempt to upstream the driver [5] number of 
>> comments and
>> concerns were raised, one of the biggest flaws in the design were 
>> questioned
>> by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of
>> synchronization between frontend and backend during capture/playback.
>> Two options were discussed:
>>
>> “In design of ALSA PCM core, drivers are expected to synchronize to
>> actual hardwares for semi-realtime data transmission. The
>> synchronization is done by two points:
>> 1) Interrupts to respond events from actual hardwares.
>> 2) Positions of actual data transmission in any serial sound interfaces
>>     of actual hardwares.
>> “
>>
>> and finally a change to the existing protocol was suggested:
>>
>> “In 'include/xen/interface/io/sndif.h', there's no functionalities I
>> described the above:
>> 1. notifications from DomU to Dom0 about the size of period for
>>     interrupts from actual hardwares. Or no way from Dom0 to DomU about
>>     the configured size of the period.
>> 2. notifications of the interrupts from actual hardwares to DomU.”
>>
>> This is implemented as a change to the sndif protocol [8] and allows 
>> removing
>> period emulation:
>> 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 (in Linux
>>    implementation). 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.
>>
>> Along with these changes other comments on the driver were addressed,
>> e.g. split into smaller chunks, moved the driver from misc to xen etc.
>>
>>
>> Hope, this helps to get the full picture of what was discussed and 
>> makes it
>> possible to move forward.
>>
>> Waiting for your valuable comments,
>>
>> Thank you,
>> Oleksandr
>>
>> [1] https://github.com/andr2000/linux/commits/snd_upstream_v1
>> [2] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
>> [3] https://github.com/xen-troops/snd_be
>> [4] https://github.com/xen-troops/libxenbe
>> [5] https://lkml.org/lkml/2017/8/7/363
>> [6] 
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html
>> [7] 
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html
>> [8] 
>> https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@...ts.xen.org
>> https://lists.xen.org/xen-devel
>