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=-9.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 BE08CC433B4 for ; Wed, 28 Apr 2021 16:47:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7CF5861417 for ; Wed, 28 Apr 2021 16:47:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241196AbhD1Qrp convert rfc822-to-8bit (ORCPT ); Wed, 28 Apr 2021 12:47:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:49478 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241138AbhD1Qro (ORCPT ); Wed, 28 Apr 2021 12:47:44 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C79CA61412; Wed, 28 Apr 2021 16:46:59 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lbnKz-009tmL-H6; Wed, 28 Apr 2021 17:46:57 +0100 Date: Wed, 28 Apr 2021 17:46:56 +0100 Message-ID: <87fszanypr.wl-maz@kernel.org> From: Marc Zyngier To: Alex =?UTF-8?B?QmVubsOpZQ==?= Cc: Alexandru Elisei , kvm@vger.kernel.org, shashi.mallela@linaro.org, eric.auger@redhat.com, qemu-arm@nongnu.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, christoffer.dall@arm.com Subject: Re: [kvm-unit-tests PATCH v1 1/4] arm64: split its-trigger test into KVM and TCG variants In-Reply-To: <87czues90k.fsf@linaro.org> References: <20210428101844.22656-1-alex.bennee@linaro.org> <20210428101844.22656-2-alex.bennee@linaro.org> <87fszasjdg.fsf@linaro.org> <996210ae-9c63-54ff-1a65-6dbd63da74d2@arm.com> <87k0omo4rr.wl-maz@kernel.org> <87czues90k.fsf@linaro.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: alex.bennee@linaro.org, alexandru.elisei@arm.com, kvm@vger.kernel.org, shashi.mallela@linaro.org, eric.auger@redhat.com, qemu-arm@nongnu.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, christoffer.dall@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 28 Apr 2021 16:37:45 +0100, Alex Bennée wrote: > > > Marc Zyngier writes: > > > On Wed, 28 Apr 2021 15:00:15 +0100, > > Alexandru Elisei wrote: > >> > >> I interpret that as that an INVALL guarantees that a change is > >> visible, but it the change can become visible even without the > >> INVALL. > > > > Yes. Expecting the LPI to be delivered or not in the absence of an > > invalidate when its configuration has been altered is wrong. The > > architecture doesn't guarantee anything of the sort. > > Is the underlying hypervisor allowed to invalidate and reload the > configuration whenever it wants or should it only be driven by the > guests requests? The HW can do it at any time. It all depends on whether the RD has cached this LPI configuration or not. KVM relies on the required invalidation as a hook to reload the cached state, as it has an infinite LPI configuration cache, while TCG doesn't have a cache at all. Both approaches are valid implementations. > I did consider a more nuanced variant of the test that allowed for a > delivery pre-inval and a pass for post-inval as long as it had been > delivered one way or another: > > --8<---------------cut here---------------start------------->8--- > modified arm/gic.c > @@ -36,6 +36,7 @@ static struct gic *gic; > static int acked[NR_CPUS], spurious[NR_CPUS]; > static int irq_sender[NR_CPUS], irq_number[NR_CPUS]; > static cpumask_t ready; > +static bool under_tcg; > > static void nr_cpu_check(int nr) > { > @@ -687,6 +688,7 @@ static void test_its_trigger(void) > struct its_collection *col3; > struct its_device *dev2, *dev7; > cpumask_t mask; > + bool before, after; > > if (its_setup1()) > return; > @@ -734,15 +736,17 @@ static void test_its_trigger(void) > /* > * re-enable the LPI but willingly do not call invall > * so the change in config is not taken into account. > - * The LPI should not hit > + * The LPI should not hit. This does however depend on This first point is *wrong*. From the architecture spec: * A change to the LPI configuration is not guaranteed to be visible until an appropriate invalidation operation has completed: - If one or more ITS is implemented, invalidation is performed using the INV or INVALL command. A SYNC command completes the INV and INVALL commands. *not guaranteed* means that it may fire, it may not. > + * implementation defined behaviour - under QEMU TCG emulation > + * it can quite correctly process the event directly. I really don't see the point in testing IMPDEF behaviours. We should test for architectural compliance, not for implementation choices. M. -- Without deviation from the norm, progress is not possible.