Re: [PATCH 2/3] KVM: arm64: Correctly handle zero register in system register accesses
On 03/12/15 11:55, Pavel Fedin wrote: > Hello! > >>> It's simply more convenient to use a pointer for exchange with >>> userspace, see vgic_v3_cpu_regs_access() and callers. I wouldn't like >>> to refactor the code again. What's your opinion on this? >> >> I still don't think this is a good idea. You can still store the value >> as an integer in vgic_v3_cpu_regs_access(), and check the write property >> to do the writeback on read. Which is the same thing I asked for in this >> patch. > > Started doing this and found one more (big) reason against. All sysreg > handlers have 'const struct sys_reg_params' declaration, and > callers, and their callers... This 'const' is all around the code, and it > would take a separate huge patch to un-const'ify all this. > Does it worth that? maz@approximate:~/Work/arm-platforms$ git diff --stat arch/arm64/kvm/sys_regs.c | 36 ++-- arch/arm64/kvm/sys_regs.h | 2 +- 2 files changed, 19 insertions(+), 19 deletions(-) Hardly a big deal... You can have that as a separate patch. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3] KVM: arm64: Correctly handle zero register in system register accesses
Hello! > > It's simply more convenient to use a pointer for exchange with > > userspace, see vgic_v3_cpu_regs_access() and callers. I wouldn't like > > to refactor the code again. What's your opinion on this? > > I still don't think this is a good idea. You can still store the value > as an integer in vgic_v3_cpu_regs_access(), and check the write property > to do the writeback on read. Which is the same thing I asked for in this > patch. Started doing this and found one more (big) reason against. All sysreg handlers have 'const struct sys_reg_params' declaration, and callers, and their callers... This 'const' is all around the code, and it would take a separate huge patch to un-const'ify all this. Does it worth that? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] KVM: arm64: Correctly handle zero register in system register accesses
On 03/12/15 11:08, Pavel Fedin wrote: > Hello! > >>> diff --git a/arch/arm64/kvm/sys_regs.c >>> b/arch/arm64/kvm/sys_regs.c index 87a64e8..a667228 100644 --- >>> a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ >>> -102,7 +102,7 @@ static bool access_vm_reg(struct kvm_vcpu >>> *vcpu, >>> >>> BUG_ON(!p->is_write); >>> >>> - val = *vcpu_reg(vcpu, p->Rt); + val = *p->val; >> >> Why does it have to be a pointer? You could just have "val = >> p->val" if you carried the actual value instead of a pointer to the >> stack variable holding that value. > > There's only one concern for pointer approach. Actually, this > refactor is based on my vGICv3 live migration API patch set: > http://www.spinics.net/lists/kvm/msg124205.html > http://www.spinics.net/lists/kvm/msg124202.html > > It's simply more convenient to use a pointer for exchange with > userspace, see vgic_v3_cpu_regs_access() and callers. I wouldn't like > to refactor the code again. What's your opinion on this? I still don't think this is a good idea. You can still store the value as an integer in vgic_v3_cpu_regs_access(), and check the write property to do the writeback on read. Which is the same thing I asked for in this patch. > And of course i'll fix up the rest. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3] KVM: arm64: Correctly handle zero register in system register accesses
Hello! > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index 87a64e8..a667228 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -102,7 +102,7 @@ static bool access_vm_reg(struct kvm_vcpu *vcpu, > > > > BUG_ON(!p->is_write); > > > > - val = *vcpu_reg(vcpu, p->Rt); > > + val = *p->val; > > Why does it have to be a pointer? You could just have "val = p->val" if > you carried the actual value instead of a pointer to the stack variable > holding that value. There's only one concern for pointer approach. Actually, this refactor is based on my vGICv3 live migration API patch set: http://www.spinics.net/lists/kvm/msg124205.html http://www.spinics.net/lists/kvm/msg124202.html It's simply more convenient to use a pointer for exchange with userspace, see vgic_v3_cpu_regs_access() and callers. I wouldn't like to refactor the code again. What's your opinion on this? And of course i'll fix up the rest. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] KVM: arm64: Correctly handle zero register in system register accesses
Pavel,
On 03/12/15 09:58, Pavel Fedin wrote:
> System register accesses also use zero register for Rt == 31, and
> therefore using it will also result in getting SP value instead. This
> patch makes them also using new accessors, introduced by the previous
> patch.
>
> Additionally, got rid of "massive hack" in kvm_handle_cp_64().
Looks good for a first drop - some comments below.
>
> Signed-off-by: Pavel Fedin
> ---
> arch/arm64/kvm/sys_regs.c| 79
>
> arch/arm64/kvm/sys_regs.h| 4 +-
> arch/arm64/kvm/sys_regs_generic_v8.c | 2 +-
> 3 files changed, 46 insertions(+), 39 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 87a64e8..a667228 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -102,7 +102,7 @@ static bool access_vm_reg(struct kvm_vcpu *vcpu,
>
> BUG_ON(!p->is_write);
>
> - val = *vcpu_reg(vcpu, p->Rt);
> + val = *p->val;
Why does it have to be a pointer? You could just have "val = p->val" if
you carried the actual value instead of a pointer to the stack variable
holding that value.
> if (!p->is_aarch32) {
> vcpu_sys_reg(vcpu, r->reg) = val;
> } else {
> @@ -125,13 +125,10 @@ static bool access_gic_sgi(struct kvm_vcpu *vcpu,
> const struct sys_reg_params *p,
> const struct sys_reg_desc *r)
> {
> - u64 val;
> -
> if (!p->is_write)
> return read_from_write_only(vcpu, p);
>
> - val = *vcpu_reg(vcpu, p->Rt);
> - vgic_v3_dispatch_sgi(vcpu, val);
> + vgic_v3_dispatch_sgi(vcpu, *p->val);
>
> return true;
> }
> @@ -153,7 +150,7 @@ static bool trap_oslsr_el1(struct kvm_vcpu *vcpu,
> if (p->is_write) {
> return ignore_write(vcpu, p);
> } else {
> - *vcpu_reg(vcpu, p->Rt) = (1 << 3);
> + *p->val = (1 << 3);
> return true;
> }
> }
> @@ -167,7 +164,7 @@ static bool trap_dbgauthstatus_el1(struct kvm_vcpu *vcpu,
> } else {
> u32 val;
> asm volatile("mrs %0, dbgauthstatus_el1" : "=r" (val));
> - *vcpu_reg(vcpu, p->Rt) = val;
> + *p->val = val;
> return true;
> }
> }
> @@ -204,13 +201,13 @@ static bool trap_debug_regs(struct kvm_vcpu *vcpu,
> const struct sys_reg_desc *r)
> {
> if (p->is_write) {
> - vcpu_sys_reg(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt);
> + vcpu_sys_reg(vcpu, r->reg) = *p->val;
> vcpu->arch.debug_flags |= KVM_ARM64_DEBUG_DIRTY;
> } else {
> - *vcpu_reg(vcpu, p->Rt) = vcpu_sys_reg(vcpu, r->reg);
> + *p->val = vcpu_sys_reg(vcpu, r->reg);
> }
>
> - trace_trap_reg(__func__, r->reg, p->is_write, *vcpu_reg(vcpu, p->Rt));
> + trace_trap_reg(__func__, r->reg, p->is_write, *p->val);
>
> return true;
> }
> @@ -228,7 +225,7 @@ static inline void reg_to_dbg(struct kvm_vcpu *vcpu,
> const struct sys_reg_params *p,
> u64 *dbg_reg)
> {
> - u64 val = *vcpu_reg(vcpu, p->Rt);
> + u64 val = *p->val;
>
> if (p->is_32bit) {
> val &= 0xUL;
> @@ -248,7 +245,7 @@ static inline void dbg_to_reg(struct kvm_vcpu *vcpu,
> if (p->is_32bit)
> val &= 0xUL;
>
> - *vcpu_reg(vcpu, p->Rt) = val;
> + *p->val = val;
> }
>
> static inline bool trap_bvr(struct kvm_vcpu *vcpu,
> @@ -697,10 +694,10 @@ static bool trap_dbgidr(struct kvm_vcpu *vcpu,
> u64 pfr = read_system_reg(SYS_ID_AA64PFR0_EL1);
> u32 el3 = !!cpuid_feature_extract_field(pfr,
> ID_AA64PFR0_EL3_SHIFT);
>
> - *vcpu_reg(vcpu, p->Rt) = dfr >> ID_AA64DFR0_WRPS_SHIFT) &
> 0xf) << 28) |
> - (((dfr >> ID_AA64DFR0_BRPS_SHIFT) &
> 0xf) << 24) |
> - (((dfr >> ID_AA64DFR0_CTX_CMPS_SHIFT)
> & 0xf) << 20) |
> - (6 << 16) | (el3 << 14) | (el3 <<
> 12));
> + *p->val = dfr >> ID_AA64DFR0_WRPS_SHIFT) & 0xf) << 28) |
> +(((dfr >> ID_AA64DFR0_BRPS_SHIFT) & 0xf) << 24) |
> +(((dfr >> ID_AA64DFR0_CTX_CMPS_SHIFT) & 0xf) << 20) |
> +(6 << 16) | (el3 << 14) | (el3 << 12));
> return true;
> }
> }
> @@ -710,10 +707,10 @@ static bool trap_debug32(struct kvm_vcpu *vcpu,
>const struct sys_reg_desc *r)
> {
> if (p->is_write) {
> - vcpu_cp14(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt);
> + vcpu_cp14(vcpu, r->reg) = *p->val;
> vcpu->arch.debug_flags |= KVM_ARM64_DEBUG_DIRTY;
> } else {
> - *vcpu_reg(vcpu, p->Rt) = vcpu_cp14(vcpu, r->reg);
> + *p->val = vcpu_
[PATCH 2/3] KVM: arm64: Correctly handle zero register in system register accesses
System register accesses also use zero register for Rt == 31, and
therefore using it will also result in getting SP value instead. This
patch makes them also using new accessors, introduced by the previous
patch.
Additionally, got rid of "massive hack" in kvm_handle_cp_64().
Signed-off-by: Pavel Fedin
---
arch/arm64/kvm/sys_regs.c| 79
arch/arm64/kvm/sys_regs.h| 4 +-
arch/arm64/kvm/sys_regs_generic_v8.c | 2 +-
3 files changed, 46 insertions(+), 39 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 87a64e8..a667228 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -102,7 +102,7 @@ static bool access_vm_reg(struct kvm_vcpu *vcpu,
BUG_ON(!p->is_write);
- val = *vcpu_reg(vcpu, p->Rt);
+ val = *p->val;
if (!p->is_aarch32) {
vcpu_sys_reg(vcpu, r->reg) = val;
} else {
@@ -125,13 +125,10 @@ static bool access_gic_sgi(struct kvm_vcpu *vcpu,
const struct sys_reg_params *p,
const struct sys_reg_desc *r)
{
- u64 val;
-
if (!p->is_write)
return read_from_write_only(vcpu, p);
- val = *vcpu_reg(vcpu, p->Rt);
- vgic_v3_dispatch_sgi(vcpu, val);
+ vgic_v3_dispatch_sgi(vcpu, *p->val);
return true;
}
@@ -153,7 +150,7 @@ static bool trap_oslsr_el1(struct kvm_vcpu *vcpu,
if (p->is_write) {
return ignore_write(vcpu, p);
} else {
- *vcpu_reg(vcpu, p->Rt) = (1 << 3);
+ *p->val = (1 << 3);
return true;
}
}
@@ -167,7 +164,7 @@ static bool trap_dbgauthstatus_el1(struct kvm_vcpu *vcpu,
} else {
u32 val;
asm volatile("mrs %0, dbgauthstatus_el1" : "=r" (val));
- *vcpu_reg(vcpu, p->Rt) = val;
+ *p->val = val;
return true;
}
}
@@ -204,13 +201,13 @@ static bool trap_debug_regs(struct kvm_vcpu *vcpu,
const struct sys_reg_desc *r)
{
if (p->is_write) {
- vcpu_sys_reg(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt);
+ vcpu_sys_reg(vcpu, r->reg) = *p->val;
vcpu->arch.debug_flags |= KVM_ARM64_DEBUG_DIRTY;
} else {
- *vcpu_reg(vcpu, p->Rt) = vcpu_sys_reg(vcpu, r->reg);
+ *p->val = vcpu_sys_reg(vcpu, r->reg);
}
- trace_trap_reg(__func__, r->reg, p->is_write, *vcpu_reg(vcpu, p->Rt));
+ trace_trap_reg(__func__, r->reg, p->is_write, *p->val);
return true;
}
@@ -228,7 +225,7 @@ static inline void reg_to_dbg(struct kvm_vcpu *vcpu,
const struct sys_reg_params *p,
u64 *dbg_reg)
{
- u64 val = *vcpu_reg(vcpu, p->Rt);
+ u64 val = *p->val;
if (p->is_32bit) {
val &= 0xUL;
@@ -248,7 +245,7 @@ static inline void dbg_to_reg(struct kvm_vcpu *vcpu,
if (p->is_32bit)
val &= 0xUL;
- *vcpu_reg(vcpu, p->Rt) = val;
+ *p->val = val;
}
static inline bool trap_bvr(struct kvm_vcpu *vcpu,
@@ -697,10 +694,10 @@ static bool trap_dbgidr(struct kvm_vcpu *vcpu,
u64 pfr = read_system_reg(SYS_ID_AA64PFR0_EL1);
u32 el3 = !!cpuid_feature_extract_field(pfr,
ID_AA64PFR0_EL3_SHIFT);
- *vcpu_reg(vcpu, p->Rt) = dfr >> ID_AA64DFR0_WRPS_SHIFT) &
0xf) << 28) |
- (((dfr >> ID_AA64DFR0_BRPS_SHIFT) &
0xf) << 24) |
- (((dfr >> ID_AA64DFR0_CTX_CMPS_SHIFT)
& 0xf) << 20) |
- (6 << 16) | (el3 << 14) | (el3 <<
12));
+ *p->val = dfr >> ID_AA64DFR0_WRPS_SHIFT) & 0xf) << 28) |
+ (((dfr >> ID_AA64DFR0_BRPS_SHIFT) & 0xf) << 24) |
+ (((dfr >> ID_AA64DFR0_CTX_CMPS_SHIFT) & 0xf) << 20) |
+ (6 << 16) | (el3 << 14) | (el3 << 12));
return true;
}
}
@@ -710,10 +707,10 @@ static bool trap_debug32(struct kvm_vcpu *vcpu,
const struct sys_reg_desc *r)
{
if (p->is_write) {
- vcpu_cp14(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt);
+ vcpu_cp14(vcpu, r->reg) = *p->val;
vcpu->arch.debug_flags |= KVM_ARM64_DEBUG_DIRTY;
} else {
- *vcpu_reg(vcpu, p->Rt) = vcpu_cp14(vcpu, r->reg);
+ *p->val = vcpu_cp14(vcpu, r->reg);
}
return true;
@@ -740,12 +737,12 @@ static inline bool trap_xvr(struct kvm_vcpu *vcpu,
u64 val = *dbg_reg;
val &= 0xUL;
- val |= *vcpu_reg(vcpu, p->Rt) << 32;
+ val |= *p->val << 32;
*dbg_reg = val;
vcpu->arch.debug_flags |= KVM_ARM6
