From: Christian Borntraeger <borntraeger@de.ibm.com> Cc: cohuck@redhat.com, david@redhat.com, frankja@linux.ibm.com, kvm@vger.kernel.org, linux-s390@vger.kernel.org, stable@kernel.org, thuth@redhat.com Subject: Re: [PATCH v2] KVM: s390: do not clobber user space registers during guest reset/store status Date: Thu, 30 Jan 2020 13:01:59 +0100 [thread overview] Message-ID: <8120c228-2935-07d4-38b9-3b9c5cb8b92c@de.ibm.com> (raw) In-Reply-To: <1580384552-7964-1-git-send-email-borntraeger@de.ibm.com> On 30.01.20 12:42, Christian Borntraeger wrote: > The two ioctls for initial CPU reset and store status currently clobber > the userspace fpc and potentially access registers. This was an > oversight during a fixup for the lazy fpu reloading rework. The reset > calls are only done from userspace ioctls. No CPU context is loaded, so > we can (and must) act directly on the sync regs, not on the thread > context. Otherwise the fpu restore call will restore the zeroes fpc to > userspace. New patch description: KVM: s390: do not clobber registers during guest reset/store status The initial CPU reset clobbers the userspace fpc and the store status ioctl clobbers the guest acrs + fpr. As these calls are only done via ioctl (and not via vcpu_run), no CPU context is loaded, so we can (and must) act directly on the sync regs, not on the thread context. Cc: stable@kernel.org Fixes: e1788bb995be ("KVM: s390: handle floating point registers in the run ioctl not in vcpu_put/load") Fixes: 31d8b8d41a7e ("KVM: s390: handle access registers in the run ioctl not in vcpu_put/load") Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > > Cc: stable@kernel.org > Fixes: e1788bb995be ("KVM: s390: handle floating point registers in the run ioctl not in vcpu_put/load") > Fixes: 31d8b8d41a7e ("KVM: s390: handle access registers in the run ioctl not in vcpu_put/load") > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > --- > arch/s390/kvm/kvm-s390.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c > index c059b86..936415b 100644 > --- a/arch/s390/kvm/kvm-s390.c > +++ b/arch/s390/kvm/kvm-s390.c > @@ -2824,8 +2824,7 @@ static void kvm_s390_vcpu_initial_reset(struct kvm_vcpu *vcpu) > vcpu->arch.sie_block->gcr[14] = CR14_UNUSED_32 | > CR14_UNUSED_33 | > CR14_EXTERNAL_DAMAGE_SUBMASK; > - /* make sure the new fpc will be lazily loaded */ > - save_fpu_regs(); > + vcpu->run->s.regs.fpc = 0; > current->thread.fpu.fpc = 0; > vcpu->arch.sie_block->gbea = 1; > vcpu->arch.sie_block->pp = 0; > @@ -4343,7 +4342,7 @@ long kvm_arch_vcpu_ioctl(struct file *filp, > switch (ioctl) { > case KVM_S390_STORE_STATUS: > idx = srcu_read_lock(&vcpu->kvm->srcu); > - r = kvm_s390_vcpu_store_status(vcpu, arg); > + r = kvm_s390_vcpu_store_status_unloaded(vcpu, arg); > srcu_read_unlock(&vcpu->kvm->srcu, idx); > break; > case KVM_S390_SET_INITIAL_PSW: { >
WARNING: multiple messages have this Message-ID (diff)
From: Christian Borntraeger <borntraeger@de.ibm.com> To: unlisted-recipients:; (no To-header on input) Cc: cohuck@redhat.com, david@redhat.com, frankja@linux.ibm.com, kvm@vger.kernel.org, linux-s390@vger.kernel.org, stable@kernel.org, thuth@redhat.com Subject: Re: [PATCH v2] KVM: s390: do not clobber user space registers during guest reset/store status Date: Thu, 30 Jan 2020 13:01:59 +0100 [thread overview] Message-ID: <8120c228-2935-07d4-38b9-3b9c5cb8b92c@de.ibm.com> (raw) In-Reply-To: <1580384552-7964-1-git-send-email-borntraeger@de.ibm.com> On 30.01.20 12:42, Christian Borntraeger wrote: > The two ioctls for initial CPU reset and store status currently clobber > the userspace fpc and potentially access registers. This was an > oversight during a fixup for the lazy fpu reloading rework. The reset > calls are only done from userspace ioctls. No CPU context is loaded, so > we can (and must) act directly on the sync regs, not on the thread > context. Otherwise the fpu restore call will restore the zeroes fpc to > userspace. New patch description: KVM: s390: do not clobber registers during guest reset/store status The initial CPU reset clobbers the userspace fpc and the store status ioctl clobbers the guest acrs + fpr. As these calls are only done via ioctl (and not via vcpu_run), no CPU context is loaded, so we can (and must) act directly on the sync regs, not on the thread context. Cc: stable@kernel.org Fixes: e1788bb995be ("KVM: s390: handle floating point registers in the run ioctl not in vcpu_put/load") Fixes: 31d8b8d41a7e ("KVM: s390: handle access registers in the run ioctl not in vcpu_put/load") Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > > Cc: stable@kernel.org > Fixes: e1788bb995be ("KVM: s390: handle floating point registers in the run ioctl not in vcpu_put/load") > Fixes: 31d8b8d41a7e ("KVM: s390: handle access registers in the run ioctl not in vcpu_put/load") > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > --- > arch/s390/kvm/kvm-s390.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c > index c059b86..936415b 100644 > --- a/arch/s390/kvm/kvm-s390.c > +++ b/arch/s390/kvm/kvm-s390.c > @@ -2824,8 +2824,7 @@ static void kvm_s390_vcpu_initial_reset(struct kvm_vcpu *vcpu) > vcpu->arch.sie_block->gcr[14] = CR14_UNUSED_32 | > CR14_UNUSED_33 | > CR14_EXTERNAL_DAMAGE_SUBMASK; > - /* make sure the new fpc will be lazily loaded */ > - save_fpu_regs(); > + vcpu->run->s.regs.fpc = 0; > current->thread.fpu.fpc = 0; > vcpu->arch.sie_block->gbea = 1; > vcpu->arch.sie_block->pp = 0; > @@ -4343,7 +4342,7 @@ long kvm_arch_vcpu_ioctl(struct file *filp, > switch (ioctl) { > case KVM_S390_STORE_STATUS: > idx = srcu_read_lock(&vcpu->kvm->srcu); > - r = kvm_s390_vcpu_store_status(vcpu, arg); > + r = kvm_s390_vcpu_store_status_unloaded(vcpu, arg); > srcu_read_unlock(&vcpu->kvm->srcu, idx); > break; > case KVM_S390_SET_INITIAL_PSW: { >
next prev parent reply other threads:[~2020-01-30 12:02 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-29 20:03 [PATCH v8 0/4] KVM: s390: Add new reset vcpu API Janosch Frank 2020-01-29 20:03 ` [PATCH v8 1/4] " Janosch Frank 2020-01-30 8:55 ` [PATCH/FIXUP FOR STABLE BEFORE THIS SERIES] KVM: s390: do not clobber user space fpc during guest reset Christian Borntraeger 2020-01-30 9:49 ` David Hildenbrand 2020-01-30 10:39 ` Cornelia Huck 2020-01-30 10:56 ` Thomas Huth 2020-01-30 11:07 ` Christian Borntraeger 2020-01-30 11:01 ` Christian Borntraeger 2020-01-30 11:14 ` Christian Borntraeger 2020-01-30 11:20 ` David Hildenbrand 2020-01-30 11:27 ` Christian Borntraeger 2020-01-30 11:42 ` [PATCH v2] KVM: s390: do not clobber user space registers during guest reset/store status Christian Borntraeger 2020-01-30 11:44 ` Christian Borntraeger 2020-01-30 11:44 ` Christian Borntraeger 2020-01-30 12:01 ` Christian Borntraeger [this message] 2020-01-30 12:01 ` Christian Borntraeger 2020-01-30 12:38 ` David Hildenbrand 2020-01-30 9:00 ` [PATCH v8 1/4] KVM: s390: Add new reset vcpu API Thomas Huth 2020-01-30 9:58 ` Christian Borntraeger 2020-01-29 20:03 ` [PATCH v8 2/4] selftests: KVM: Add fpu and one reg set/get library functions Janosch Frank 2020-01-30 10:36 ` Thomas Huth 2020-01-30 13:55 ` Andrew Jones 2020-01-30 14:10 ` Janosch Frank 2020-01-30 14:30 ` Andrew Jones 2020-01-30 14:58 ` Janosch Frank 2020-01-30 15:04 ` Andrew Jones 2020-01-29 20:03 ` [PATCH v8 3/4] selftests: KVM: s390x: Add reset tests Janosch Frank 2020-01-30 10:51 ` Thomas Huth 2020-01-30 11:32 ` Janosch Frank 2020-01-30 11:36 ` Thomas Huth 2020-01-29 20:03 ` [PATCH v8 4/4] selftests: KVM: testing the local IRQs resets Janosch Frank 2020-01-30 10:55 ` Cornelia Huck 2020-01-30 11:18 ` Janosch Frank 2020-01-30 11:28 ` Cornelia Huck 2020-01-30 11:34 ` Janosch Frank 2020-01-30 11:10 ` Thomas Huth 2020-01-30 11:33 ` Janosch Frank 2020-01-30 9:10 ` [PATCH] KVM: s390: Cleanup initial cpu reset Janosch Frank
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=8120c228-2935-07d4-38b9-3b9c5cb8b92c@de.ibm.com \ --to=borntraeger@de.ibm.com \ --cc=cohuck@redhat.com \ --cc=david@redhat.com \ --cc=frankja@linux.ibm.com \ --cc=kvm@vger.kernel.org \ --cc=linux-s390@vger.kernel.org \ --cc=stable@kernel.org \ --cc=thuth@redhat.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: linkBe 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.