Re: [PATCH v2 4/5] KVM: selftests: Add exception handling support for aarch64

From: Marc Zyngier <maz@kernel.org>
To: Ricardo Koller <ricarkol@google.com>
Cc: Zenghui Yu <yuzenghui@huawei.com>,
	Auger Eric <eric.auger@redhat.com>,
	kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	pbonzini@redhat.com, drjones@redhat.com,
	alexandru.elisei@arm.com
Subject: Re: [PATCH v2 4/5] KVM: selftests: Add exception handling support for aarch64
Date: Wed, 12 May 2021 17:18:42 +0100	[thread overview]
Message-ID: <ad3fd18571983a08952f523ad5091360@kernel.org> (raw)
In-Reply-To: <YJv8NUtKilXPDYpY@google.com>

On 2021-05-12 17:03, Ricardo Koller wrote:
> On Wed, May 12, 2021 at 02:43:28PM +0100, Marc Zyngier wrote:
>> On 2021-05-12 13:59, Zenghui Yu wrote:
>> > Hi Eric,
>> >
>> > On 2021/5/6 20:30, Auger Eric wrote:
>> > > running the test on 5.12 I get
>> > >
>> > > ==== Test Assertion Failure ====
>> > >   aarch64/debug-exceptions.c:232: false
>> > >   pid=6477 tid=6477 errno=4 - Interrupted system call
>> > >      1	0x000000000040147b: main at debug-exceptions.c:230
>> > >      2	0x000003ff8aa60de3: ?? ??:0
>> > >      3	0x0000000000401517: _start at :?
>> > >   Failed guest assert: hw_bp_addr == PC(hw_bp) at
>> > > aarch64/debug-exceptions.c:105
>> > > 	values: 0, 0x401794
>> >
>> > FYI I can also reproduce it on my VHE box. And Drew's suggestion [*]
>> > seemed to work for me. Is the ISB a requirement of architecture?
>> 
>> Very much so. Given that there is no context synchronisation (such as
>> ERET or an interrupt) in this code, the CPU is perfectly allowed to
>> delay the system register effect as long as it can.
>> 
>>         M.
>> --
>> Jazz is not dead. It just smells funny...
> 
> Thank you very much Eric, Zenghui, Marc, and Andrew (for the ISB
> suggestion)!
> 
> As per Zenghui test, will send a V3 that includes the missing ISBs.
> Hopefully that will fix the issue for Eric as well. It's very
> interesting that the CPU seems to _always_ reorder those instructions.

I suspect that because hitting the debug registers can be a costly
operation (it mobilises a lot of resources in the CPU), there is
a strong incentive to let it slide until there is an actual mandate
to commit the resource.

It also means that SW can issue a bunch of these without too much
overhead, and only pay the cost *once*.

Your N1 CPU seems to be less aggressive on this. Implement choice,
I'd say (it probably is more aggressive than TX2 on other things).
Also, QEMU will almost always hide these problems, due to the nature
of TCG.

Thanks,

          M.
-- 
Jazz is not dead. It just smells funny...