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: 9453903 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 93E566071E for ; Wed, 30 Nov 2016 08:27:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 83716283AC for ; Wed, 30 Nov 2016 08:27:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 775BA28409; Wed, 30 Nov 2016 08:27:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id C0ADB283AC for ; Wed, 30 Nov 2016 08:27:17 +0000 (UTC) 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-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+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP 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 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.