Hi, Dmitry!
On 06/29/2017 10:24 PM, Dmitry Torokhov wrote:
On June 29, 2017 11:40:30 AM PDT, Oleksandr Andrushchenko
wrote:
Hi, Dmitry!
First of all thank you for both the comments and the patch
On 06/29/2017 11:17 AM, Dmitry Torokhov wrote:
Hi Oleksandr,
On Fri, Jun 23, 2017 at 09:09
Hi, Owen!
On 07/03/2017 03:57 PM, Owen Smith wrote:
determine the difference between older
backends and newer backends. In the case I'm interested in, the difference
between old QEMU vkbd backend which blocks waiting for the vfb device, which
is not present on HVM guests, and a newer QEMU backen
Hi, all!
This is a follow-up on Xen distribution build systems we saw at the
summit and invitation for sharing thoughts and ways we build our images and
distros. I would like to specifically ask OpenXT project to reply with the
description of their build system so we have clear picture of what is
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
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
gentle reminder
On 09/26/2017 02:35 PM, Oleksandr Andrushchenko wrote:
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
ksandr
On 03/23/2017 05:40 PM, Oleksandr Andrushchenko wrote:
Hi, all!
I am trying to implement a zero-copy scenario for DRM front/back,
e.g. buffers allocated by DomU in the DRM frontend used as is
by Dom0. The requirement I have is that the buffer is contiguous.
So, what I currently have i
or hide this translation in Xen specific code.
Another question is that for phys_to_dma we have __pfn_to_mfn,
but there is no reverse translation , e.g. __mfn_to_pfn
Cheers,
Stefano
Thank you,
Oleksandr
On Mon, 27 Mar 2017, Oleksandr Andrushchenko wrote:
Hi, all!
First of all this could be
ping
On 03/20/2017 10:56 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle
ping
On 03/20/2017 09:03 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add ABI for the two halves of a para-virtualized
sound driver to communicate with each other.
The ABI allows implementing audio playback and capture as
well as volume control and possibility to mute
indeed, this seems to be the case
So, in that mail thread we have the following statement:
"However, if that's not the case in any of the drivers, it
would lead to memory corruptions." with respect to get_sgtable
and pfn != mfn.
So, do you guys think I'll have to patch the offending driver?
An
dealing with sg_table here.
On 03/28/2017 10:20 PM, Stefano Stabellini wrote:
On Tue, 28 Mar 2017, Oleksandr Andrushchenko wrote:
Hi, Stefano!
On 03/27/2017 11:23 PM, Stefano Stabellini wrote:
Hello Oleksandr,
Just to clarify, you are talking about dma_to_phys/phys_to_dma in Linux
(not in Xen
Hi, Stefano
Unfortunately I had to switch to other tasks,
but I'll get back to this issue asap
Thank you
On 03/30/2017 01:36 AM, Stefano Stabellini wrote:
On Wed, 29 Mar 2017, Oleksandr Andrushchenko wrote:
Hi, Stefano!
Ok, probably I need to put more details into the use-case
so
d to DISPL, protocol made generic
* major re-work addressing issues raised for sndif
Signed-off-by: Oleksandr Grytsov
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/public/io/displif.h | 847
1 file changed, 847 insertions(+)
create mode 10
On 04/04/2017 11:07 PM, Konrad Rzeszutek Wilk wrote:
.snip..
+ *- Protocol version --
+ *
+ * version
+ * Values:
+ *
+ * Protocol version, chosen among the ones supported by the backend.
+ *
..snip..
+#define XENDISPL
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention
For your convenience, PFA diff between v4..v5
Thank you,
Oleksandr
On 04/05/2017 09:09 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
On 04/05/2017 04:33 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Apr 05, 2017 at 09:09:07AM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
.. snip..
---
..snip..
Signed-off-by: Oleksandr Grytsov
Signed-off-by: Oleksandr Andrushchenko
Please in the future to put these
From: Oleksandr Andrushchenko
Hi, all!
This patch series adds/updates para-virtual device
protocols for Linux Kernel (headers):
o kbdif (multitouch support added)
o sndif - sound (new)
o displif - display (new)
No changes, but Linux Kernel coding style applied.
Thank you,
Oleksandr
From: Oleksandr Andrushchenko
Multi-touch fields re-use the page that is used by the other features
which means that you can interleave multi-touch, motion, and key
events.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Stefano Stabellini
Signed-off-by: Oleksandr Andrushchenko
---
include
From: Oleksandr Andrushchenko
Add ABI for the two halves of a para-virtualized
sound driver to communicate with each other.
The ABI allows implementing audio playback and capture as
well as volume control and possibility to mute/unmute
audio sources.
Note: depending on the use-case backend can
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention
From: Oleksandr Andrushchenko
The patch clarifies the protocol that is used by the PV keyboard
drivers.
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Stefano Stabellini
Signed-off-by: Oleksandr Andrushchenko
---
include/xen/interface/io/kbdif.h | 258
+Juergen
On 04/07/2017 11:30 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, all!
This patch series adds/updates para-virtual device
protocols for Linux Kernel (headers):
o kbdif (multitouch support added)
o sndif - sound (new)
o displif - display (new)
No changes
On 04/07/2017 03:45 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Apr 07, 2017 at 01:29:27PM +0200, Juergen Gross wrote:
On 07/04/17 10:30, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
The patch clarifies the protocol that is used by the PV keyboard
drivers.
Reviewed-by: Konrad
Hi, all and ping2
I am also interested in the destiny of this patch
as I am planning to base multi-touch support on it
Dmitry, I would appreciate if you could review the patch
as it is hanging around for quite a while now
Thank you,
Oleksandr
On 04/04/2017 02:58 PM, Juergen Gross wrote:
On
Hi, Julien!
On 04/07/2017 04:50 PM, Julien Grall wrote:
Hi Oleksandr,
On 07/04/17 09:30, Oleksandr Andrushchenko wrote:
+/*
+
**
+ *Back to front events delivery
On 04/07/2017 07:36 PM, Stefano Stabellini wrote:
On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote:
Hi, Julien!
On 04/07/2017 04:50 PM, Julien Grall wrote:
Hi Oleksandr,
On 07/04/17 09:30, Oleksandr Andrushchenko wrote
On 04/07/2017 08:50 PM, Stefano Stabellini wrote:
On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote:
On 04/07/2017 07:36 PM, Stefano Stabellini wrote:
On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote:
Hi, Julien!
On 04/07/2017 04:50 PM, Julien Grall wrote:
Hi Oleksandr,
On 07/04/17 09:30
On 04/10/2017 09:03 AM, Juergen Gross wrote:
On 07/04/17 16:02, Oleksandr Andrushchenko wrote:
Hi, Julien!
On 04/07/2017 04:50 PM, Julien Grall wrote:
Hi Oleksandr,
On 07/04/17 09:30, Oleksandr Andrushchenko wrote
From: Oleksandr Andrushchenko
Multi-touch fields re-use the page that is used by the other features
which means that you can interleave multi-touch, motion, and key
events.
Acked-by: Juergen Gross
Signed-off-by: Oleksandr Andrushchenko
---
include/xen/interface/io/kbdif.h | 210
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention
From: Oleksandr Andrushchenko
Hi, all!
This patch series adds/updates para-virtual device
protocols for Linux Kernel (headers):
o kbdif (updated/multitouch support added)
o sndif - sound (new)
o displif - display (new)
Changes since v0:
* removed editor blocks
* XENDISPL_EVENT_PAGE_SIZE
From: Oleksandr Andrushchenko
Add ABI for the two halves of a para-virtualized
sound driver to communicate with each other.
The ABI allows implementing audio playback and capture as
well as volume control and possibility to mute/unmute
audio sources.
Note: depending on the use-case backend can
From: Oleksandr Andrushchenko
The patch clarifies the protocol that is used by the PV keyboard
drivers.
Acked-by: Juergen Gross
Signed-off-by: Oleksandr Andrushchenko
---
include/xen/interface/io/kbdif.h | 248 ++-
1 file changed, 221 insertions(+), 27
Hi, Juergen!
On 03/21/2017 07:19 PM, Juergen Gross wrote:
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.
Signed-off-by: Juergen Gross
---
drivers/input/misc/xen-kbdfront.c | 10 --
1 file
On 04/10/2017 04:50 PM, Juergen Gross wrote:
On 10/04/17 15:44, Oleksandr Andrushchenko wrote:
Hi, Juergen!
On 03/21/2017 07:19 PM, Juergen Gross wrote:
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary
On 04/10/2017 05:11 PM, Juergen Gross wrote:
On 10/04/17 16:00, Oleksandr Andrushchenko wrote:
On 04/10/2017 04:50 PM, Juergen Gross wrote:
On 10/04/17 15:44, Oleksandr Andrushchenko wrote:
Hi, Juergen!
On 03/21/2017 07:19 PM, Juergen Gross wrote:
Add a parameter for setting the resolution
Connected)
- goto InitWait; /* no InitWait seen yet, fudge it */
+ /* No InitWait seen yet, fudge it. */
+ xenkbd_set_connected(dev);
/* Set input abs params to match backend screen res */
if (xenbus_scanf(XBT_NIL, info->xbdev->
On 04/11/2017 08:15 AM, Juergen Gross wrote:
On 10/04/17 08:25, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, all!
This patch series adds/updates para-virtual device
protocols for Linux Kernel (headers):
o kbdif (updated/multitouch support added)
o sndif - sound (new
eInitWait has been missed the resolution
settings won't be read. Correct this.
Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
---
drivers/input/misc/xen-kbdfront.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a
On 04/11/2017 11:50 AM, Juergen Gross wrote:
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.
Signed-off-by: Juergen Gross
---
drivers/input/misc/xen-kbdfront.c | 18 ++
1 file change
From: Oleksandr Andrushchenko
For some use cases when Xen framebuffer/input backend
is not a part of Qemu it is required to disable it,
because of conflicting access to input/display devices.
Introduce additional configuration option for explicit
input/display control.
Signed-off-by: Oleksandr
On 04/11/2017 12:35 PM, Juergen Gross wrote:
On 11/04/17 11:26, Oleksandr Andrushchenko wrote:
On 04/11/2017 11:50 AM, Juergen Gross wrote:
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.
Signed-off
-
- if (xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-"height", "%d", &val) > 0)
- input_set_abs_params(info->ptr, ABS_Y, 0, val, 0, 0);
-
+ xenbus_switch_state(dev, XenbusSt
From: Oleksandr Andrushchenko
Xen input para-virtual protocol defines string constants
used by both back and frontend. Use those instead of
explicit strings in the frontend driver.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/input/misc/xen-kbdfront.c | 22 +-
1 file
From: Oleksandr Andrushchenko
Hi, all!
This patch series updates existing Xen vkbd frontend driver
to use string constants from the corresponding IO protocol
(kbdif.h) and adds support for virtual multi-touch input device.
This has been tested on a guest running Weston.
This patch series
From: Oleksandr Andrushchenko
Extend xen_kbdfront to provide multi-touch support
to unprivileged domains.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/input/misc/xen-kbdfront.c | 142 +-
1 file changed, 140 insertions(+), 2 deletions(-)
diff --git a
On 02/08/2017 05:16 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 08, 2017 at 10:48:45AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add ABI for the two halves of a para-virtualized
sound driver to communicate with each other.
The ABI allows implementing audio
On 02/08/2017 05:29 PM, Konrad Rzeszutek Wilk wrote:
. snip..
Reviewed-by: Konrad Rzeszutek Wilk
Do you want me to send v18 with the changes requested?
Please wait a week for other folks to get a chance to look at this
patch.
May I put your "Reviewed-by: Konrad Rzeszutek Wilk" in v18?
Of c
On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:
(CC Konrad)
Hi Oleksandr,
On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
On 01/30/2017 05:33 PM, Julien Grall wrote:
This email only tracks big items for xen.git tree
On 02/08/2017 09:29 PM, Julien Grall wrote:
Hi Oleksandr,
On 08/02/17 18:56, Oleksandr Andrushchenko wrote:
On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:
(CC Konrad)
Hi Oleksandr,
On 31/01/17 13:51, Oleksandr
On 02/08/2017 05:29 PM, Konrad Rzeszutek Wilk wrote:
. snip..
Reviewed-by: Konrad Rzeszutek Wilk
Couple of issues I found in sndif while preparing displif for review:
1. missing string constants
+#define XENSND_FIELD_BE_VERSIONS"versions"
+#define XENSND_FIELD_FE_VERSION "v
On 02/09/2017 02:48 PM, Konrad Rzeszutek Wilk wrote:
On February 9, 2017 3:46:10 AM EST, Oleksandr Andrushchenko
wrote:
On 02/08/2017 05:29 PM, Konrad Rzeszutek Wilk wrote:
. snip..
Reviewed-by: Konrad Rzeszutek Wilk
Couple of issues I found in sndif while preparing displif for review:
1
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention
Hi, Konrad!
Thank you for reviewing this.
On 02/10/2017 11:27 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims
. Use the default as fallback only.
Signed-off-by: Juergen Gross
Ping?
---
V3: add case of late framebuffer registration (Oleksandr Andrushchenko)
V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov)
---
drivers/input/misc/xen-kbdfront.c | 46
On 02/14/2017 10:27 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote:
Hi, Konrad!
Thank you for reviewing this.
On 02/10/2017 11:27 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko wrote
On 02/15/2017 05:45 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 15, 2017 at 09:33:41AM +0200, Oleksandr Andrushchenko wrote:
On 02/14/2017 10:27 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote:
Hi, Konrad!
Thank you for reviewing this
On 02/15/2017 11:33 PM, Konrad Rzeszutek Wilk wrote:
.snip..
I will define 2 sections:
*-- Connector Request Transport Parameters
---
*
* ctrl-event-channel
* ctrl-ring-ref
*
*--- Connector Event Transport Parameters
---
On 02/17/2017 06:33 PM, Konrad Rzeszutek Wilk wrote:
On Thu, Feb 16, 2017 at 10:36:01AM +0200, Oleksandr Andrushchenko wrote:
On 02/15/2017 11:33 PM, Konrad Rzeszutek Wilk wrote:
.snip..
I will define 2 sections:
*-- Connector Request Transport Parameters
On 02/17/2017 09:12 PM, Stefano Stabellini wrote:
On Fri, 17 Feb 2017, Konrad Rzeszutek Wilk wrote:
On Thu, Feb 16, 2017 at 10:36:01AM +0200, Oleksandr Andrushchenko wrote:
On 02/15/2017 11:33 PM, Konrad Rzeszutek Wilk wrote:
.snip..
I will define 2 sections
ping
On 02/08/2017 04:42 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Feb 08, 2017 at 09:38:18AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Multi-touch fields re-use the page that is used by the other features
which means that you can interleave multi-touch, motion, and
Hi, Stefano, Jan!
1. Stefano, are you still NOT considering adding
functionality to avoid memory copying? We discussed
this a little bit here [1].
2. Will you also provide macros/inlines for fixed sized packets?
So, others do not reinvent the wheel again on top of your code.
3. C89 - Jan, we
On 02/22/2017 09:40 AM, Jan Beulich wrote:
On 22.02.17 at 08:16, wrote:
3. C89 - Jan, we discussed that a bit for zero-sized arrays [2]
and empty structures [3]. So, then we came to a conclusion that
breakage is not acceptable, but now I see that you have changed
your mind? (Please correct me i
Hi, Stefano!
On 02/22/2017 07:10 PM, Stefano Stabellini wrote:
On Wed, 22 Feb 2017, Oleksandr Andrushchenko wrote:
Hi, Stefano, Jan!
1. Stefano, are you still NOT considering adding
functionality to avoid memory copying? We discussed
this a little bit here [1].
Hi Oleksandr,
these macros are
On 02/23/2017 08:45 PM, Stefano Stabellini wrote:
On Thu, 23 Feb 2017, Oleksandr Andrushchenko wrote:
Hi, Stefano!
On 02/22/2017 07:10 PM, Stefano Stabellini wrote:
On Wed, 22 Feb 2017, Oleksandr Andrushchenko wrote:
Hi, Stefano, Jan!
1. Stefano, are you still NOT considering adding
Hi,
PFA the DTS I use for M3ULCB board
On 02/27/2017 12:48 PM, Oleksandr Tyshchenko wrote:
Hi.
On Mon, Feb 27, 2017 at 12:29 PM, George John wrote:
Hi,
Thanks for the reply,
I am using Linux version 4.6.
The memory nodes were already squashed. When I have used a different version
of Xen, it
On 02/28/2017 12:17 AM, Stefano Stabellini wrote:
On Mon, 27 Feb 2017, Oleksandr Andrushchenko wrote:
On 02/23/2017 08:45 PM, Stefano Stabellini wrote:
On Thu, 23 Feb 2017, Oleksandr Andrushchenko wrote:
Hi, Stefano!
On 02/22/2017 07:10 PM, Stefano Stabellini wrote:
On Wed, 22 Feb 2017
Hi, all!
I have a use-case when I may need to call __vmap for kernel provided
IPAs (read MFNs)
which may not be PAGE_SIZE aligned etc.
The question is if it is safe to call __vmap multiple times for
different IPAs
sharing the same page (mfn), e.g. map something like 6ca00 0080 and
6ca00 0
On 02/28/2017 10:51 PM, Andrew Cooper wrote:
On 28/02/17 19:50, Oleksandr Andrushchenko wrote:
Hi, all!
I have a use-case when I may need to call __vmap for kernel provided
IPAs (read MFNs)
which may not be PAGE_SIZE aligned etc.
The question is if it is safe to call __vmap multiple times
On 03/01/2017 10:22 AM, Jan Beulich wrote:
On 01.03.17 at 06:39, wrote:
On 02/28/2017 10:51 PM, Andrew Cooper wrote:
On 28/02/17 19:50, Oleksandr Andrushchenko wrote:
I have a use-case when I may need to call __vmap for kernel provided
IPAs (read MFNs)
which may not be PAGE_SIZE aligned etc
ons we must stay away from some OS specifics and
be agnostic to the OSes used by back and front. That said, what if
front is Windows
and back QNX? What if errno values differ?
>> + */
>> +
>> +struct xensnd_request {
>> +uint8_t raw[16];
>> +};
>
> How come you p
64 x86_64 GNU/Linux
Could anyone please give me any hint on what needs to
be checked and how this can be resolved?
Thank you,
Oleksandr Andrushchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
If these are all the comments then I'll start preparing patch v9
Thank you all for reviewing and providing feedback
Oleksandr Andrushchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Thank you all for the review and comments!
I guess only these are not addressed (or still need comments):
> 1. You can only say how many channels a stream has, not what the
> channels correspond to (e.g., "left", "right" for a 2 channel stereo
> stream; or "left-front", "rear-right", etc. for a 6
Hi,
just wanted to bump this as I also have the same issue on real HW now
(x86_64)
Nov 14 10:30:18 DomU kernel: [ 1169.569936] []
xen_mc_flush+0x19c/0x1b0
Thank you in advnce,
Oleksandr
On Mon, Nov 14, 2016 at 6:07 PM, Oleksandr Andrushchenko wrote:
> Hi, there!
>
> Sorry for the
This is the ABI for the two halves of a para-virtualized
sound driver to communicate with each to other.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Grytsov
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Iurii Konovalenko
---
Changes since v1:
* removed __attribute__
Hi, all!
First of all we would like to thank you for valuable comments!
Please find the next version of the ABI for the PV sound.
Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov
Oleksandr Andrushchenko (1):
xen: add para-virtual sound interface header files
include/xen/interface/io
Hi, all!
This patch adds support for para-virtualized DRM/KMS.
Comments, ideas are more than welcome.
With best regards,
Oleksandr Andrushchenko
Oleksandr Grytsov
Oleksandr Andrushchenko (1):
drmif: add ABI for para-virtual DRM/KMS
include/xen/interface/io/drmif.h | 505
This is the ABI for the two halves of a para-virtualized
DRM/KMS driver.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Grytsov
---
include/xen/interface/io/drmif.h | 505 +
include/xen/interface/io/drmif_linux.h | 142 +
2 files
etc.
2. My intention was that these files go into Linux kernel tree and the
corresponding
Xen headers are all under include/xen/interface/io folder.
Best regards,
Oleksandr Andrushchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https
> It is not clear to me to which field this comment applies. Is it
> pcm_channels?
It is for pcm_rate, fixed, thanks
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
> You still talk about "Xen headers", i.e. plural, so I don't think your
> reply addresses my earlier question. IOW I continue to think there
> should be only one header in the patch here.
Ok, makes sense. I will create 2 patches: one for sndif.h which
is a generic protocol (platform agnostic) and
> Any people who wants to use the PV driver for other OS than Linux will have
> to do it. So, may I ask why don't you write a platform agnostic header?
>
> This would also make easier to share the PV driver code between different
> OS.
There are 2 files: sndif.h which is platform agnostic and sndif
> I don't consider sndif.h been agnostic. It is just a bunch of array
> definition.
>
I am not sure I'm following you here.
sndif.h doesn't have any platform specific definitions, but sndif_linux.h does.
Both don't define any methods, but only structures (and __packed as of now).
>Each OS would hav
I believe these concerns are exactly the same as for para-virtual audio,
so I would suggest that these being addressed after sndif has some
resolution on packaging and structure (one or two files)
Other than that I would also hear comments on the protocol itself,
e.g. related to DRM/KMS
Thank you,
> This is not critical/important ATM, and completely disconnected from the
> purpose of the patch, so I agree it has to be rewritten according to
> current practices.
Agree, will resend new patch v10 soon
Thank you all
___
Xen-devel mailing list
Xen-dev
Sorry about that, will fix
On Thu, Nov 24, 2016 at 5:05 PM, Lars Kurth wrote:
>
> Oleksandr,
>
>
> On 24/11/2016 11:30, "Oleksandr Andrushchenko" wrote:
>
>>This is the ABI for the two halves of a para-virtualized
>>DRM/KMS driver.
>>
>>Sig
ly
> when replying to long mails), deleting all of it makes reading harder.
>
Sorry about that, I am new to Open Source and sometimes do things wrong ;)
> Jan
>
--
Best regards,
Oleksandr Andrushchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
From: Oleksandr Andrushchenko
Hi, all!
Please find the next version of the ABI for the PV sound
after addressing review comments.
Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov
Oleksandr Andrushchenko (1):
xen: add para-virtual sound interface header file
include/xen/interface/io
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
sound driver to communicate with each to other.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Grytsov
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Iurii Konovalenko
---
Changes
_vol_req get_vol;
>> + struct xensnd_set_vol_req set_vol;
>> + struct xensnd_mute_req mute;
>> + struct xensnd_unmute_req unmute;
>
> ... here.
>
> Also please observe ./CODING_STYLE
most of cache line. Although technically it would be
> possible have bigger one (see the definition of CSSIDR).
>
So, then I will align to 32
>> What it means in practice
>> is not clear as we have so many HW around, so it is not possible to
>>
he size of the command packet to 32
> octet?
>
Well, actually this is what I was going to do...
So, what is the correct value to be used here?
>>>> What it means in practice
>>>> is not clear as we have so many HW around, so it is not possible to
>>>> fit all. So the options could be:
>>>> 1. 32 or 64
>>>> 2. 48 I think is not an option here
>>>
>>>
>>>
>>> Why 48?
>>
>> It is not an option, saw something like this in fbif.h, but it is 40
>> actually there:
>> #define XENFB_OUT_EVENT_SIZE 40
>
>
> But your 32 value seems to be as random as 40. I guess they define a size
> that would fit all the command and would potentially allow the addition of
> commands.
>
Yes, you are right here
> --
> Julien Grall
Best regards,
Oleksandr Andrushchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
se
2. If also FB is needed then we use existing protocol
to add this functionality to guest along with DSPL
Nothing tells me that these couldn't be different
back and front drivers/applications for even better flexibility.
> Jan
>
Best regards,
Oleksandr Andrushchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
atform. There is HW available with
>>>>> 128
>>>>> bytes.
>>>>>
>>>>> For instance on Xen ARM, all the structures are aligned to 128 bytes in
>>>>> order to fit in most of cache line. Although technically it would be
>>>>> possible have bigger one (see the definition of CSSIDR).
>>>>>
>>>> So, then I will align to 32
>>>
>>>
>>>
>>> To confirm, you don't plan to reduce the size of the command packet to 32
>>> octet?
>>>
>> Well, actually this is what I was going to do...
>> So, what is the correct value to be used here?
>
>
> I don't know. What is the expected maximum size of a command?
>
With the current design I don't expect it to be more than 32.
Actually we have already implemented a Linux PV snd driver
and feel comfortable with 32.
So, I would suggest we stick to 32
> Regards,
>
> --
> Julien Grall
--
Best regards,
Oleksandr Andrushchenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 11/25/2016 09:20 AM, Jan Beulich wrote:
On 24.11.16 at 23:14, wrote:
On Thu, 2016-11-24 at 20:31 +0200, Oleksandr Andrushchenko wrote:
Hmm, I think you want a PV Linux DRM/KMS driver, but that doesn't
mean you want/need a protocol by that name. The interface has
to describe vi
101 - 200 of 335 matches
Mail list logo
