Received: by 10.223.185.116 with SMTP id b49csp6487354wrg; Thu, 8 Mar 2018 08:13:19 -0800 (PST) X-Google-Smtp-Source: AG47ELsNBVpqBI8YkjI5obzsV/lZwGuGbIcnorDiyEHbEXSOGL3yujFaLJmApD/Mj6BpQ1M9GpzT X-Received: by 10.98.92.194 with SMTP id q185mr25853964pfb.63.1520525599718; Thu, 08 Mar 2018 08:13:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520525599; cv=none; d=google.com; s=arc-20160816; b=slcaVGJ95chE7/58aVOWugCs5LXAEEPpQNKm/FiYtvlOtyzRSTP1BrACc4zbntserH cC+qSFmcNrJqiGSLFW6HkRn+M1/w+7R16VL3bChIN21aaPD/JOdiv9lrFqKWwTEQlu6s smKhUPeNzzjfRIP5V3z1uf4gElupODjOdZWd33Nc3I3wfJjolcYLsxGudRyMT3+c7kEn TfOzLg45N/YRww8BhoUlLT/U4x73I/7RBvq1tYIT01rWvOX2E5svkEz+zWjc9EWE4MCP OqcFoZfikV2S2UGiE8FnQS8VHjz2cSoFc38gL0a559dIJ6Mer/d2rgGFgCBSZ8SAoMWZ Mfsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=iGuzD+sHzd9kNuHWUG5Ik+YcLu0GtyXSWAxIRwIsrNA=; b=Tt//TqXufcrw1wR5Ey/E0qKP5iwwf5/Uc73T7nkFzZV/WVHhqjptEH73CXXHp93YMs 9TZGweiZT7ldSNd8f3XGUZs/yx54Qg8hFZuILTm7A/nglOV40Ba4tnW8mhP9iat+qcEg h6nbfUb+/LTmRK6U2Me9KAzurXBFIvjJo6a1Mw+fYKxytMp6Ue+gOiK3Mf4uhJYzrKPI FmB3oJsiWq7Ff+dTRcwrBZEtlv7C6azniQ+w+0Vu8ZQ1ma0zuC2r96oP4R2/t4wxKhuI qAKtYPk7IFDWmCCFZtiCKNw1eSKRwRiCxRANESXKkaQ2Z8T4ac31JnPOHtgGwQsx1kQf 6bQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@christofferdall-dk.20150623.gappssmtp.com header.s=20150623 header.b=qpq9kzjm; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e11si13026055pgn.261.2018.03.08.08.13.04; Thu, 08 Mar 2018 08:13:19 -0800 (PST) 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; dkim=fail header.i=@christofferdall-dk.20150623.gappssmtp.com header.s=20150623 header.b=qpq9kzjm; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935912AbeCHQKa (ORCPT + 99 others); Thu, 8 Mar 2018 11:10:30 -0500 Received: from mail-lf0-f50.google.com ([209.85.215.50]:37679 "EHLO mail-lf0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752093AbeCHQK1 (ORCPT ); Thu, 8 Mar 2018 11:10:27 -0500 Received: by mail-lf0-f50.google.com with SMTP id y19-v6so9060074lfd.4 for ; Thu, 08 Mar 2018 08:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=christofferdall-dk.20150623.gappssmtp.com; s=20150623; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=iGuzD+sHzd9kNuHWUG5Ik+YcLu0GtyXSWAxIRwIsrNA=; b=qpq9kzjm0DyupWAtTeUXcgiHw/LCUNtcKDmz6DekaQX/SbZi0Cq+b6Pt6X0PH5I5EZ IXcWxo3bJhIQ2QMyPPlhrxPcrMZlgHkedUHdgTUFeTeQFqhNSXGZF/lhDJ5KwbNQP8M/ /2P/fCTsnvHw3QyhSgoUm4cZ/r44c/fH4OP/2T7vhiLleXBtvrMtCMjGkLZZkC7pOSZq LkenKTKoFYyNpYAlCKDLRd6wa6V/hXX9HJylh7MdVZuOqRNqZzXUT4Z14lABbcOpmL3M GwH13Lt+ETawKPwiEo7i/uT25xbBpj1z30eczcR83oJju8FdBDzkjcFflepmklhzHg3o GrKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=iGuzD+sHzd9kNuHWUG5Ik+YcLu0GtyXSWAxIRwIsrNA=; b=m0eY16H3GmSajslTKwxz7xgZnIQp5KjpIkSW/SWZW7Fk4ZI9GJoEnXNifa5KGR6Pth 9bp+GABY3v+pc0M/MlthJ64kjVslv6zxGMUEd8EESrmBzlvN2qgJrvY2XkzJ5Ss57VCr GkhjQ5/18ZKICaP6TU2r97dA9I9hro7bTc5hKf6TNdXymvMK/U72WYXZ0twCIWxpm/SH SfAdCc8ayHZZdjrOOZBX2R+8gnCp+Goq1oPU9c+Levtsh/YO22ZBB/2CoA33bD7//ehv R3mVq6ZaA+atfeqTQqDBNFpW5v6i/qOmh2re+pvjtO5xtmZVzOeN+zsv2X0zauEOo+qP ZXAw== X-Gm-Message-State: AElRT7E7DVej7DckjoDwvVXKYuB3RB3vhsCvr7ONL3R2NGmjZznMNdvF BKbbLcHf8k4mu72JPw5AfwXY8AXMiaM= X-Received: by 10.25.203.68 with SMTP id b65mr19744921lfg.116.1520525425987; Thu, 08 Mar 2018 08:10:25 -0800 (PST) Received: from localhost (77.241.141.19.bredband.3.dk. [77.241.141.19]) by smtp.gmail.com with ESMTPSA id y7sm4163332ljd.45.2018.03.08.08.10.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 08:10:25 -0800 (PST) Date: Thu, 8 Mar 2018 08:10:21 -0800 From: Christoffer Dall To: Marc Zyngier Cc: Shunyong Yang , ard.biesheuvel@linaro.org, will.deacon@arm.com, eric.auger@redhat.com, david.daney@cavium.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, Joey Zheng Subject: Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling Message-ID: <20180308161021.GB1917@lvm> References: <1520492490-7943-1-git-send-email-shunyong.yang@hxt-semitech.com> <9ad47673-068e-f732-d2ca-9c76a8fbdfbc@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9ad47673-068e-f732-d2ca-9c76a8fbdfbc@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 08, 2018 at 09:49:43AM +0000, Marc Zyngier wrote: > [updated Christoffer's email address] > > Hi Shunyong, > > On 08/03/18 07:01, Shunyong Yang wrote: > > When resampling irqfds is enabled, level interrupt should be > > de-asserted when resampling happens. On page 4-47 of GIC v3 > > specification IHI0069D, it said, > > "When the PE acknowledges an SGI, a PPI, or an SPI at the CPU > > interface, the IRI changes the status of the interrupt to active > > and pending if: > > • It is an edge-triggered interrupt, and another edge has been > > detected since the interrupt was acknowledged. > > • It is a level-sensitive interrupt, and the level has not been > > deasserted since the interrupt was acknowledged." > > > > GIC v2 specification IHI0048B.b has similar description on page > > 3-42 for state machine transition. > > > > When some VFIO device, like mtty(8250 VFIO mdev emulation driver > > in samples/vfio-mdev) triggers a level interrupt, the status > > transition in LR is pending-->active-->active and pending. > > Then it will wait resampling to de-assert the interrupt. > > > > Current design of lr_signals_eoi_mi() will return false if state > > in LR is not invalid(Inactive). It causes resampling will not happen > > in mtty case. > > Let me rephrase this, and tell me if I understood it correctly: > > - A level interrupt is injected, activated by the guest (LR state=active) > - guest exits, re-enters, (LR state=pending+active) > - guest EOIs the interrupt (LR state=pending) > - maintenance interrupt > - we don't signal the resampling because we're not in an invalid state > > Is that correct? > > That's an interesting case, because it seems to invalidate some of the > optimization that went in over a year ago. > > 096f31c4360f KVM: arm/arm64: vgic: Get rid of MISR and EISR fields > b6095b084d87 KVM: arm/arm64: vgic: Get rid of unnecessary save_maint_int_state > af0614991ab6 KVM: arm/arm64: vgic: Get rid of unnecessary process_maintenance operation > > We could compare the value of the LR before the guest entry with > the value at exit time, but we still could miss it if we have a > transition such as P+A -> P -> A and assume a long enough propagation > delay for the maintenance interrupt (which is very likely). > > In essence, we have lost the benefit of EISR, which was to give us a > way to deal with asynchronous signalling. > I don't understand why EISR gives us anything beyond looking at the LR and evaluating if the state is 00. My reading of the spec is that the EISR is merely a shortcut to knowing the state of the LRs but contains not record or information beyond what you can read from the LRs. What am I missing? Thanks, -Christoffer