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
On 9/26/19 12:49 PM, Julien Grall wrote:
> Hi Rob,
>
>
> On 9/25/19 10:50 PM, Rob Herring wrote:
>> As the comment says, this isn't a DT based device. of_dma_configure()
>> is going to stop allowing a NULL DT node, so this needs to be fixed.
>
> And this can't work on arch not selecting CONFIG_OF
On 9/26/19 1:46 PM, Robin Murphy wrote:
> On 2019-09-26 11:17 am, Oleksandr Andrushchenko wrote:
>>
>> On 9/26/19 12:49 PM, Julien Grall wrote:
>>> Hi Rob,
>>>
>>>
>>> On 9/25/19 10:50 PM, Rob Herring wrote:
>>>> As the comment says,
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
SUPPORT.md | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index 375473a45640..b536cf0814f3 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -372,6 +372,12 @@ Guest
Hello, Anchal!
On 3/29/19 1:19 AM, Anchal Agarwal wrote:
[snip]
Great, could you please let us know what is the progress and further plans
on that, so we do not work on the same code and can coordinate our
efforts somehow? Anchal, could you please shed some light on this?
Looks like my previous
On 1/11/19 5:10 PM, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions
Hello, Hans!
Could you please take a look at my answers below and kindly let me know
if we are ready for (final?) v4 from your point of view.
Konrad, Xen-devel - do you have any objections/comments on this?
Thank you,
Oleksandr
On 12/17/18 9:37 AM, Oleksandr Andrushchenko wrote:
Hello, Hans
On 1/7/19 7:37 PM, Souptick Joarder wrote:
Remove duplicate header which is included twice.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
arch/arm/xen/mm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index cb44aa2
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual multimedia
features [2] such as virtual display, sound. It supports keyboards,
pointers and multi-touch devices all allowing Xen to be used in
automotive appliances, In-Vehicle Infotainment (IVI) systems
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for video conferencing, In-Vehicle Infotainment,
high definition maps etc.
The initial goal is to support most n
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts. Make sure that the frontend's
memory is coheren
On 1/15/19 4:44 PM, Hans Verkuil wrote:
> Hi Oleksandr,
Hello, Hans!
> Just two remaining comments:
>
> On 1/15/19 10:38 AM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> This is the ABI for the two halves of a para-virtualized
>> cam
t_conn.c | 2 +-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
For Xen:
Acked-by: Oleksandr Andrushchenko
drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
On 1/16/19 8:30 AM, Gerd Hoffmann wrote:
>Hi,
>
>> +if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
>> +DMA_BIDIRECTIONAL)) {
>> +ret = -EFAULT;
>> +goto fail_free_sgt;
>> +}
> Hmm, so it seems the arm guys could not come up
On 1/16/19 8:36 AM, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019 at 07:30:02AM +0100, Gerd Hoffmann wrote:
>>Hi,
>>
>>> + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
>>> + DMA_BIDIRECTIONAL)) {
>>> + ret = -EFAULT;
>>> + goto fail
On 1/17/19 11:18 AM, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019 at 06:43:29AM +0000, Oleksandr Andrushchenko wrote:
>>> This whole issue keeps getting more and more confusing.
>> Well, I don't really do DMA here, but instead the buffers in
>> question are sha
On 1/18/19 1:43 PM, Julien Grall wrote:
> (+ Stefano)
>
> Hi,
>
> Sorry for jumping late in the conversation.
>
> On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
>> On 1/17/19 11:18 AM, Christoph Hellwig wrote:
>>> On Wed, Jan 16, 2019 at 06:43:29AM +
Hello, Julien!
On 1/21/19 7:09 PM, Julien Grall wrote:
> Hello,
>
> On 21/01/2019 12:43, Oleksandr Andrushchenko wrote:
>> On 1/18/19 1:43 PM, Julien Grall wrote:
>>> On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
>>>> On 1/17/19 11:18 AM, Christoph Hellw
Any comments from Xen community?
Konrad?
On 1/15/19 4:44 PM, Hans Verkuil wrote:
> Hi Oleksandr,
>
> Just two remaining comments:
>
> On 1/15/19 10:38 AM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> This is the ABI for the two halve
Hello, Julien!
Sorry for the late reply - it took quite some time to collect the data
requested.
On 1/22/19 1:44 PM, Julien Grall wrote:
>
>
> On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/21/19 7:09 PM, Julien Grall wr
On 1/26/19 2:05 PM, YueHaibing wrote:
> There is no need to have the 'struct drm_framebuffer *fb' variable
> static since new value always be assigned before use it.
>
> Signed-off-by: YueHaibing
Good catch, thank you!
Reviewed-by: Oleksandr Andrushchenko
> --
+Boris and Juergen who can also help getting it in
On 1/28/19 8:34 AM, Souptick Joarder wrote:
On Mon, Jan 14, 2019 at 4:08 PM Oleksandr Andrushchenko
wrote:
On 1/7/19 7:37 PM, Souptick Joarder wrote:
Remove duplicate header which is included twice.
Signed-off-by: Souptick Joarder
On 1/24/19 5:02 PM, Julien Grall wrote:
>
>
> On 24/01/2019 14:34, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/22/19 1:44 PM, Julien Grall wrote:
>>>
>>>
>>> On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
&g
From: Oleksandr Andrushchenko
When GEM backing storage is allocated those are normal pages,
so there is no point using pgprot_writecombine while mmaping.
This fixes mismatch of buffer pages' memory attributes between
the frontend and backend which may cause screen artifacts.
Fixes: c575b7e
Dropped in favor of https://lkml.org/lkml/2019/1/29/910
On 1/24/19 5:02 PM, Julien Grall wrote:
>
>
> On 24/01/2019 14:34, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/22/19 1:44 PM, Julien Grall wrote:
>>>
>>>
>&g
On 1/29/19 9:07 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When GEM backing storage is allocated those are normal pages,
>> so there is no point using pgprot_writecom
Konrad, could you please review?
Thank you,
Oleksandr
On 1/15/19 11:38 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Hello!
>
> At the moment Xen [1] already supports some virtual multimedia
> features [2] such as virtual display, sound. It
Hello,
I am working on porting an out-of-tree kernel driver to the kernel
5.0 and that driver uses functionality provided by
drivers/xen/mem-reservation.c
module. Since commit [1] it is not possible to build a kernel module
which uses mem-reservation API as xen_scrub_pages variable, which is
ch
On 2/1/19 10:27 AM, Christoph Hellwig wrote:
> On Thu, Jan 31, 2019 at 01:44:15PM -0800, Stefano Stabellini wrote:
>> The alternative would be to turn xenmem_reservation_scrub_page into a
>> regular function (not a static inline)?
> All that is a moot point until said currently out of tree module g
On 1/31/19 11:44 PM, Stefano Stabellini wrote:
> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
>> Hello,
>>
>> I am working on porting an out-of-tree kernel driver to the kernel
>> 5.0 and that driver uses functionality provided by
>> drivers/xen/mem-reservat
On 1/28/19 8:36 AM, Oleksandr Andrushchenko wrote:
> On 1/26/19 2:05 PM, YueHaibing wrote:
>> There is no need to have the 'struct drm_framebuffer *fb' variable
>> static since new value always be assigned before use it.
>>
>> Signed-off-by: YueHaibing
&
On 1/30/19 11:09 AM, Oleksandr Andrushchenko wrote:
> On 1/29/19 9:07 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> When GEM backing storage is allocated
On 2/1/19 11:14 AM, Juergen Gross wrote:
> On 01/02/2019 09:39, Oleksandr Andrushchenko wrote:
>> On 1/31/19 11:44 PM, Stefano Stabellini wrote:
>>> On Thu, 31 Jan 2019, Oleksandr Andrushchenko wrote:
>>>> Hello,
>>>>
>>>> I am working on porti
On 1/29/19 9:07 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When GEM backing storage is allocated those are normal pages,
>> so there is no point using pgprot_writecom
On 1/26/19 2:05 PM, YueHaibing wrote:
> There is no need to have the 'struct drm_framebuffer *fb' variable
> static since new value always be assigned before use it.
>
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletio
modified. Therefore make fb_funcs
constant to protect it from further modification.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
On 8/14/19 8:26 PM, Daniel Vetter wrote:
On Tue, Aug 13, 2019 at 10:32:00AM +0300, Oleksandr Andrushchenko wrote:
On 8/13/19 9:27 AM, Nishka Dasgupta wrote:
Static structure fb_funcs, of type drm_framebuffer_funcs, is used only
when it is passed to drm_gem_fb_create_with_funcs() as its last
On 1/23/19 10:14 AM, Oleksandr Andrushchenko wrote:
Any comments from Xen community?
Konrad?
While I am still looking forward to any comments from Xen community...
On 1/15/19 4:44 PM, Hans Verkuil wrote:
Hi Oleksandr,
Just two remaining comments:
On 1/15/19 10:38 AM, Oleksandr
On 2/5/19 11:34 AM, Hans Verkuil wrote:
On 2/5/19 9:48 AM, Oleksandr Andrushchenko wrote:
On 1/23/19 10:14 AM, Oleksandr Andrushchenko wrote:
Any comments from Xen community?
Konrad?
While I am still looking forward to any comments from Xen community...
On 1/15/19 4:44 PM, Hans Verkuil wrote
On 2/5/19 12:53 PM, Hans Verkuil wrote:
On 2/5/19 11:44 AM, Oleksandr Andrushchenko wrote:
On 2/5/19 11:34 AM, Hans Verkuil wrote:
On 2/5/19 9:48 AM, Oleksandr Andrushchenko wrote:
On 1/23/19 10:14 AM, Oleksandr Andrushchenko wrote:
Any comments from Xen community?
Konrad?
While I am still
On 2/5/19 2:14 PM, Hans Verkuil wrote:
On 2/5/19 12:44 PM, Oleksandr Andrushchenko wrote:
On 2/5/19 12:53 PM, Hans Verkuil wrote:
On 2/5/19 11:44 AM, Oleksandr Andrushchenko wrote:
On 2/5/19 11:34 AM, Hans Verkuil wrote:
On 2/5/19 9:48 AM, Oleksandr Andrushchenko wrote:
On 1/23/19 10:14 AM
On 2/5/19 3:02 PM, Hans Verkuil wrote:
On 2/5/19 1:30 PM, Oleksandr Andrushchenko wrote:
Sorry for paying so much attention to this, but I think it is important that
this is documented precisely.
Thank you for helping with this - your comments are really
important and make the description
Konrad, could you please review? So, I can send v5 with Hans'
comments addressed
Thank you,
Oleksandr
On 1/23/19 10:14 AM, Oleksandr Andrushchenko wrote:
Any comments from Xen community?
Konrad?
On 1/15/19 4:44 PM, Hans Verkuil wrote:
Hi Oleksandr,
Just two remaining comments:
On 1/
From: Oleksandr Andrushchenko
If there are exported DMA buffers which are still in use and
grant device is closed by either normal user-space close or by
a signal this leads to the grant device context to be destroyed,
thus making it not possible to correctly destroy those exported
buffers when
From: Oleksandr Andrushchenko
Check if there are any imported dma-bufs left not released by
user-space when grant device's release callback is called and
free those if this is the case. This can happen if user-space
leaks the buffers because of a bug or application has been
terminated fo
On 2/15/19 5:03 PM, Boris Ostrovsky wrote:
On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
/* DMA buffer export support. */
@@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref *kref)
dmabuf_exp_wait_obj_signal(gntdev_dmabuf->priv, gntdev_dmabuf);
list_
On 2/15/19 5:28 PM, Boris Ostrovsky wrote:
On 2/15/19 10:07 AM, Oleksandr Andrushchenko wrote:
On 2/15/19 5:03 PM, Boris Ostrovsky wrote:
On 2/14/19 9:23 AM, Oleksandr Andrushchenko wrote:
/* DMA buffer export support. */
@@ -311,6 +317,7 @@ static void dmabuf_exp_release(struct kref
On 2/19/19 6:57 AM, Li RongQing wrote:
> This case block will be terminated by a break, so not need
> a switch fall-through
>
> Signed-off-by: Li RongQing
Reviewed-by: Oleksandr Andrushchenko
> ---
> sound/xen/xen_snd_front.c | 1 -
> 1 file changed, 1 deletion(-)
>
al/lib/xen/bin/pygrub", line 19, in
> import xen.lowlevel.xc
> ImportError: /usr/local/lib/libxengnttab.so.1: Undefined symbol
> "osdep_gnttab_dmabuf_exp_from_refs"
>
> Fixes: ee8105 ("libgnttab: Add support for Linux dma-buf")
> Signed-off-by: Roger Pau Mo
From: Oleksandr Andrushchenko
It is required by MISRA [1] that every switch statement has a default
label as a measure of defensive programming technique.
The changes in this patch are to match MISRA C:2012: Rule 16.4
requirements.
[1] https://www.misra.org.uk/
Signed-off-by: Oleksandr
From: Oleksandr Andrushchenko
It is required by MISRA [1] that every switch statement has a default
label as a measure of defensive programming technique.
The changes in this patch are to match MISRA C:2012: Rule 16.4
requirements.
[1] https://www.misra.org.uk/
Signed-off-by: Oleksandr
From: Oleksandr Andrushchenko
It is required by MISRA [1] that every switch statement has a default
label as a measure of defensive programming technique.
The changes in this patch are to match MISRA C:2012: Rule 16.4
requirements.
[1] https://www.misra.org.uk/
Signed-off-by: Oleksandr
From: Oleksandr Andrushchenko
It is required by MISRA [1] that every switch statement has a default
label as a measure of defensive programming technique.
The changes in this patch are to match MISRA C:2012: Rule 16.4
requirements.
[1] https://www.misra.org.uk/
Signed-off-by: Oleksandr
From: Oleksandr Andrushchenko
Hello, everybody!
We at EPAM Systems would like to present first series of patches targeting Xen
on ARM Functional Safety certification (ISO61508 based): implementation of
MISRA [1] C:2012 Rule 16.4 which requires that every switch statement has a
default label as
On 2/22/19 1:05 PM, Julien Grall wrote:
Hi,
On 22/02/2019 10:27, Andrew Cooper wrote:
On 22/02/2019 09:57, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello, everybody!
We at EPAM Systems would like to present first series of patches
targeting Xen
on ARM Functional Safety
On 2/22/19 1:27 PM, Julien Grall wrote:
Hi Oleksandr,
On 22/02/2019 11:13, Oleksandr Andrushchenko wrote:
On 2/22/19 1:05 PM, Julien Grall wrote:
Hi,
On 22/02/2019 10:27, Andrew Cooper wrote:
On 22/02/2019 09:57, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello
On 2/20/19 10:46 PM, Julien Grall wrote:
(+ Andrew and Jan for feedback on the event channel interrupt)
Hi Boris,
Thank you for the your feedback.
On 2/20/19 8:04 PM, Boris Ostrovsky wrote:
On 2/20/19 1:05 PM, Julien Grall wrote:
Hi,
On 20/02/2019 17:07, Boris Ostrovsky wrote:
On 2/20/19 9
On 2/22/19 11:33 PM, Andrew Cooper wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I checked the series with -Wswitch-default:
-Wswitch-default
Warn whenever a switch statement does not have a default case.
Will you be ok to turn this particu
On 2/23/19 1:34 AM, Julien Grall wrote:
Hi,
On 22/02/2019 22:38, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Andrew Cooper wrote:
On 22/02/2019 22:11, Julien Grall wrote:
Hi Stefano,
On 22/02/2019 21:58, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Andrew Cooper wrote:
On 22/02/2019 2
On 2/23/19 1:41 AM, Andrew Cooper wrote:
On 22/02/2019 23:22, Julien Grall wrote:
Hi,
On 22/02/2019 22:34, Andrew Cooper wrote:
On 22/02/2019 22:11, Julien Grall wrote:
Hi Stefano,
On 22/02/2019 21:58, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Andrew Cooper wrote:
On 22/02/2019 21:00,
On 2/23/19 12:08 AM, Julien Grall wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I checked the series with -Wswitch-default:
-Wswitch-default
On 2/23/19 1:13 AM, Julien Grall wrote:
Hi,
On 22/02/2019 22:34, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
Hi Stefano,
On 22/02/2019 21:58, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Andrew Cooper wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22
On 2/25/19 1:08 PM, Julien Grall wrote:
Hi Oleksandr,
On 25/02/2019 10:00, Oleksandr Andrushchenko wrote:
On 2/23/19 1:34 AM, Julien Grall wrote:
What are the consequences of not following them in Xen Project? I
know that some upstream project chose to not apply to all the rules.
Not all
On 2/25/19 1:10 PM, Julien Grall wrote:
Hi,
On 25/02/2019 10:06, Oleksandr Andrushchenko wrote:
On 2/23/19 1:41 AM, Andrew Cooper wrote:
On 22/02/2019 23:22, Julien Grall wrote:
Hi,
On 22/02/2019 22:34, Andrew Cooper wrote:
On 22/02/2019 22:11, Julien Grall wrote:
Hi Stefano,
On 22/02
On 2/25/19 1:23 PM, Julien Grall wrote:
Hi,
On 25/02/2019 09:50, Oleksandr Andrushchenko wrote:
On 2/22/19 11:33 PM, Andrew Cooper wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I checked the series with -Wswitch-default:
-Wswitch-default
On 2/25/19 1:47 PM, Julien Grall wrote:
Hi,
On 25/02/2019 10:11, Oleksandr Andrushchenko wrote:
On 2/23/19 12:08 AM, Julien Grall wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri, 22 Feb 2019, Julien Grall wrote:
BTW, I checked the series with -Wswitch-default:
-Wswitch-default
On 2/25/19 1:43 PM, Julien Grall wrote:
Hi,
On 22/02/2019 10:27, Andrew Cooper wrote:
On 22/02/2019 09:57, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello, everybody!
We at EPAM Systems would like to present first series of patches
targeting Xen
on ARM Functional Safety
On 2/25/19 2:11 PM, Jan Beulich wrote:
On 25.02.19 at 12:49, wrote:
I am not defending BUG() in any way which is obviously a no-go.
I am just trying to say that BUG() usage in the existing code needs to be
fixed first. Once done, we can then move to "default" w/o BUG()
Why? A first step to not
On 2/25/19 2:15 PM, Julien Grall wrote:
Hi,
On 25/02/2019 11:49, Oleksandr Andrushchenko wrote:
On 2/25/19 1:23 PM, Julien Grall wrote:
Hi,
On 25/02/2019 09:50, Oleksandr Andrushchenko wrote:
On 2/22/19 11:33 PM, Andrew Cooper wrote:
On 22/02/2019 21:00, Stefano Stabellini wrote:
On Fri
On 2/25/19 2:50 PM, Julien Grall wrote:
Hi,
On 25/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/25/19 2:15 PM, Julien Grall wrote:
Hi,
On 25/02/2019 11:49, Oleksandr Andrushchenko wrote:
On 2/25/19 1:23 PM, Julien Grall wrote:
Hi,
On 25/02/2019 09:50, Oleksandr Andrushchenko wrote
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, Julien Grall wrote:
Discussing with my team, a solution that came up would be to
introduce one atomic field per event to record the number of event
received. I will explore
On 2/25/19 3:22 PM, Julien Grall wrote:
Hi,
On 25/02/2019 13:06, Oleksandr Andrushchenko wrote:
On 2/25/19 2:50 PM, Julien Grall wrote:
Hi,
On 25/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/25/19 2:15 PM, Julien Grall wrote:
Hi,
On 25/02/2019 11:49, Oleksandr Andrushchenko wrote
On 2/25/19 3:40 PM, Julien Grall wrote:
Hi,
On 25/02/2019 13:32, Oleksandr Andrushchenko wrote:
On 2/25/19 3:22 PM, Julien Grall wrote:
Why? If we *first* deal with BUG() and *then* introduce "defaults"
patch
which will use the already fixed code?
This is not how your e-mail ca
On 2/25/19 3:55 PM, Julien Grall wrote:
Hi Oleksandr,
On 25/02/2019 13:24, Oleksandr Andrushchenko wrote:
On 2/22/19 3:33 PM, Julien Grall wrote:
Hi,
On 22/02/2019 12:38, Oleksandr Andrushchenko wrote:
On 2/20/19 10:46 PM, Julien Grall wrote:
Discussing with my team, a solution that came up
On 2/25/19 11:34 PM, Julien Grall wrote:
Hi,
On 2/25/19 9:13 PM, Stefano Stabellini wrote:
I think it is fine to exploit compiler specific checks when available.
However, I don't think we should make any decisions on code correctness
based on the compiler checks that we introduce.
In other w
On 2/26/19 1:20 PM, Jan Beulich wrote:
On 25.02.19 at 22:34, wrote:
On 2/25/19 9:13 PM, Stefano Stabellini wrote:
I think it is fine to exploit compiler specific checks when available.
However, I don't think we should make any decisions on code correctness
based on the compiler checks that we
On 2/26/19 1:47 PM, Jan Beulich wrote:
On 26.02.19 at 12:33, wrote:
On 2/26/19 1:20 PM, Jan Beulich wrote:
On 25.02.19 at 22:34, wrote:
On 2/25/19 9:13 PM, Stefano Stabellini wrote:
I think it is fine to exploit compiler specific checks when available.
However, I don't think we should make
+Xen-devel list
On 2/27/19 10:53 PM, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warning:
drivers/video/fbdev/xen-fbfront.c: In function ‘xenfb_backend_changed’:
drivers/v
To whom it may concern
Since late 2017 the very useful Patchwork resource [1]
stopped working after (as I assume) Xen-devel list has changed
its address from xen-de...@lists.xen.org to the current one.
Patchwork is still configured to the old one, so recent
patches are not archived.
Could the res
+webmas...@kernel.org
Hi, there!
Could you please fix wrong mailing list for Xen project at [2]?
The correct mailing list now lives at "xen-devel@lists.xenproject.org"
Thank you in advance,
Oleksandr
On 3/6/19 1:17 PM, Julien Grall wrote:
(+ Lars)
On 06/03/2019 10:04,
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual multimedia
features [2] such as virtual display, sound. It supports keyboards,
pointers and multi-touch devices all allowing Xen to be used in
automotive appliances, In-Vehicle Infotainment (IVI) systems
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for video conferencing, In-Vehicle Infotainment,
high definition maps etc.
The initial goal is to support most n
Hello, Hans!
This is the version of the protocol with minor comments addressed
(that you had on v4). Hope this now looks OK.
Thank you,
Oleksandr
On 3/12/19 10:19 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual
On 3/12/19 10:58 AM, Hans Verkuil wrote:
Hi Oleksandr,
Just one comment:
On 3/12/19 9:20 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
fa
On 3/12/19 11:07 AM, Jan Beulich wrote:
On 12.03.19 at 09:48, wrote:
On 12/03/2019 09:19, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual multimedia
features [2] such as virtual display, sound. It supports keyboards
On 3/12/19 11:30 AM, Hans Verkuil wrote:
On 3/12/19 10:08 AM, Oleksandr Andrushchenko wrote:
On 3/12/19 10:58 AM, Hans Verkuil wrote:
Hi Oleksandr,
Just one comment:
On 3/12/19 9:20 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a
On 3/12/19 12:09 PM, Hans Verkuil wrote:
On 3/12/19 10:35 AM, Oleksandr Andrushchenko wrote:
On 3/12/19 11:30 AM, Hans Verkuil wrote:
On 3/12/19 10:08 AM, Oleksandr Andrushchenko wrote:
On 3/12/19 10:58 AM, Hans Verkuil wrote:
Hi Oleksandr,
Just one comment:
On 3/12/19 9:20 AM, Oleksandr
On 3/12/19 10:38 AM, Juergen Gross wrote:
On 12/03/2019 09:20, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for
From: Oleksandr Andrushchenko
Currently on driver resume we remove all the network queues and
destroy shared Tx/Rx rings leaving the driver in its current state
and never signaling the backend of this frontend's state change.
This leads to the number of consequences:
- when frontend with
, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Currently on driver resume we remove all the network queues and
destroy shared Tx/Rx rings leaving the driver in its current state
and never signaling the backend of this frontend's state change.
This leads to the number of consequences:
-
On 3/6/19 6:02 PM, Lars Kurth wrote:
On 06/03/2019, 16:00, "Ian Jackson" wrote:
Lars Kurth writes ("Re: [Xen-devel] Can someone pls repair patchwork?"):
> Hi all, (+ Florian & +Ian, as NEC runs their own patchwork instance and
may have some insights)
>
> before I approach
On 3/14/19 4:47 PM, Boris Ostrovsky wrote:
On 3/14/19 9:17 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Currently on driver resume we remove all the network queues and
destroy shared Tx/Rx rings leaving the driver in its current state
and never signaling the backend of
On 3/14/19 5:02 PM, Boris Ostrovsky wrote:
On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote:
On 3/14/19 4:47 PM, Boris Ostrovsky wrote:
On 3/14/19 9:17 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Currently on driver resume we remove all the network queues and
destroy
On 3/14/19 17:40, Boris Ostrovsky wrote:
On 3/14/19 11:10 AM, Oleksandr Andrushchenko wrote:
On 3/14/19 5:02 PM, Boris Ostrovsky wrote:
On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote:
On 3/14/19 4:47 PM, Boris Ostrovsky wrote:
On 3/14/19 9:17 AM, Oleksandr Andrushchenko wrote:
From
On 3/14/19 20:16, Boris Ostrovsky wrote:
On 3/14/19 12:33 PM, Oleksandr Andrushchenko wrote:
On 3/14/19 17:40, Boris Ostrovsky wrote:
On 3/14/19 11:10 AM, Oleksandr Andrushchenko wrote:
On 3/14/19 5:02 PM, Boris Ostrovsky wrote:
On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote:
On 3/14/19
On 3/14/19 7:05 PM, Lars Kurth wrote:
On 14/03/2019, 07:23, "Oleksandr Andrushchenko" wrote:
On 3/6/19 6:02 PM, Lars Kurth wrote:
>
> Oleksandr sent a mail to +webmas...@kernel.org
> Let's see whether anything comes back
>
> If not,
From: Oleksandr Andrushchenko
While disconnecting from the backend we clean up shared resources
(event channel, ring buffer), but never let the backend know about
that. This may lead to inconsistent backend state and/or shared
resources use.
Fix this by explicitly letting the backend know that
+Amazon
pls see inline
On 3/14/19 9:00 PM, Julien Grall wrote:
Hi,
On 3/14/19 3:40 PM, Boris Ostrovsky wrote:
On 3/14/19 11:10 AM, Oleksandr Andrushchenko wrote:
On 3/14/19 5:02 PM, Boris Ostrovsky wrote:
On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote:
On 3/14/19 4:47 PM, Boris
From: Oleksandr Andrushchenko
Hello!
At the moment Xen [1] already supports some virtual multimedia
features [2] such as virtual display, sound. It supports keyboards,
pointers and multi-touch devices all allowing Xen to be used in
automotive appliances, In-Vehicle Infotainment (IVI) systems
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for video conferencing, In-Vehicle Infotainment,
high definition maps etc.
The initial goal is to support most n
1 - 100 of 1430 matches
Mail list logo
