All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Sam Bobroff <sam.bobroff@au1.ibm.com>
Cc: kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, paulus@samba.org
Subject: Re: [PATCH 1/1] KVM: PPC: Book3S: correct width in XER handling
Date: Tue, 26 May 2015 00:23:49 +0000	[thread overview]
Message-ID: <5563BD15.1080301@suse.de> (raw)
In-Reply-To: <20150526001438.GA17851@ocelot.ozlabs.ibm.com>



On 26.05.15 02:14, Sam Bobroff wrote:
> On Mon, May 25, 2015 at 11:08:08PM +0200, Alexander Graf wrote:
>>
>>
>> On 20.05.15 07:26, Sam Bobroff wrote:
>>> In 64 bit kernels, the Fixed Point Exception Register (XER) is a 64
>>> bit field (e.g. in kvm_regs and kvm_vcpu_arch) and in most places it is
>>> accessed as such.
>>>
>>> This patch corrects places where it is accessed as a 32 bit field by a
>>> 64 bit kernel.  In some cases this is via a 32 bit load or store
>>> instruction which, depending on endianness, will cause either the
>>> lower or upper 32 bits to be missed.  In another case it is cast as a
>>> u32, causing the upper 32 bits to be cleared.
>>>
>>> This patch corrects those places by extending the access methods to
>>> 64 bits.
>>>
>>> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
>>> ---
>>>
>>>  arch/powerpc/include/asm/kvm_book3s.h   |    4 ++--
>>>  arch/powerpc/kvm/book3s_hv_rmhandlers.S |    6 +++---
>>>  arch/powerpc/kvm/book3s_segment.S       |    4 ++--
>>>  3 files changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
>>> index b91e74a..05a875a 100644
>>> --- a/arch/powerpc/include/asm/kvm_book3s.h
>>> +++ b/arch/powerpc/include/asm/kvm_book3s.h
>>> @@ -225,12 +225,12 @@ static inline u32 kvmppc_get_cr(struct kvm_vcpu *vcpu)
>>>  	return vcpu->arch.cr;
>>>  }
>>>  
>>> -static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, u32 val)
>>> +static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, ulong val)
>>>  {
>>>  	vcpu->arch.xer = val;
>>>  }
>>>  
>>> -static inline u32 kvmppc_get_xer(struct kvm_vcpu *vcpu)
>>> +static inline ulong kvmppc_get_xer(struct kvm_vcpu *vcpu)
>>>  {
>>>  	return vcpu->arch.xer;
>>>  }
>>> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>>> index 4d70df2..d75be59 100644
>>> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>>> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>>> @@ -870,7 +870,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
>>>  	blt	hdec_soon
>>>  
>>>  	ld	r6, VCPU_CTR(r4)
>>> -	lwz	r7, VCPU_XER(r4)
>>> +	ld	r7, VCPU_XER(r4)
>>>  
>>>  	mtctr	r6
>>>  	mtxer	r7
>>> @@ -1103,7 +1103,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>>>  	mfctr	r3
>>>  	mfxer	r4
>>>  	std	r3, VCPU_CTR(r9)
>>> -	stw	r4, VCPU_XER(r9)
>>> +	std	r4, VCPU_XER(r9)
>>>  
>>>  	/* If this is a page table miss then see if it's theirs or ours */
>>>  	cmpwi	r12, BOOK3S_INTERRUPT_H_DATA_STORAGE
>>> @@ -1675,7 +1675,7 @@ kvmppc_hdsi:
>>>  	bl	kvmppc_msr_interrupt
>>>  fast_interrupt_c_return:
>>>  6:	ld	r7, VCPU_CTR(r9)
>>> -	lwz	r8, VCPU_XER(r9)
>>> +	ld	r8, VCPU_XER(r9)
>>>  	mtctr	r7
>>>  	mtxer	r8
>>>  	mr	r4, r9
>>> diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
>>> index acee37c..ca8f174 100644
>>> --- a/arch/powerpc/kvm/book3s_segment.S
>>> +++ b/arch/powerpc/kvm/book3s_segment.S
>>> @@ -123,7 +123,7 @@ no_dcbz32_on:
>>>  	PPC_LL	r8, SVCPU_CTR(r3)
>>>  	PPC_LL	r9, SVCPU_LR(r3)
>>>  	lwz	r10, SVCPU_CR(r3)
>>> -	lwz	r11, SVCPU_XER(r3)
>>> +	PPC_LL	r11, SVCPU_XER(r3)
>>
>> struct kvmppc_book3s_shadow_vcpu {
>>         bool in_use;
>>         ulong gpr[14];
>>         u32 cr;
>>         u32 xer;
>> [...]
>>
>> so at least this change looks wrong. Please double-check all fields in
>> your patch again.
>>
>>
>> Alex
> 
> Thanks for the review and the catch!
> 
> The xer field in kvm_vcpu_arch is already ulong, so it looks like the one in
> kvmppc_book3s_shadow_vcpu is the only other case. I'll fix that and repost.

I guess given that the one in pt_regs is also ulong going ulong rather
than u32 is the better choice, yes.

While at it, could you please just do a grep -i xer across all kvm (.c
and .h) files and just sanity check that we're staying in sync?


Thanks!

Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Sam Bobroff <sam.bobroff@au1.ibm.com>
Cc: kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, paulus@samba.org
Subject: Re: [PATCH 1/1] KVM: PPC: Book3S: correct width in XER handling
Date: Tue, 26 May 2015 02:23:49 +0200	[thread overview]
Message-ID: <5563BD15.1080301@suse.de> (raw)
In-Reply-To: <20150526001438.GA17851@ocelot.ozlabs.ibm.com>



On 26.05.15 02:14, Sam Bobroff wrote:
> On Mon, May 25, 2015 at 11:08:08PM +0200, Alexander Graf wrote:
>>
>>
>> On 20.05.15 07:26, Sam Bobroff wrote:
>>> In 64 bit kernels, the Fixed Point Exception Register (XER) is a 64
>>> bit field (e.g. in kvm_regs and kvm_vcpu_arch) and in most places it is
>>> accessed as such.
>>>
>>> This patch corrects places where it is accessed as a 32 bit field by a
>>> 64 bit kernel.  In some cases this is via a 32 bit load or store
>>> instruction which, depending on endianness, will cause either the
>>> lower or upper 32 bits to be missed.  In another case it is cast as a
>>> u32, causing the upper 32 bits to be cleared.
>>>
>>> This patch corrects those places by extending the access methods to
>>> 64 bits.
>>>
>>> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
>>> ---
>>>
>>>  arch/powerpc/include/asm/kvm_book3s.h   |    4 ++--
>>>  arch/powerpc/kvm/book3s_hv_rmhandlers.S |    6 +++---
>>>  arch/powerpc/kvm/book3s_segment.S       |    4 ++--
>>>  3 files changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
>>> index b91e74a..05a875a 100644
>>> --- a/arch/powerpc/include/asm/kvm_book3s.h
>>> +++ b/arch/powerpc/include/asm/kvm_book3s.h
>>> @@ -225,12 +225,12 @@ static inline u32 kvmppc_get_cr(struct kvm_vcpu *vcpu)
>>>  	return vcpu->arch.cr;
>>>  }
>>>  
>>> -static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, u32 val)
>>> +static inline void kvmppc_set_xer(struct kvm_vcpu *vcpu, ulong val)
>>>  {
>>>  	vcpu->arch.xer = val;
>>>  }
>>>  
>>> -static inline u32 kvmppc_get_xer(struct kvm_vcpu *vcpu)
>>> +static inline ulong kvmppc_get_xer(struct kvm_vcpu *vcpu)
>>>  {
>>>  	return vcpu->arch.xer;
>>>  }
>>> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>>> index 4d70df2..d75be59 100644
>>> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>>> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
>>> @@ -870,7 +870,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
>>>  	blt	hdec_soon
>>>  
>>>  	ld	r6, VCPU_CTR(r4)
>>> -	lwz	r7, VCPU_XER(r4)
>>> +	ld	r7, VCPU_XER(r4)
>>>  
>>>  	mtctr	r6
>>>  	mtxer	r7
>>> @@ -1103,7 +1103,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>>>  	mfctr	r3
>>>  	mfxer	r4
>>>  	std	r3, VCPU_CTR(r9)
>>> -	stw	r4, VCPU_XER(r9)
>>> +	std	r4, VCPU_XER(r9)
>>>  
>>>  	/* If this is a page table miss then see if it's theirs or ours */
>>>  	cmpwi	r12, BOOK3S_INTERRUPT_H_DATA_STORAGE
>>> @@ -1675,7 +1675,7 @@ kvmppc_hdsi:
>>>  	bl	kvmppc_msr_interrupt
>>>  fast_interrupt_c_return:
>>>  6:	ld	r7, VCPU_CTR(r9)
>>> -	lwz	r8, VCPU_XER(r9)
>>> +	ld	r8, VCPU_XER(r9)
>>>  	mtctr	r7
>>>  	mtxer	r8
>>>  	mr	r4, r9
>>> diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
>>> index acee37c..ca8f174 100644
>>> --- a/arch/powerpc/kvm/book3s_segment.S
>>> +++ b/arch/powerpc/kvm/book3s_segment.S
>>> @@ -123,7 +123,7 @@ no_dcbz32_on:
>>>  	PPC_LL	r8, SVCPU_CTR(r3)
>>>  	PPC_LL	r9, SVCPU_LR(r3)
>>>  	lwz	r10, SVCPU_CR(r3)
>>> -	lwz	r11, SVCPU_XER(r3)
>>> +	PPC_LL	r11, SVCPU_XER(r3)
>>
>> struct kvmppc_book3s_shadow_vcpu {
>>         bool in_use;
>>         ulong gpr[14];
>>         u32 cr;
>>         u32 xer;
>> [...]
>>
>> so at least this change looks wrong. Please double-check all fields in
>> your patch again.
>>
>>
>> Alex
> 
> Thanks for the review and the catch!
> 
> The xer field in kvm_vcpu_arch is already ulong, so it looks like the one in
> kvmppc_book3s_shadow_vcpu is the only other case. I'll fix that and repost.

I guess given that the one in pt_regs is also ulong going ulong rather
than u32 is the better choice, yes.

While at it, could you please just do a grep -i xer across all kvm (.c
and .h) files and just sanity check that we're staying in sync?


Thanks!

Alex

  reply	other threads:[~2015-05-26  0:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20  5:26 [PATCH 1/1] KVM: PPC: Book3S: correct width in XER handling Sam Bobroff
2015-05-20  5:26 ` Sam Bobroff
2015-05-20 22:26 ` Paul Mackerras
2015-05-20 22:26   ` Paul Mackerras
2015-05-20 22:35 ` Scott Wood
2015-05-20 22:35   ` Scott Wood
2015-05-21  2:51   ` Paul Mackerras
2015-05-21  2:51     ` Paul Mackerras
2015-05-25 21:08 ` Alexander Graf
2015-05-25 21:08   ` Alexander Graf
2015-05-26  0:14   ` Sam Bobroff
2015-05-26  0:14     ` Sam Bobroff
2015-05-26  0:23     ` Alexander Graf [this message]
2015-05-26  0:23       ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5563BD15.1080301@suse.de \
    --to=agraf@suse.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=sam.bobroff@au1.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.