From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ND0Sl-0004kw-6p for qemu-devel@nongnu.org; Tue, 24 Nov 2009 13:50:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ND0Sf-0004iS-QM for qemu-devel@nongnu.org; Tue, 24 Nov 2009 13:50:05 -0500 Received: from [199.232.76.173] (port=55997 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ND0Sf-0004iN-HM for qemu-devel@nongnu.org; Tue, 24 Nov 2009 13:50:01 -0500 Received: from thoth.sbs.de ([192.35.17.2]:23372) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ND0Se-0002xZ-UN for qemu-devel@nongnu.org; Tue, 24 Nov 2009 13:50:01 -0500 Message-ID: <4B0C2AD5.6070404@siemens.com> Date: Tue, 24 Nov 2009 19:49:57 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1259049712-8165-1-git-send-email-agraf@suse.de> <1259049712-8165-2-git-send-email-agraf@suse.de> <4B0C1F77.9010107@siemens.com> <24552AC9-1CE4-4750-9D5D-EDBB88CEA716@suse.de> <4B0C2215.3090004@siemens.com> <565ED192-6DB0-4209-A343-7CCF97239F60@suse.de> <4B0C2709.9060306@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] PPC: Get MMU state on register sync List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-devel@nongnu.org" Alexander Graf wrote: > On 24.11.2009, at 19:33, Jan Kiszka wrote: > >> Alexander Graf wrote: >>> On 24.11.2009, at 19:12, Jan Kiszka wrote: >>> >>>> Alexander Graf wrote: >>>>> On 24.11.2009, at 19:01, Jan Kiszka wrote: >>>>> >>>>>> Alexander Graf wrote: >>>>>>> While x86 only needs to sync cr0-4 to know all about its MMU state and enable >>>>>>> qemu to resolve virtual to physical addresses, we need to sync all of the >>>>>>> segment registers on PPC to know which mapping we're in. >>>>>>> >>>>>>> So let's grab the segment register contents to be able to use the "x" monitor >>>>>>> command and also enable the gdbstub to resolve virtual addresses. >>>>>>> >>>>>>> I sent the corresponding KVM patch to the KVM ML some minutes ago. >>>>>>> >>>>>>> Signed-off-by: Alexander Graf >>>>>>> --- >>>>>>> target-ppc/kvm.c | 30 ++++++++++++++++++++++++++++++ >>>>>>> 1 files changed, 30 insertions(+), 0 deletions(-) >>>>>>> >>>>>>> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c >>>>>>> index 4e1c65f..566513f 100644 >>>>>>> --- a/target-ppc/kvm.c >>>>>>> +++ b/target-ppc/kvm.c >>>>>>> @@ -98,12 +98,17 @@ int kvm_arch_put_registers(CPUState *env) >>>>>>> int kvm_arch_get_registers(CPUState *env) >>>>>>> { >>>>>>> struct kvm_regs regs; >>>>>>> + struct kvm_sregs sregs; >>>>>>> uint32_t i, ret; >>>>>>> >>>>>>> ret = kvm_vcpu_ioctl(env, KVM_GET_REGS, ®s); >>>>>>> if (ret < 0) >>>>>>> return ret; >>>>>>> >>>>>>> + ret = kvm_vcpu_ioctl(env, KVM_GET_SREGS, &sregs); >>>>>>> + if (ret < 0) >>>>>>> + return ret; >>>>>>> + >>>>>>> env->ctr = regs.ctr; >>>>>>> env->lr = regs.lr; >>>>>>> env->xer = regs.xer; >>>>>>> @@ -125,6 +130,31 @@ int kvm_arch_get_registers(CPUState *env) >>>>>>> for (i = 0;i < 32; i++) >>>>>>> env->gpr[i] = regs.gpr[i]; >>>>>>> >>>>>>> +#ifdef KVM_CAP_PPC_SEGSTATE >>>>>>> + if (kvm_check_extension(env->kvm_state, KVM_CAP_PPC_SEGSTATE)) { >>>>>>> + env->sdr1 = sregs.sdr1; >>>>>>> + >>>>>>> + /* Sync SLB */ >>>>>>> + for (i = 0; i < 64; i++) { >>>>>>> + ppc_store_slb(env, sregs.ppc64.slb[i].slbe, >>>>>>> + sregs.ppc64.slb[i].slbv); >>>>>>> + } >>>>>>> + >>>>>>> + /* Sync SRs */ >>>>>>> + for (i = 0; i < 16; i++) { >>>>>>> + env->sr[i] = sregs.ppc32.sr[i]; >>>>>>> + } >>>>>>> + >>>>>>> + /* Sync BATs */ >>>>>>> + for (i = 0; i < 8; i++) { >>>>>>> + env->DBAT[0][i] = sregs.ppc32.dbat[i] & 0xffffffff; >>>>>>> + env->DBAT[1][i] = sregs.ppc32.dbat[i] >> 32; >>>>>>> + env->IBAT[0][i] = sregs.ppc32.ibat[i] & 0xffffffff; >>>>>>> + env->IBAT[1][i] = sregs.ppc32.ibat[i] >> 32; >>>>>>> + } >>>>>>> + } >>>>>>> +#endif >>>>>>> + >>>>>>> return 0; >>>>>>> } >>>>>>> >>>>>> What about KVM_SET_SREGS in kvm_arch_put_registers? E.g. to play back >>>>>> potential changes to that special registers someone did via gdb? >>>>> I don't think you can actually change the segment values. At least I can't imagine why. >>>> Dunno about PPC in this regard and how much value it has, but we have >>>> segment register access via gdb for x86. >>> The segments here are more like PLM4 on x86. >> Even that will be settable one day (gdb just do not yet know much about >> x86 system management registers). >> >>>>> I definitely will implement SET_SREGS as soon as your sync split is in, as that's IMHO only really required on migration. >>>>> >>>> Migration is, of course, the major use case. >>>> >>>> Still I wonder why not making this API symmetric when already touching it. >>> I was afraid to introduce performance regressions - setting the segments means flushing the complete shadow MMU. >>> >> Unless it costs milliseconds, not really critical, given how often >> registers are synchronized. >> >> BTW, I noticed that ppc only syncs the SREGS once on init, not on reset >> - are they static? > > So far SREGS are only used for setting the PVR (cpuid in x86 speech). There's no need to reset that on reset :-). Then I don't get why you need to re-read them during runtime - user space should know the state and should be able push it into the CPUState on init. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux