From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Bellows Subject: Re: [Qemu-devel] [PATCH v2 4/6] target-arm: kvm64 sync FP register state Date: Wed, 11 Mar 2015 10:17:47 -0500 Message-ID: References: <1425479753-18349-1-git-send-email-alex.bennee@linaro.org> <1425479753-18349-5-git-send-email-alex.bennee@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: kvm@vger.kernel.org, Marc Zyngier , QEMU Developers , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Return-path: In-Reply-To: <1425479753-18349-5-git-send-email-alex.bennee@linaro.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu List-Id: kvm.vger.kernel.org T24gV2VkLCBNYXIgNCwgMjAxNSBhdCA4OjM1IEFNLCBBbGV4IEJlbm7DqWUgPGFsZXguYmVubmVl QGxpbmFyby5vcmc+IHdyb3RlOgo+IEZvciBtaWdyYXRpb24gdG8gd29yayB3ZSBuZWVkIHRvIHN5 bmMgYWxsIG9mIHRoZSByZWdpc3RlciBzdGF0ZS4gVGhpcyBpcwo+IGVzcGVjaWFsbHkgbm90aWNl YWJsZSB3aGVuIEdDQyBzdGFydHMgdXNpbmcgRlAgcmVnaXN0ZXJzIGFzIHNwaWxsCj4gcmVnaXN0 ZXJzIGV2ZW4gd2l0aCBpbnRlZ2VyIHByb2dyYW1zLgo+Cj4gU2lnbmVkLW9mZi1ieTogQWxleCBC ZW5uw6llIDxhbGV4LmJlbm5lZUBsaW5hcm8ub3JnPgo+Cj4gZGlmZiAtLWdpdCBhL3RhcmdldC1h cm0va3ZtNjQuYyBiL3RhcmdldC1hcm0va3ZtNjQuYwo+IGluZGV4IDhjZjNhNjIuLmM2MGU5ODkg MTAwNjQ0Cj4gLS0tIGEvdGFyZ2V0LWFybS9rdm02NC5jCj4gKysrIGIvdGFyZ2V0LWFybS9rdm02 NC5jCj4gQEAgLTEyNiw5ICsxMjYsMTcgQEAgYm9vbCBrdm1fYXJtX3JlZ19zeW5jc192aWFfY3By ZWdfbGlzdCh1aW50NjRfdCByZWdpZHgpCj4gICNkZWZpbmUgQUFSQ0g2NF9DT1JFX1JFRyh4KSAg IChLVk1fUkVHX0FSTTY0IHwgS1ZNX1JFR19TSVpFX1U2NCB8IFwKPiAgICAgICAgICAgICAgICAg ICBLVk1fUkVHX0FSTV9DT1JFIHwgS1ZNX1JFR19BUk1fQ09SRV9SRUcoeCkpCj4KPiArLyogVGhl IGxpbnV4IGhlYWRlcnMgZG9uJ3QgZGVmaW5lIGEgMTI4IGJpdCB3aWRlIFNJTUQgbWFjcm8gZm9y IHVzICovCj4gKyNkZWZpbmUgQUFSQ0g2NF9TSU1EX0NPUkVfUkVHKHgpICAgKEtWTV9SRUdfQVJN NjQgfCBLVk1fUkVHX1NJWkVfVTEyOCB8IFwKPiArICAgICAgICAgICAgICAgICBLVk1fUkVHX0FS TV9DT1JFIHwgS1ZNX1JFR19BUk1fQ09SRV9SRUcoeCkpCj4gKwo+ICsjZGVmaW5lIEFBUkNINjRf U0lNRF9DVFJMX1JFRyh4KSAgIChLVk1fUkVHX0FSTTY0IHwgS1ZNX1JFR19TSVpFX1UzMiB8IFwK PiArICAgICAgICAgICAgICAgICBLVk1fUkVHX0FSTV9DT1JFIHwgS1ZNX1JFR19BUk1fQ09SRV9S RUcoeCkpCj4gKwo+ICBpbnQga3ZtX2FyY2hfcHV0X3JlZ2lzdGVycyhDUFVTdGF0ZSAqY3MsIGlu dCBsZXZlbCkKPiAgewo+ICAgICAgc3RydWN0IGt2bV9vbmVfcmVnIHJlZzsKPiArICAgIHVpbnQz Ml90IGZwcjsKPiAgICAgIHVpbnQ2NF90IHZhbDsKPiAgICAgIGludCBpOwo+ICAgICAgaW50IHJl dDsKPiBAQCAtMjA3LDEzICsyMTUsMzYgQEAgaW50IGt2bV9hcmNoX3B1dF9yZWdpc3RlcnMoQ1BV U3RhdGUgKmNzLCBpbnQgbGV2ZWwpCj4gICAgICAgICAgfQo+ICAgICAgfQo+Cj4gKyAgICAvKiBB ZHZhbmNlZCBTSU1EIGFuZCBGUCByZWdpc3RlcnMgKi8KPiArICAgIGZvciAoaSA9IDA7IGkgPCAz MjsgaSsrKSB7Cj4gKyAgICAgICAgcmVnLmlkID0gQUFSQ0g2NF9TSU1EX0NPUkVfUkVHKGZwX3Jl Z3MudnJlZ3NbaV0pOwo+ICsgICAgICAgIHJlZy5hZGRyID0gKHVpbnRwdHJfdCkoJmVudi0+dmZw LnJlZ3NbaV0pOwo+ICsgICAgICAgIHJldCA9IGt2bV92Y3B1X2lvY3RsKGNzLCBLVk1fU0VUX09O RV9SRUcsICZyZWcpOwo+ICsgICAgICAgIGlmIChyZXQpIHsKPiArICAgICAgICAgICAgcmV0dXJu IHJldDsKPiArICAgICAgICB9Cj4gKyAgICAgICAgcmVnLmlkKys7CgpXaGF0IGRvZXMgdGhpcyBp bmNyZW1lbnQgZG8/ICBJdCBhcHBlYXJzIHRoYXQgaXQganVzdCBnZXRzIHRocm93biBhd2F5Cm9u IHRoZSBuZXh0IGl0ZXJhdGlvbiBvZiB0aGUgbG9vcCB1bmxlc3MgaW9jdGwoU0VUKSByZXR1cm4g c29tZXRoaW5nLApidXQgbWF5YmUgSSBhbSBtaXNzaW5nIHNvbWV0aGluZy4KCj4gKyAgICB9Cj4g Kwo+ICsgICAgcmVnLmFkZHIgPSAodWludHB0cl90KSgmZnByKTsKPiArICAgIGZwciA9IHZmcF9n ZXRfZnBzcihlbnYpOwo+ICsgICAgcmVnLmlkID0gQUFSQ0g2NF9TSU1EX0NUUkxfUkVHKGZwX3Jl Z3MuZnBzcik7Cj4gKyAgICByZXQgPSBrdm1fdmNwdV9pb2N0bChjcywgS1ZNX1NFVF9PTkVfUkVH LCAmcmVnKTsKPiArICAgIGlmIChyZXQpIHsKPiArICAgICAgICByZXR1cm4gcmV0Owo+ICsgICAg fQo+ICsKPiArICAgIGZwciA9IHZmcF9nZXRfZnBjcihlbnYpOwo+ICsgICAgcmVnLmlkID0gQUFS Q0g2NF9TSU1EX0NUUkxfUkVHKGZwX3JlZ3MuZnBjcik7Cj4gKyAgICByZXQgPSBrdm1fdmNwdV9p b2N0bChjcywgS1ZNX1NFVF9PTkVfUkVHLCAmcmVnKTsKPiArICAgIGlmIChyZXQpIHsKPiArICAg ICAgICByZXR1cm4gcmV0Owo+ICsgICAgfQo+ICsKPiAgICAgIGlmICghd3JpdGVfbGlzdF90b19r dm1zdGF0ZShjcHUpKSB7Cj4gICAgICAgICAgcmV0dXJuIEVJTlZBTDsKPiAgICAgIH0KPgo+IC0g ICAgLyogVE9ETzoKPiAtICAgICAqIEZQIHN0YXRlCj4gLSAgICAgKi8KPiAgICAgIHJldHVybiBy ZXQ7Cj4gIH0KPgo+IEBAIC0yMjEsNiArMjUyLDcgQEAgaW50IGt2bV9hcmNoX2dldF9yZWdpc3Rl cnMoQ1BVU3RhdGUgKmNzKQo+ICB7Cj4gICAgICBzdHJ1Y3Qga3ZtX29uZV9yZWcgcmVnOwo+ICAg ICAgdWludDY0X3QgdmFsOwo+ICsgICAgdWludDMyX3QgZnByOwo+ICAgICAgaW50IGk7Cj4gICAg ICBpbnQgcmV0Owo+Cj4gQEAgLTMwMiw5ICszMzQsMzYgQEAgaW50IGt2bV9hcmNoX2dldF9yZWdp c3RlcnMoQ1BVU3RhdGUgKmNzKQo+ICAgICAgICAgIH0KPiAgICAgIH0KPgo+ICsgICAgLyogQWR2 YW5jZWQgU0lNRCBhbmQgRlAgcmVnaXN0ZXJzICovCj4gKyAgICBmb3IgKGkgPSAwOyBpIDwgMzI7 IGkrKykgewo+ICsgICAgICAgIHJlZy5pZCA9IEFBUkNINjRfU0lNRF9DT1JFX1JFRyhmcF9yZWdz LnZyZWdzW2ldKTsKPiArICAgICAgICByZWcuYWRkciA9ICh1aW50cHRyX3QpKCZlbnYtPnZmcC5y ZWdzW2ldKTsKPiArICAgICAgICByZXQgPSBrdm1fdmNwdV9pb2N0bChjcywgS1ZNX0dFVF9PTkVf UkVHLCAmcmVnKTsKPiArICAgICAgICBpZiAocmV0KSB7Cj4gKyAgICAgICAgICAgIHJldHVybiBy ZXQ7Cj4gKyAgICAgICAgfQo+ICsgICAgICAgIHJlZy5pZCsrOwo+ICsgICAgfQo+ICsKPiArICAg IHJlZy5hZGRyID0gKHVpbnRwdHJfdCkoJmZwcik7Cj4gKyAgICByZWcuaWQgPSBBQVJDSDY0X1NJ TURfQ1RSTF9SRUcoZnBfcmVncy5mcHNyKTsKPiArICAgIHJldCA9IGt2bV92Y3B1X2lvY3RsKGNz LCBLVk1fR0VUX09ORV9SRUcsICZyZWcpOwo+ICsgICAgaWYgKHJldCkgewo+ICsgICAgICAgIHJl dHVybiByZXQ7Cj4gKyAgICB9Cj4gKyAgICB2ZnBfc2V0X2Zwc3IoZW52LCBmcHIpOwo+ICsKPiAr ICAgIHJlZy5pZCA9IEFBUkNINjRfU0lNRF9DVFJMX1JFRyhmcF9yZWdzLmZwY3IpOwo+ICsgICAg cmV0ID0ga3ZtX3ZjcHVfaW9jdGwoY3MsIEtWTV9HRVRfT05FX1JFRywgJnJlZyk7Cj4gKyAgICBp ZiAocmV0KSB7Cj4gKyAgICAgICAgcmV0dXJuIHJldDsKPiArICAgIH0KPiArICAgIHZmcF9zZXRf ZnBjcihlbnYsIGZwcik7Cj4gKwo+ICAgICAgaWYgKCF3cml0ZV9rdm1zdGF0ZV90b19saXN0KGNw dSkpIHsKPiAgICAgICAgICByZXR1cm4gRUlOVkFMOwo+ICAgICAgfQo+ICsKPiAgICAgIC8qIE5v dGUgdGhhdCBpdCdzIE9LIHRvIGhhdmUgcmVnaXN0ZXJzIHdoaWNoIGFyZW4ndCBpbiBDUFVTdGF0 ZSwKPiAgICAgICAqIHNvIHdlIGNhbiBpZ25vcmUgYSBmYWlsdXJlIHJldHVybiBoZXJlLgo+ICAg ICAgICovCj4gLS0KPiAyLjMuMQo+Cj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18Ka3ZtYXJtIG1haWxpbmcgbGlzdAprdm1hcm1AbGlzdHMuY3MuY29sdW1i aWEuZWR1Cmh0dHBzOi8vbGlzdHMuY3MuY29sdW1iaWEuZWR1L21haWxtYW4vbGlzdGluZm8va3Zt YXJtCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YViON-0004hy-SL for qemu-devel@nongnu.org; Wed, 11 Mar 2015 11:17:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YViOK-0007ey-IY for qemu-devel@nongnu.org; Wed, 11 Mar 2015 11:17:51 -0400 Received: from mail-qc0-f173.google.com ([209.85.216.173]:36492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YViOK-0007ea-DH for qemu-devel@nongnu.org; Wed, 11 Mar 2015 11:17:48 -0400 Received: by qcxm20 with SMTP id m20so10958826qcx.3 for ; Wed, 11 Mar 2015 08:17:47 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1425479753-18349-5-git-send-email-alex.bennee@linaro.org> References: <1425479753-18349-1-git-send-email-alex.bennee@linaro.org> <1425479753-18349-5-git-send-email-alex.bennee@linaro.org> Date: Wed, 11 Mar 2015 10:17:47 -0500 Message-ID: From: Greg Bellows Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 4/6] target-arm: kvm64 sync FP register state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: Peter Maydell , kvm@vger.kernel.org, Marc Zyngier , QEMU Developers , Christoffer Dall , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org On Wed, Mar 4, 2015 at 8:35 AM, Alex Benn=C3=A9e w= rote: > For migration to work we need to sync all of the register state. This is > especially noticeable when GCC starts using FP registers as spill > registers even with integer programs. > > Signed-off-by: Alex Benn=C3=A9e > > diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c > index 8cf3a62..c60e989 100644 > --- a/target-arm/kvm64.c > +++ b/target-arm/kvm64.c > @@ -126,9 +126,17 @@ bool kvm_arm_reg_syncs_via_cpreg_list(uint64_t regid= x) > #define AARCH64_CORE_REG(x) (KVM_REG_ARM64 | KVM_REG_SIZE_U64 | \ > KVM_REG_ARM_CORE | KVM_REG_ARM_CORE_REG(x)) > > +/* The linux headers don't define a 128 bit wide SIMD macro for us */ > +#define AARCH64_SIMD_CORE_REG(x) (KVM_REG_ARM64 | KVM_REG_SIZE_U128 | = \ > + KVM_REG_ARM_CORE | KVM_REG_ARM_CORE_REG(x)) > + > +#define AARCH64_SIMD_CTRL_REG(x) (KVM_REG_ARM64 | KVM_REG_SIZE_U32 | \ > + KVM_REG_ARM_CORE | KVM_REG_ARM_CORE_REG(x)) > + > int kvm_arch_put_registers(CPUState *cs, int level) > { > struct kvm_one_reg reg; > + uint32_t fpr; > uint64_t val; > int i; > int ret; > @@ -207,13 +215,36 @@ int kvm_arch_put_registers(CPUState *cs, int level) > } > } > > + /* Advanced SIMD and FP registers */ > + for (i =3D 0; i < 32; i++) { > + reg.id =3D AARCH64_SIMD_CORE_REG(fp_regs.vregs[i]); > + reg.addr =3D (uintptr_t)(&env->vfp.regs[i]); > + ret =3D kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + reg.id++; What does this increment do? It appears that it just gets thrown away on the next iteration of the loop unless ioctl(SET) return something, but maybe I am missing something. > + } > + > + reg.addr =3D (uintptr_t)(&fpr); > + fpr =3D vfp_get_fpsr(env); > + reg.id =3D AARCH64_SIMD_CTRL_REG(fp_regs.fpsr); > + ret =3D kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + > + fpr =3D vfp_get_fpcr(env); > + reg.id =3D AARCH64_SIMD_CTRL_REG(fp_regs.fpcr); > + ret =3D kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + > if (!write_list_to_kvmstate(cpu)) { > return EINVAL; > } > > - /* TODO: > - * FP state > - */ > return ret; > } > > @@ -221,6 +252,7 @@ int kvm_arch_get_registers(CPUState *cs) > { > struct kvm_one_reg reg; > uint64_t val; > + uint32_t fpr; > int i; > int ret; > > @@ -302,9 +334,36 @@ int kvm_arch_get_registers(CPUState *cs) > } > } > > + /* Advanced SIMD and FP registers */ > + for (i =3D 0; i < 32; i++) { > + reg.id =3D AARCH64_SIMD_CORE_REG(fp_regs.vregs[i]); > + reg.addr =3D (uintptr_t)(&env->vfp.regs[i]); > + ret =3D kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + reg.id++; > + } > + > + reg.addr =3D (uintptr_t)(&fpr); > + reg.id =3D AARCH64_SIMD_CTRL_REG(fp_regs.fpsr); > + ret =3D kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + vfp_set_fpsr(env, fpr); > + > + reg.id =3D AARCH64_SIMD_CTRL_REG(fp_regs.fpcr); > + ret =3D kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + vfp_set_fpcr(env, fpr); > + > if (!write_kvmstate_to_list(cpu)) { > return EINVAL; > } > + > /* Note that it's OK to have registers which aren't in CPUState, > * so we can ignore a failure return here. > */ > -- > 2.3.1 > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: greg.bellows@linaro.org (Greg Bellows) Date: Wed, 11 Mar 2015 10:17:47 -0500 Subject: [Qemu-devel] [PATCH v2 4/6] target-arm: kvm64 sync FP register state In-Reply-To: <1425479753-18349-5-git-send-email-alex.bennee@linaro.org> References: <1425479753-18349-1-git-send-email-alex.bennee@linaro.org> <1425479753-18349-5-git-send-email-alex.bennee@linaro.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Mar 4, 2015 at 8:35 AM, Alex Benn?e wrote: > For migration to work we need to sync all of the register state. This is > especially noticeable when GCC starts using FP registers as spill > registers even with integer programs. > > Signed-off-by: Alex Benn?e > > diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c > index 8cf3a62..c60e989 100644 > --- a/target-arm/kvm64.c > +++ b/target-arm/kvm64.c > @@ -126,9 +126,17 @@ bool kvm_arm_reg_syncs_via_cpreg_list(uint64_t regidx) > #define AARCH64_CORE_REG(x) (KVM_REG_ARM64 | KVM_REG_SIZE_U64 | \ > KVM_REG_ARM_CORE | KVM_REG_ARM_CORE_REG(x)) > > +/* The linux headers don't define a 128 bit wide SIMD macro for us */ > +#define AARCH64_SIMD_CORE_REG(x) (KVM_REG_ARM64 | KVM_REG_SIZE_U128 | \ > + KVM_REG_ARM_CORE | KVM_REG_ARM_CORE_REG(x)) > + > +#define AARCH64_SIMD_CTRL_REG(x) (KVM_REG_ARM64 | KVM_REG_SIZE_U32 | \ > + KVM_REG_ARM_CORE | KVM_REG_ARM_CORE_REG(x)) > + > int kvm_arch_put_registers(CPUState *cs, int level) > { > struct kvm_one_reg reg; > + uint32_t fpr; > uint64_t val; > int i; > int ret; > @@ -207,13 +215,36 @@ int kvm_arch_put_registers(CPUState *cs, int level) > } > } > > + /* Advanced SIMD and FP registers */ > + for (i = 0; i < 32; i++) { > + reg.id = AARCH64_SIMD_CORE_REG(fp_regs.vregs[i]); > + reg.addr = (uintptr_t)(&env->vfp.regs[i]); > + ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + reg.id++; What does this increment do? It appears that it just gets thrown away on the next iteration of the loop unless ioctl(SET) return something, but maybe I am missing something. > + } > + > + reg.addr = (uintptr_t)(&fpr); > + fpr = vfp_get_fpsr(env); > + reg.id = AARCH64_SIMD_CTRL_REG(fp_regs.fpsr); > + ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + > + fpr = vfp_get_fpcr(env); > + reg.id = AARCH64_SIMD_CTRL_REG(fp_regs.fpcr); > + ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + > if (!write_list_to_kvmstate(cpu)) { > return EINVAL; > } > > - /* TODO: > - * FP state > - */ > return ret; > } > > @@ -221,6 +252,7 @@ int kvm_arch_get_registers(CPUState *cs) > { > struct kvm_one_reg reg; > uint64_t val; > + uint32_t fpr; > int i; > int ret; > > @@ -302,9 +334,36 @@ int kvm_arch_get_registers(CPUState *cs) > } > } > > + /* Advanced SIMD and FP registers */ > + for (i = 0; i < 32; i++) { > + reg.id = AARCH64_SIMD_CORE_REG(fp_regs.vregs[i]); > + reg.addr = (uintptr_t)(&env->vfp.regs[i]); > + ret = kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + reg.id++; > + } > + > + reg.addr = (uintptr_t)(&fpr); > + reg.id = AARCH64_SIMD_CTRL_REG(fp_regs.fpsr); > + ret = kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + vfp_set_fpsr(env, fpr); > + > + reg.id = AARCH64_SIMD_CTRL_REG(fp_regs.fpcr); > + ret = kvm_vcpu_ioctl(cs, KVM_GET_ONE_REG, ®); > + if (ret) { > + return ret; > + } > + vfp_set_fpcr(env, fpr); > + > if (!write_kvmstate_to_list(cpu)) { > return EINVAL; > } > + > /* Note that it's OK to have registers which aren't in CPUState, > * so we can ignore a failure return here. > */ > -- > 2.3.1 > >