From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Huth Date: Tue, 10 May 2016 15:23:15 +0000 Subject: Re: [kvm-unit-test PATCH v2] powerpc: Add emulator test for the lswi instruction Message-Id: <5731FCE3.6010107@redhat.com> List-Id: References: <1460645382-31616-1-git-send-email-thuth@redhat.com> <571629BC.6000605@redhat.com> <57174AB9.2090900@redhat.com> <5731CE9B.9060904@redhat.com> In-Reply-To: <5731CE9B.9060904@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Paolo Bonzini , Laurent Vivier , kvm@vger.kernel.org Cc: kvm-ppc@vger.kernel.org, drjones@redhat.com On 10.05.2016 14:05, Paolo Bonzini wrote: > > > On 20/04/2016 11:24, Thomas Huth wrote: >>>> + ".long 0x7fe154aa\n" /* lswi r31, r1, 10 */ >>> >>> Perhaps you can add a comment explaining why you are using a .long >>> instead of the mnemonic? >> >> The compiler is smart enough to detect that r1 is in the range of >> registers that get clobbered, and thus rejects that mnemonic. You >> quickly notice that when replacing the .long with the mnemonic, so I'm >> not sure whether it's worth to add a verbose comment here... Paolo, what >> do you prefer? > > The assembler does this, not the compiler. Right, of course. > Is this a valid operation at all, or is it undefined? (aka, what > does it do on real hardware)? O_o The specification (PowerISA) says "If RA is in the range of registers to be loaded, including the case in which RA=0, the instruction form is invalid." ... which sounds like the CPU is supposed to raise an invalid instruction exception. However, on real hardware (POWER8), the CPU simply stops before loading that register and continues with the next instruction. In any case, the contents of the RA register should not be destroyed, and this is what we're testing here. (and this is also already mentioned in a comment later in the patch already, right before the report() line). Thomas From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Huth Subject: Re: [kvm-unit-test PATCH v2] powerpc: Add emulator test for the lswi instruction Date: Tue, 10 May 2016 17:23:15 +0200 Message-ID: <5731FCE3.6010107@redhat.com> References: <1460645382-31616-1-git-send-email-thuth@redhat.com> <571629BC.6000605@redhat.com> <57174AB9.2090900@redhat.com> <5731CE9B.9060904@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: kvm-ppc@vger.kernel.org, drjones@redhat.com To: Paolo Bonzini , Laurent Vivier , kvm@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57506 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752990AbcEJPXT (ORCPT ); Tue, 10 May 2016 11:23:19 -0400 In-Reply-To: <5731CE9B.9060904@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10.05.2016 14:05, Paolo Bonzini wrote: > > > On 20/04/2016 11:24, Thomas Huth wrote: >>>> + ".long 0x7fe154aa\n" /* lswi r31, r1, 10 */ >>> >>> Perhaps you can add a comment explaining why you are using a .long >>> instead of the mnemonic? >> >> The compiler is smart enough to detect that r1 is in the range of >> registers that get clobbered, and thus rejects that mnemonic. You >> quickly notice that when replacing the .long with the mnemonic, so I'm >> not sure whether it's worth to add a verbose comment here... Paolo, what >> do you prefer? > > The assembler does this, not the compiler. Right, of course. > Is this a valid operation at all, or is it undefined? (aka, what > does it do on real hardware)? O_o The specification (PowerISA) says "If RA is in the range of registers to be loaded, including the case in which RA=0, the instruction form is invalid." ... which sounds like the CPU is supposed to raise an invalid instruction exception. However, on real hardware (POWER8), the CPU simply stops before loading that register and continues with the next instruction. In any case, the contents of the RA register should not be destroyed, and this is what we're testing here. (and this is also already mentioned in a comment later in the patch already, right before the report() line). Thomas