qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Bennée
Subject: Re: [Qemu-devel] [RFC 00/11] Current MTTCG kvm-unit-test patches
Date: Fri, 26 Feb 2016 16:03:57 +0000
User-agent: mu4e 0.9.17; emacs 25.0.91.1

Andrew Jones <address@hidden> writes:

> On Fri, Feb 26, 2016 at 02:54:33PM +0000, Alex Bennée wrote:
>>
>> Andrew Jones <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]