From: Thomas Huth <thuth@redhat.com>
To: Alexander Graf <agraf@suse.de>,
Laurent Vivier <lvivier@redhat.com>,
Paul Mackerras <paulus@samba.org>,
kvm-ppc@vger.kernel.org
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: Fix illegal opcode emulation in kvm-pr
Date: Thu, 19 May 2016 08:26:55 +0000 [thread overview]
Message-ID: <573D78CF.6030106@redhat.com> (raw)
In-Reply-To: <573D73E0.90603@suse.de>
On 19.05.2016 10:05, Alexander Graf wrote:
> On 05/19/2016 09:58 AM, Laurent Vivier wrote:
>>
>> On 18/05/2016 21:01, Thomas Huth wrote:
>>> If kvmppc_handle_exit_pr() calls kvmppc_emulate_instruction() to emulate
>>> one instruction (in the BOOK3S_INTERRUPT_H_EMUL_ASSIST case), it calls
>>> kvmppc_core_queue_program() afterwards if kvmppc_emulate_instruction()
>>> returned EMULATE_FAIL, so the guest gets an program interrupt for the
>>> illegal opcode.
>>> However, the kvmppc_emulate_instruction() also tried to inject a
>>> program exception for this already, so the program interrupt gets
>>> injected twice and the return address in srr0 gets destroyed.
>>> All other callers of kvmppc_emulate_instruction() are also injecting
>>> a program interrupt, and since the callers have the right knowledge
>>> about the srr1 flags that should be used, it is the function
>>> kvmppc_emulate_instruction() that should _not_ inject program
>>> interrupts, so remove the kvmppc_core_queue_program() here.
>>>
>>> This fixes the issue discovered by Laurent Vivier with kvm-unit-tests
>>> where the logs are filled with these messages when the test tries
>>> to execute an illegal instruction:
>>>
>>> Couldn't emulate instruction 0x00000000 (op 0 xop 0)
>>> kvmppc_handle_exit_pr: emulation at 700 failed (00000000)
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>> arch/powerpc/kvm/emulate.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
>>> index 5cc2e7a..b379146 100644
>>> --- a/arch/powerpc/kvm/emulate.c
>>> +++ b/arch/powerpc/kvm/emulate.c
>>> @@ -302,7 +302,6 @@ int kvmppc_emulate_instruction(struct kvm_run
>>> *run, struct kvm_vcpu *vcpu)
>>> advance = 0;
>>> printk(KERN_ERR "Couldn't emulate instruction 0x%08x "
>>> "(op %d xop %d)\n", inst, get_op(inst),
>>> get_xop(inst));
>>> - kvmppc_core_queue_program(vcpu, 0);
>>> }
>>> }
>>>
>> I've tested this patch with kvm-unit-tests: it solves the multiple
>> illegal instruction exceptions, but the test fails because SRR1 is not
>> updated correctly. It should contains the bit for "Illegal Instruction"
>> whereas it is 0.
>> [But I think it's what you explain in your last email]
>
> So if the illegal instruction flag is missing, that's probably because
> the host CPU didn't pass that in via SRR1. That's probably a subtle
> difference between EMUL_ASSIST and PROGRAM.
Thanks for that hint! You're right, flags is only 0 if exit_nr is
BOOK3S_INTERRUPT_H_EMUL_ASSIST. It seems to contain proper values for
BOOK3S_INTERRUPT_PROGRAM, e.g. for privileged-instruction program
interrupts.
Looking at the PowerISA, this also supports this theory: For emulation
assist interrupts, the bits in SRR1 are 0.
So the right fix really seems to be to set flags = SRR1_PROGILL in case
the function has been called with EMUL_ASSIST.
> Please send a follow-up patch that sets the illegal instruction bit in
> flags on EMULATE_FAIL as well.
I think I'll best send a separate patch, since it is a separate issue.
Thomas
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Huth <thuth@redhat.com>
To: Alexander Graf <agraf@suse.de>,
Laurent Vivier <lvivier@redhat.com>,
Paul Mackerras <paulus@samba.org>,
kvm-ppc@vger.kernel.org
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: Fix illegal opcode emulation in kvm-pr
Date: Thu, 19 May 2016 10:26:55 +0200 [thread overview]
Message-ID: <573D78CF.6030106@redhat.com> (raw)
In-Reply-To: <573D73E0.90603@suse.de>
On 19.05.2016 10:05, Alexander Graf wrote:
> On 05/19/2016 09:58 AM, Laurent Vivier wrote:
>>
>> On 18/05/2016 21:01, Thomas Huth wrote:
>>> If kvmppc_handle_exit_pr() calls kvmppc_emulate_instruction() to emulate
>>> one instruction (in the BOOK3S_INTERRUPT_H_EMUL_ASSIST case), it calls
>>> kvmppc_core_queue_program() afterwards if kvmppc_emulate_instruction()
>>> returned EMULATE_FAIL, so the guest gets an program interrupt for the
>>> illegal opcode.
>>> However, the kvmppc_emulate_instruction() also tried to inject a
>>> program exception for this already, so the program interrupt gets
>>> injected twice and the return address in srr0 gets destroyed.
>>> All other callers of kvmppc_emulate_instruction() are also injecting
>>> a program interrupt, and since the callers have the right knowledge
>>> about the srr1 flags that should be used, it is the function
>>> kvmppc_emulate_instruction() that should _not_ inject program
>>> interrupts, so remove the kvmppc_core_queue_program() here.
>>>
>>> This fixes the issue discovered by Laurent Vivier with kvm-unit-tests
>>> where the logs are filled with these messages when the test tries
>>> to execute an illegal instruction:
>>>
>>> Couldn't emulate instruction 0x00000000 (op 0 xop 0)
>>> kvmppc_handle_exit_pr: emulation at 700 failed (00000000)
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>> arch/powerpc/kvm/emulate.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
>>> index 5cc2e7a..b379146 100644
>>> --- a/arch/powerpc/kvm/emulate.c
>>> +++ b/arch/powerpc/kvm/emulate.c
>>> @@ -302,7 +302,6 @@ int kvmppc_emulate_instruction(struct kvm_run
>>> *run, struct kvm_vcpu *vcpu)
>>> advance = 0;
>>> printk(KERN_ERR "Couldn't emulate instruction 0x%08x "
>>> "(op %d xop %d)\n", inst, get_op(inst),
>>> get_xop(inst));
>>> - kvmppc_core_queue_program(vcpu, 0);
>>> }
>>> }
>>>
>> I've tested this patch with kvm-unit-tests: it solves the multiple
>> illegal instruction exceptions, but the test fails because SRR1 is not
>> updated correctly. It should contains the bit for "Illegal Instruction"
>> whereas it is 0.
>> [But I think it's what you explain in your last email]
>
> So if the illegal instruction flag is missing, that's probably because
> the host CPU didn't pass that in via SRR1. That's probably a subtle
> difference between EMUL_ASSIST and PROGRAM.
Thanks for that hint! You're right, flags is only 0 if exit_nr is
BOOK3S_INTERRUPT_H_EMUL_ASSIST. It seems to contain proper values for
BOOK3S_INTERRUPT_PROGRAM, e.g. for privileged-instruction program
interrupts.
Looking at the PowerISA, this also supports this theory: For emulation
assist interrupts, the bits in SRR1 are 0.
So the right fix really seems to be to set flags = SRR1_PROGILL in case
the function has been called with EMUL_ASSIST.
> Please send a follow-up patch that sets the illegal instruction bit in
> flags on EMULATE_FAIL as well.
I think I'll best send a separate patch, since it is a separate issue.
Thomas
next prev parent reply other threads:[~2016-05-19 8:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-18 19:01 [PATCH] KVM: PPC: Fix illegal opcode emulation in kvm-pr Thomas Huth
2016-05-18 19:01 ` Thomas Huth
2016-05-19 7:58 ` Laurent Vivier
2016-05-19 7:58 ` Laurent Vivier
2016-05-19 8:05 ` Alexander Graf
2016-05-19 8:05 ` Alexander Graf
2016-05-19 8:26 ` Thomas Huth [this message]
2016-05-19 8:26 ` Thomas Huth
2016-05-19 8:07 ` Thomas Huth
2016-05-19 8:07 ` Thomas Huth
2016-05-19 8:31 ` Laurent Vivier
2016-05-19 8:31 ` Laurent Vivier
2016-05-19 8:04 ` Alexander Graf
2016-05-19 8:04 ` Alexander Graf
2016-05-31 10:29 ` Thomas Huth
2016-05-31 10:29 ` Thomas Huth
2016-06-14 17:49 ` Thomas Huth
2016-06-14 17:49 ` Thomas Huth
2016-06-24 9:22 ` Paul Mackerras
2016-06-24 9:22 ` Paul Mackerras
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=573D78CF.6030106@redhat.com \
--to=thuth@redhat.com \
--cc=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=lvivier@redhat.com \
--cc=paulus@samba.org \
/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.