From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZKs8-0003as-SC for qemu-devel@nongnu.org; Fri, 26 Feb 2016 11:04:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZKs5-0001wk-Cq for qemu-devel@nongnu.org; Fri, 26 Feb 2016 11:04:04 -0500 Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:38091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZKs5-0001wC-2a for qemu-devel@nongnu.org; Fri, 26 Feb 2016 11:04:01 -0500 Received: by mail-wm0-x22e.google.com with SMTP id a4so75866306wme.1 for ; Fri, 26 Feb 2016 08:04:00 -0800 (PST) References: <1456492533-17171-1-git-send-email-alex.bennee@linaro.org> <20160226141256.7rcdm3apxsnglh2p@hawk.localdomain> <87mvqn7c9i.fsf@linaro.org> <20160226152236.fw7lj5fy7s7pzg6c@hawk.localdomain> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <20160226152236.fw7lj5fy7s7pzg6c@hawk.localdomain> Date: Fri, 26 Feb 2016 16:03:57 +0000 Message-ID: <87lh67791u.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC 00/11] Current MTTCG kvm-unit-test patches List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones Cc: mttcg@greensocs.com, peter.maydell@linaro.org, mark.burton@greensocs.com, claudio.fontana@huawei.com, qemu-devel@nongnu.org, will.deacon@arm.com, a.rigo@virtualopensystems.com, crosthwaitepeter@gmail.com, a.spyridakis@virtualopensystems.com, pbonzini@redhat.com, fred.konrad@greensocs.com, aurelien@aurel32.net, rth@twiddle.net Andrew Jones writes: > On Fri, Feb 26, 2016 at 02:54:33PM +0000, Alex Bennée wrote: >> >> Andrew Jones writes: >> >> > On Fri, Feb 26, 2016 at 01:15:22PM +0000, Alex Bennée wrote: >> >> Hi, >> >> >> >> Some of these patches have been posted before and previous patches >> >> have already been accepted upstream so I'm tagging this as a new RFC >> >> series. >> >> >> >> This is a series of tests built around kvm-unit-tests but built with >> >> the express purpose of stressing the TCG, in particular MTTCG builds. >> >> >> >> Changes from previous appearances: >> >> >> >> * Separated locking and barrier tests >> >> * Included Drew's IPI patches (used in tcg-test) >> >> * New TCG chaining test >> >> >> >> The new barrier tests really only fails when running on MTTCG builds on >> >> a weak backend. Many thanks to Will Deacon for helping me get a >> >> working test case at the last Connect. >> >> >> >> I'm mainly posting these for reference for others testing MTTCG as >> >> I've still got to check I've addressed any outstanding review >> >> comments. However there has been enough code churn some of the >> >> comments may no longer be relevant. >> >> >> >> The TCG tests are also useful as benchmarks for comparing the cost of >> >> having chained basic blocks versus exiting the loop every time. The >> >> pathological case is the computed jumps test as all the addresses are >> >> within a PAGE_SIZE boundary the tb_jump_cache has no effect meaning a >> >> full look up each time. >> >> >> >> Alex Bennée (8): >> >> config/config-arm-common: build-up tests-common target >> >> lib: add isaac prng library from CCAN >> >> arm/run: set indentation defaults for emacs >> >> arm/run: allow aarch64 to start arm binaries >> >> arm/tlbflush-test: Add TLB torture test >> >> arm/locking-tests: add comprehensive locking test >> >> arm/barrier-litmus-tests: add some litmus tests >> >> arm/tcg-test: some basic TCG exercising tests >> >> >> >> Andrew Jones (3): >> >> arm/arm64: irq enable/disable >> >> arm/arm64: Add initial gic support >> >> arm/arm64: Add IPI test >> > >> > I've actually updated these patches a bit, and started extending the >> > series to also work with a v3 gic. I'll pick that back up and get it >> > posted for you (hopefully next week). Or I'll at least update my >> > arm/ipi-test branch with the changes I've made for gicv2... >> >> Cool. >> >> One thing I noticed was a slight disparity between the number of IPI >> IRQs sent and the number received. However I'm assuming this could well >> be without any explicit synchronisation a second IPI can get swallowed >> up if the first hasn't been acknowledged yet. > > Hmm, this version of the test only sends/receives a single IPI, so > it should always be one/one. Or, are you watching the interrupts > somewhere else, and seeing more generated? Sorry I should have been clear. In my tcg-test with the "irq" modifier which sends an IRQ to every CPU every n-iterations. >> Is there any sane/safe way for gic_send_sgi to know if the IRQ was >> pending when it flips the bit? > > The new version wraps the acking in an if (iar != GICC_INT_SPURIOUS) > condition (I ripped that off of Marc's assembler version). That may > "fix" things for you, but then the question is why do you see spurious > interrupts? I'll add code that counts spurious interrupts too. Not spurious, less received than sent. I'll double check the code and make sure I count them up right. > > Thanks, > drew -- Alex Bennée