From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A999C43381 for ; Mon, 25 Feb 2019 13:55:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2319C213A2 for ; Mon, 25 Feb 2019 13:55:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727160AbfBYNzq (ORCPT ); Mon, 25 Feb 2019 08:55:46 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:32814 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725990AbfBYNzq (ORCPT ); Mon, 25 Feb 2019 08:55:46 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8F57480D; Mon, 25 Feb 2019 05:55:45 -0800 (PST) Received: from [10.1.196.50] (e108454-lin.cambridge.arm.com [10.1.196.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 12D6F3F575; Mon, 25 Feb 2019 05:55:43 -0800 (PST) Subject: Re: [Xen-devel] xen/evtchn and forced threaded irq To: Oleksandr Andrushchenko , Boris Ostrovsky Cc: Juergen Gross , Stefano Stabellini , Andrew Cooper , "linux-kernel@vger.kernel.org" , Jan Beulich , Dave P Martin , xen-devel References: <5e256d9a-572c-e01e-7706-407f99245b00@arm.com> <20190220000209.GA4091@localhost.localdomain> <21214d47-9c68-e6bf-007a-4047cc2b02f9@oracle.com> <8f7445d7-fa50-f3e9-44f5-cc2aebd020f4@arm.com> <15bc52cb-82d8-4d2c-e5a8-c6ae8de90276@oracle.com> <5df8888a-4a29-fccd-bac2-a9c170244029@arm.com> <13a9616c-2d9a-f90b-3358-f2dcadbbb64d@gmail.com> From: Julien Grall Message-ID: Date: Mon, 25 Feb 2019 13:55:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <13a9616c-2d9a-f90b-3358-f2dcadbbb64d@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 would be to introduce one >>>> atomic field per event to record the number of event received. I will >>>> explore that solution tomorrow. >>> How will this help if events have some payload? >> >> What payload? The event channel does not carry any payload. It only notify you >> that something happen. Then this is up to the user to decide what to you with it. > Sorry, I was probably not precise enough. I mean that an event might have > associated payload in the ring buffer, for example [1]. So, counting events > may help somehow, but the ring's data may still be lost From my understanding of event channels are edge interrupts. By definition, they can be merged so you can get a signal notification to the guest for multiple "events". So if you rely on the event to have an associated payload, then you probably have done something wrong in your driver. I haven't implemented PV drivers myself, but I would expect either side to block if there were no space in the ring. What do you do in the displif driver when the ring is full? Cheers, > [1] > https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/displif.h;h=cc5de9cb1f35dedc99c866d73d086b19e496852a;hb=HEAD#l756 > -- Julien Grall