Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp8498937ybi; Thu, 6 Jun 2019 13:26:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqwFDz7VfXPfyEMPev013vyM7ln6pmwZgVq7hUkcfDPf25OSNSJklMz76i0PkoxB/rgoiPDk X-Received: by 2002:a63:1b22:: with SMTP id b34mr354465pgb.382.1559852818624; Thu, 06 Jun 2019 13:26:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559852818; cv=none; d=google.com; s=arc-20160816; b=shxgm7jadgpzvYDlfNtpeYs/aVfcv0xXKqcLlVpq2zsWhA26u5PWbDd3PDCVS5VWfV iiXUPFUTq0slvb2CNqASXNtgEWdBpYCQpChoDHfzuAcUWaudXQDOHf3ON9qFccvWAVKR gw+m/wSzma3GTio7xf1stVWw4+BEgaEqfdJV5OD0GJp61u+j7MUP7lvtE5DrCB3m6fgl WJHZgF5kViwHcj5mHMpFiAj2m8cLU8OywFTLN0J0u5lPNrkeHQMMcCcFyXO1MEScYA9u 57u+53w4ztJCwS4sRQ6dUJ3+nlKnxitccB7UDYzcu8RwLnbbvdCOxjm7fiOqqKnjLqkO OdsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=7BHPnb3TkyXzLidetRfaiRc1NR35FRQykp4zdjpV060=; b=ASWHsX9Ncm4B5em+8ZI1ELRyAoFLmK9+FY1V7mCc3GX7PBUGBDRtjy+cK/TOtFvSI+ scpxRZqCGcXkDvOWr7GwtK4L+ZuTS2bwAoxTzueV2hXp1lYiYyOc+oze0xaqFKzHruse eAYPgQrn4eGRciqvsBVg7cRHawCt3o/8GuURtOLpobmjL/lkebWYNvoJpUfbSXokmzoe oA2arXIbMufg4a6EcMqF5xaZxoX2VeRLwwKlThnvBsj++CptzEPmZSOF2Dak9M6z99DG zPiRVqSNSqqe8B/ST+M12iIQsNmor2QDmujTGvYltOruqnr/hxUhKNgeNGf0JhXjudRH +j1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 2si45699ple.275.2019.06.06.13.26.43; Thu, 06 Jun 2019 13:26:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729574AbfFFQZT (ORCPT + 99 others); Thu, 6 Jun 2019 12:25:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57682 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729137AbfFFQZT (ORCPT ); Thu, 6 Jun 2019 12:25:19 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A6E4A30872C9; Thu, 6 Jun 2019 16:25:18 +0000 (UTC) Received: from x1.home (ovpn-116-22.phx2.redhat.com [10.3.116.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 23C369F5E; Thu, 6 Jun 2019 16:25:13 +0000 (UTC) Date: Thu, 6 Jun 2019 10:25:12 -0600 From: Alex Williamson To: "Zhang, Tina" Cc: "kraxel@redhat.com" , "Tian, Kevin" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Zhenyu Wang , "Yuan, Hang" , "Lv, Zhiyuan" , "intel-gvt-dev@lists.freedesktop.org" , "Wang, Zhi A" Subject: Re: [RFC PATCH v2 1/3] vfio: Use capability chains to handle device specific irq Message-ID: <20190606102512.0b3d2933@x1.home> In-Reply-To: <237F54289DF84E4997F34151298ABEBC8764837E@SHSMSX101.ccr.corp.intel.com> References: <20190604095534.10337-1-tina.zhang@intel.com> <20190604095534.10337-2-tina.zhang@intel.com> <20190605040446.GW9684@zhen-hp.sh.intel.com> <237F54289DF84E4997F34151298ABEBC87646B5C@SHSMSX101.ccr.corp.intel.com> <20190605100942.bceke6yqjynuwk3z@sirius.home.kraxel.org> <237F54289DF84E4997F34151298ABEBC8764837E@SHSMSX101.ccr.corp.intel.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Thu, 06 Jun 2019 16:25:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 6 Jun 2019 10:17:51 +0000 "Zhang, Tina" wrote: > > -----Original Message----- > > From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@lists.freedesktop.org] On > > Behalf Of kraxel@redhat.com > > Sent: Wednesday, June 5, 2019 6:10 PM > > To: Zhang, Tina > > Cc: Tian, Kevin ; kvm@vger.kernel.org; linux- > > kernel@vger.kernel.org; Zhenyu Wang ; Yuan, > > Hang ; alex.williamson@redhat.com; Lv, Zhiyuan > > ; intel-gvt-dev@lists.freedesktop.org; Wang, Zhi A > > > > Subject: Re: [RFC PATCH v2 1/3] vfio: Use capability chains to handle device > > specific irq > > > > Hi, > > > > > > Really need to split for different planes? I'd like a > > > > VFIO_IRQ_SUBTYPE_GFX_DISPLAY_EVENT > > > > so user space can probe change for all. > > > > > User space can choose to user different handlers according to the > > > specific event. For example, user space might not want to handle every > > > cursor event due to performance consideration. Besides, it can reduce > > > the probe times, as we don't need to probe twice to make sure if both > > > cursor plane and primary plane have been updated. > > > > I'd suggest to use the value passed via eventfd for that, i.e. instead of > > sending "1" unconditionally send a mask of changed planes. > If there is only one eventfd working for GFX_DISPLAY, should it be > VFIO_IRQ_INFO_EVENTFD and VFIO_IRQ_INFO_AUTOMASKED? i.e. after > signaling, the interrupt is automatically masked and the user space > needs to unmask the line to receive new irq event. If there's any way at all the interrupt is rate limited already, I'd suggest not to use automasked. This flag is generally intended for cases where we need to mask a host interrupt and don't have a generic or efficient way to determine acknowledgement of the interrupt and therefore require an explicit unmask. If the events here are not at a high frequency or you can tell by other interactions that they've been acted upon, I'd suggest to handle these as an edge triggered interrupt w/o automasked. Thanks, Alex