From patchwork Wed Nov 30 08:24:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 84970 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp132609qgi; Wed, 30 Nov 2016 00:26:51 -0800 (PST) X-Received: by 10.84.211.144 with SMTP id c16mr70755438pli.37.1480494411717; Wed, 30 Nov 2016 00:26:51 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id y14si59568774pfg.18.2016.11.30.00.26.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2016 00:26:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1cC0C1-0001pC-T2; Wed, 30 Nov 2016 08:24:41 +0000 Received: from mail-lf0-x231.google.com ([2a00:1450:4010:c07::231]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1cC0Bu-0001bY-PX for linux-arm-kernel@lists.infradead.org; Wed, 30 Nov 2016 08:24:37 +0000 Received: by mail-lf0-x231.google.com with SMTP id b14so140704578lfg.2 for ; Wed, 30 Nov 2016 00:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=yzK54aEYvP8yaHq/f1HMEWizKQylFKEWTz9XI2xP2fs=; b=cARaPSpvNjHgxKLCMnfBIM+HFdgr77j0mvZZYLxqNE0LZEube+wLrTg/YC9u64OlQt LLJhECwxh8ZrsCUO8xiA8LQBpOnb828/AOo3gjaTKZjpBcf3K6GEjT7jaFYq4NHyp9/6 SVzpQbynzOuBpPHGQtPbPuzcNJqs9dDrSsAPs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=yzK54aEYvP8yaHq/f1HMEWizKQylFKEWTz9XI2xP2fs=; b=TP6AJGK5t/Y/YpboksfjFpA+9qVaEalLQ+JRXe3whdY2I82kkH1n8MFakbe4L6cdzf WxpW+fTG124Ir7gpnsmC3MelJDu0kAqMIL2c8orwXqfNLAR6VWPV7xA00VIw/Db634bi 9+EVw31IuCBRQJI8w8t5Cp44nU8lO475i3Rb9Ggq81ZnmXx/N5Inc0UTkRz7BBs66q46 JZvs8UPQPI44fUh+khKj2o1fRdPbyvspG7jzymyGBOMQlihQzbwv7o+b7v8Cd/ILcpY7 JNbc3/hqUFwbVJUmImtMg2dQz7sQWYqcybyZp91XUAe2E50m7IuOdnouY84WtJz6OVIJ 5l1w== X-Gm-Message-State: AKaTC00lU+uizl+9cIvEgFnXKIUePLGjHwGzbE2axv8lzb4jSry7vepW4S8rrLsKAO01lNbD X-Received: by 10.25.10.131 with SMTP id 125mr12399860lfk.172.1480494252254; Wed, 30 Nov 2016 00:24:12 -0800 (PST) Received: from localhost (x1-6-50-6a-03-de-ec-c2.cpe.webspeed.dk. [2.108.209.202]) by smtp.gmail.com with ESMTPSA id x10sm5425596lja.15.2016.11.30.00.24.11 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 30 Nov 2016 00:24:11 -0800 (PST) Date: Wed, 30 Nov 2016 09:24:11 +0100 From: Christoffer Dall To: Peter Maydell Subject: Re: [PATCH v9 07/11] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl Message-ID: <20161130082411.GA6647@cbox> References: <1479906118-15832-1-git-send-email-vijay.kilari@gmail.com> <1479906118-15832-8-git-send-email-vijay.kilari@gmail.com> <20161128195028.GH18170@cbox> <20161129210901.GC15346@cbox> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161130_002435_102398_9622027E X-CRM114-Status: GOOD ( 27.46 ) X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2a00:1450:4010:c07:0:0:0:231 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Vijay Kilari , Marc Zyngier , Pavel Fedin , Vijaya Kumar K , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org On Wed, Nov 30, 2016 at 07:10:51AM +0000, Peter Maydell wrote: > On 29 November 2016 at 21:09, Christoffer Dall > wrote: > > Actually, I'm not sure what the semantics of the line level ioctl should > > be for edge-triggered interrupts? My inclination is that it shouldn't > > have any effect at this point, but that would mean that at this point we > > should only set the pending variable and try to queue the interrupt if > > the config is level. But that also means that when we set the config > > later, we need to try to queue the interrupt, which we don't do > > currently, because we rely on the guest not fiddling with the config of > > an enabled interrupt. > > > > Could it be considered an error if user space tries to set the level for > > an edge-triggered interrupt and therefore something we can just ignore > > and assume that the corresponing interrupt will be configured as a > > level-triggered one later? > > Userspace will always read the line-level values out and write > them back for migration, and I'd rather not make it have to > do cross-checks against whether the interrupt is edge or level > triggered to see whether it should write the level values into > the kernel. Telling the kernel the level for an edge-triggered > interrupt should be a no-op because it doesn't have any effect > on pending status. > > > In any case we probably need to clarify the ABI in terms of this > > particular KVM_DEV_AR_VGIC_GRP_LEVEL_INFO group and how it relates to > > the config of edge vs. level of interrupts and ordering on restore... > > IIRC the QEMU code restores the config first. (There's a similar > ordering thing for GICv2 where we have to restore GICD_ICFGRn before > GICD_ISPENDRn.) > So it sounds to me that we should add a note in the Documentation like this: Vijay, this means that the first block in your if-statement should only set pending and queue the interrupt if the interrupt is a level triggered one. (Peter, I thought you once argued that it was important for user space to be able to save/restore the state without any ordering requirements, but I may have misunderstood. It is still the option to add something like the above to the docs but also do our best to allow any ordering of level/config, but it becomes slightly more invasive.) Thanks, -Christoffer _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt index 9348b3c..7bac20a 100644 --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt +++ b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt @@ -193,6 +193,11 @@ Groups: Bit[n] indicates the status for interrupt vINTID + n. + Getting or setting the level info for an edge-triggered interrupt is + not guaranteed to work. To restore the complete state of the VGIC, the + configuration (edge/level) of interrupts must be restored before + restoring the level. + SGIs and any interrupt with a higher ID than the number of interrupts supported, will be RAZ/WI. LPIs are always edge-triggered and are therefore not supported by this interface.