Re: [Qemu-devel] [RFC 00/11] Current MTTCG kvm-unit-test patches

["Alex Bennée" <alex.bennee@linaro.org>]

Andrew Jones <drjones@redhat.com> 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.

Is there any sane/safe way for gic_send_sgi to know if the IRQ was
pending when it flips the bit?

>
> drew


--
Alex Bennée