From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5F1N-0008BS-MO for qemu-devel@nongnu.org; Thu, 10 Jul 2014 10:08:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5F1F-0003Qj-Tu for qemu-devel@nongnu.org; Thu, 10 Jul 2014 10:08:25 -0400 Message-ID: <53BE9E4F.2090000@suse.de> Date: Thu, 10 Jul 2014 16:08:15 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1404989882-17362-1-git-send-email-Bharat.Bhushan@freescale.com> <1404989882-17362-2-git-send-email-Bharat.Bhushan@freescale.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/6 v6] ppc: debug stub: Get trap instruction opcode from KVM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Bharat Bhushan Cc: maddy@linux.vnet.ibm.com, "qemu-ppc@nongnu.org" , QEMU Developers On 10.07.14 16:07, Peter Maydell wrote: > On 10 July 2014 11:57, Bharat Bhushan wrote: >> Get trap instruction opcode from KVM and this opcode will >> be used for setting software breakpoint in following patch >> >> Signed-off-by: Bharat Bhushan >> --- >> v5->v6 >> - no change >> >> target-ppc/kvm.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c >> index 2d87108..4df23dd 100644 >> --- a/target-ppc/kvm.c >> +++ b/target-ppc/kvm.c >> @@ -72,6 +72,8 @@ static int cap_papr; >> static int cap_htab_fd; >> static int cap_fixup_hcalls; >> >> +static uint32_t debug_inst_opcode; >> + >> /* XXX We have a race condition where we actually have a level triggered >> * interrupt, but the infrastructure can't expose that yet, so the guest >> * takes but ignores it, goes to sleep and never gets notified that there's >> @@ -436,6 +438,8 @@ int kvm_arch_init_vcpu(CPUState *cs) >> break; >> } >> >> + kvm_get_one_reg(cs, KVM_REG_PPC_DEBUG_INST, &debug_inst_opcode); >> + > Presumably the kernel guarantees that this is always the > same value for every CPU in the system? Yes :) Alex