All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@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:05:52 +0000	[thread overview]
Message-ID: <573D73E0.90603@suse.de> (raw)
In-Reply-To: <4d984f52-16e6-8429-4b51-85f3c68fa3bc@redhat.com>

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.

Please send a follow-up patch that sets the illegal instruction bit in 
flags on EMULATE_FAIL as well.


Alex


WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@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:05:52 +0200	[thread overview]
Message-ID: <573D73E0.90603@suse.de> (raw)
In-Reply-To: <4d984f52-16e6-8429-4b51-85f3c68fa3bc@redhat.com>

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.

Please send a follow-up patch that sets the illegal instruction bit in 
flags on EMULATE_FAIL as well.


Alex


  reply	other threads:[~2016-05-19  8:05 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 [this message]
2016-05-19  8:05     ` Alexander Graf
2016-05-19  8:26     ` Thomas Huth
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=573D73E0.90603@suse.de \
    --to=agraf@suse.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=paulus@samba.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: 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.