linux-kernel - [RFC] 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:   Mon, 30 Oct 2017 08:33:46 +0200
From:   Oleksandr Andrushchenko <Oleksandr_Andrushchenko@...m.com>
To:     tiwai@...e.com, alsa-devel@...a-project.org,
        linux-kernel@...r.kernel.org, xen-devel@...ts.xen.org,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:     Oleksandr Andrushchenko <andr2000@...il.com>,
        Oleksandr Grytsov <al1img@...il.com>,
        Clemens Ladisch <clemens@...isch.de>,
        Takashi Sakamoto <o-takashi@...amocchi.jp>
Subject: [RFC] ALSA: vsnd: Add Xen para-virtualized frontend driver

Hi, all!

This is an attempt to summarize previous discussions on Xen para-virtual
sound driver.

A first attempt has been made to upstream the driver [1] which brought 
number
of fundamental questions, one of the biggest ones was that the frontend 
driver
has no means to synchronize its period elapsed event with the host driver,
but uses software emulation on the guest side [2] with a timer.
In order to address this a change to the existing Xen para-virtual sound
protocol [3] was proposed to fill this gap [4] and remove 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. [5].

Hope, this helps to get the full picture of what was discussed and makes it
possible to move forward: if the approach seems ok, then I'll start
upstreaming the changes to the sndif protocol and then will send the 
updated
version of the driver for the further review.

Thank you,
Oleksandr

[1] https://lkml.org/lkml/2017/8/7/363
[2] https://lkml.org/lkml/2017/8/9/1167
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h
[4] https://lkml.org/lkml/2017/9/19/121
[5] https://github.com/andr2000/linux/tree/snd_upstream_v1/sound/xen