* [PATCH 1/2] KVM: PPC: Pass through program interrupts
@ 2010-01-10 2:27 Alexander Graf
2010-01-10 12:22 ` Avi Kivity
0 siblings, 1 reply; 11+ messages in thread
From: Alexander Graf @ 2010-01-10 2:27 UTC (permalink / raw)
To: kvm-u79uwXL29TY76Z2rM5mHXA; +Cc: kvm-ppc
When we get a program interrupt in guest kernel mode, we try to emulate the
instruction.
If that doesn't fail, we report to the user and try again - at the exact same
instruction pointer. So if the guest kernel really does trigger an invalid
instruction, we loop forever.
So let's better go and forward program exceptions to the guest when we don't
know the instruction we're supposed to emulate.
Signed-off-by: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
---
arch/powerpc/kvm/emulate.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index 8b0ba0b..b905623 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -476,6 +476,7 @@ 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);
}
}
--
1.6.0.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] KVM: PPC: Pass through program interrupts
2010-01-10 2:27 [PATCH 1/2] KVM: PPC: Pass through program interrupts Alexander Graf
@ 2010-01-10 12:22 ` Avi Kivity
[not found] ` <4B49C684.8080407-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Avi Kivity @ 2010-01-10 12:22 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm, kvm-ppc
On 01/10/2010 04:27 AM, Alexander Graf wrote:
> When we get a program interrupt in guest kernel mode, we try to emulate the
> instruction.
>
> If that doesn't fail, we report to the user and try again - at the exact same
> instruction pointer. So if the guest kernel really does trigger an invalid
> instruction, we loop forever.
>
> So let's better go and forward program exceptions to the guest when we don't
> know the instruction we're supposed to emulate.
>
>
Applied both, and queued for .33. I was able to guess this from the
description, but please mention it explicitly in the future.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] KVM: PPC: Pass through program interrupts
[not found] ` <4B49C684.8080407-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2010-01-10 12:32 ` Alexander Graf
[not found] ` <3F51B03C-D36B-49F9-9AF3-EF5227DFAE3F-l3A5Bk7waGM@public.gmane.org>
2010-01-10 14:26 ` Avi Kivity
1 sibling, 1 reply; 11+ messages in thread
From: Alexander Graf @ 2010-01-10 12:32 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA, kvm-ppc
On 10.01.2010, at 13:22, Avi Kivity wrote:
> On 01/10/2010 04:27 AM, Alexander Graf wrote:
>> When we get a program interrupt in guest kernel mode, we try to emulate the
>> instruction.
>>
>> If that doesn't fail, we report to the user and try again - at the exact same
>> instruction pointer. So if the guest kernel really does trigger an invalid
>> instruction, we loop forever.
>>
>> So let's better go and forward program exceptions to the guest when we don't
>> know the instruction we're supposed to emulate.
>>
>>
>
> Applied both, and queued for .33. I was able to guess this from the description, but please mention it explicitly in the future.
I'm not sure what to mention. From a stability point of view, all the Book3S patches should go in .33 because they all fix severe bugs.
But then again the question is what our goal for .33 is. If we only want to give out the message "KVM for Book3S is coming! Stay tuned!" then we shouldn't do any updates for .33. If we want to have something working to the best of our knowledge, all patches should go into .33.
Alex
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] KVM: PPC: Pass through program interrupts
[not found] ` <3F51B03C-D36B-49F9-9AF3-EF5227DFAE3F-l3A5Bk7waGM@public.gmane.org>
@ 2010-01-10 12:37 ` Avi Kivity
[not found] ` <4B49CA20.6000303-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Avi Kivity @ 2010-01-10 12:37 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA, kvm-ppc
On 01/10/2010 02:32 PM, Alexander Graf wrote:
>
>
>> Applied both, and queued for .33. I was able to guess this from the description, but please mention it explicitly in the future.
>>
> I'm not sure what to mention. From a stability point of view, all the Book3S patches should go in .33 because they all fix severe bugs.
>
> But then again the question is what our goal for .33 is. If we only want to give out the message "KVM for Book3S is coming! Stay tuned!" then we shouldn't do any updates for .33. If we want to have something working to the best of our knowledge, all patches should go into .33.
>
Given the other 9-patch series, I'll regard .33 as a sneak preview (look
but don't touch) and .34 will be the first really serious kvm ppc64 release.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] KVM: PPC: Pass through program interrupts
[not found] ` <4B49CA20.6000303-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2010-01-10 12:46 ` Alexander Graf
0 siblings, 0 replies; 11+ messages in thread
From: Alexander Graf @ 2010-01-10 12:46 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA, kvm-ppc
On 10.01.2010, at 13:37, Avi Kivity wrote:
> On 01/10/2010 02:32 PM, Alexander Graf wrote:
>>
>>
>>> Applied both, and queued for .33. I was able to guess this from the description, but please mention it explicitly in the future.
>>>
>> I'm not sure what to mention. From a stability point of view, all the Book3S patches should go in .33 because they all fix severe bugs.
>>
>> But then again the question is what our goal for .33 is. If we only want to give out the message "KVM for Book3S is coming! Stay tuned!" then we shouldn't do any updates for .33. If we want to have something working to the best of our knowledge, all patches should go into .33.
>>
>
> Given the other 9-patch series, I'll regard .33 as a sneak preview (look but don't touch) and .34 will be the first really serious kvm ppc64 release.
That's what I figured too, so I didn't queue anything explicitly for .33 :-).
Alex
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] KVM: PPC: Pass through program interrupts
[not found] ` <4B49C684.8080407-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-10 12:32 ` Alexander Graf
@ 2010-01-10 14:26 ` Avi Kivity
[not found] ` <4B49E391.60108-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
1 sibling, 1 reply; 11+ messages in thread
From: Avi Kivity @ 2010-01-10 14:26 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA, kvm-ppc
On 01/10/2010 02:22 PM, Avi Kivity wrote:
> On 01/10/2010 04:27 AM, Alexander Graf wrote:
>> When we get a program interrupt in guest kernel mode, we try to
>> emulate the
>> instruction.
>>
>> If that doesn't fail, we report to the user and try again - at the
>> exact same
>> instruction pointer. So if the guest kernel really does trigger an
>> invalid
>> instruction, we loop forever.
>>
>> So let's better go and forward program exceptions to the guest when
>> we don't
>> know the instruction we're supposed to emulate.
>>
>
> Applied both, and queued for .33. I was able to guess this from the
> description, but please mention it explicitly in the future.
>
I get this building ppc32:
scripts/kconfig/conf -s arch/powerpc/Kconfig
CHK include/linux/version.h
CHK include/generated/utsrelease.h
CALL scripts/checksyscalls.sh
<stdin>:1523:2: warning: #warning syscall recvmmsg not implemented
CC arch/powerpc/kvm/emulate.o
arch/powerpc/kvm/emulate.c: In function 'kvmppc_emulate_instruction':
arch/powerpc/kvm/emulate.c:467: error: too many arguments to function
'kvmppc_core_queue_program'
make[1]: *** [arch/powerpc/kvm/emulate.o] Error 1
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] KVM: PPC: Pass through program interrupts
[not found] ` <4B49E391.60108-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2010-01-10 15:06 ` Alexander Graf
[not found] ` <A5862364-1443-4A32-85B8-13B11B2E55DA-l3A5Bk7waGM@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Alexander Graf @ 2010-01-10 15:06 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA, kvm-ppc
On 10.01.2010, at 15:26, Avi Kivity wrote:
> On 01/10/2010 02:22 PM, Avi Kivity wrote:
>> On 01/10/2010 04:27 AM, Alexander Graf wrote:
>>> When we get a program interrupt in guest kernel mode, we try to emulate the
>>> instruction.
>>>
>>> If that doesn't fail, we report to the user and try again - at the exact same
>>> instruction pointer. So if the guest kernel really does trigger an invalid
>>> instruction, we loop forever.
>>>
>>> So let's better go and forward program exceptions to the guest when we don't
>>> know the instruction we're supposed to emulate.
>>>
>>
>> Applied both, and queued for .33. I was able to guess this from the description, but please mention it explicitly in the future.
>>
>
> I get this building ppc32:
PPC32? That shouldn't even allow enabling KVM O_o.
Alex--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] KVM: PPC: Pass through program interrupts
[not found] ` <A5862364-1443-4A32-85B8-13B11B2E55DA-l3A5Bk7waGM@public.gmane.org>
@ 2010-01-10 15:09 ` Avi Kivity
[not found] ` <4B49EDBA.9040306-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Avi Kivity @ 2010-01-10 15:09 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA, kvm-ppc
On 01/10/2010 05:06 PM, Alexander Graf wrote:
>>
>> I get this building ppc32:
>>
> PPC32? That shouldn't even allow enabling KVM O_o.
>
>
You know, the embedded stuff.
Enabled config options:
VIRTUALIZATION=y
KVM=y
KVM_440=y
KVM_E500=n
KVM_EXIT_TIMING=n
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] KVM: PPC: Pass through program interrupts
[not found] ` <4B49EDBA.9040306-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2010-01-10 15:28 ` Alexander Graf
[not found] ` <A21E3A8F-81D1-468A-BE37-9CB5718E1FB8-l3A5Bk7waGM@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Alexander Graf @ 2010-01-10 15:28 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA, kvm-ppc
On 10.01.2010, at 16:09, Avi Kivity wrote:
> On 01/10/2010 05:06 PM, Alexander Graf wrote:
>>>
>>> I get this building ppc32:
>>>
>> PPC32? That shouldn't even allow enabling KVM O_o.
>>
>>
>
> You know, the embedded stuff.
Hm, that patch is based on the big patchset I sent earlier. Are you sure you have applied them in the correct order?
Alex--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] KVM: PPC: Pass through program interrupts
[not found] ` <A21E3A8F-81D1-468A-BE37-9CB5718E1FB8-l3A5Bk7waGM@public.gmane.org>
@ 2010-01-10 15:37 ` Avi Kivity
2010-01-10 15:54 ` Avi Kivity
0 siblings, 1 reply; 11+ messages in thread
From: Avi Kivity @ 2010-01-10 15:37 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm-u79uwXL29TY76Z2rM5mHXA, kvm-ppc
On 01/10/2010 05:28 PM, Alexander Graf wrote:
>
> Hm, that patch is based on the big patchset I sent earlier. Are you sure you have applied them in the correct order?
>
Probably not. Will reorder and retry.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] KVM: PPC: Pass through program interrupts
2010-01-10 15:37 ` Avi Kivity
@ 2010-01-10 15:54 ` Avi Kivity
0 siblings, 0 replies; 11+ messages in thread
From: Avi Kivity @ 2010-01-10 15:54 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm, kvm-ppc
On 01/10/2010 05:37 PM, Avi Kivity wrote:
> On 01/10/2010 05:28 PM, Alexander Graf wrote:
>>
>> Hm, that patch is based on the big patchset I sent earlier. Are you
>> sure you have applied them in the correct order?
>
> Probably not. Will reorder and retry.
>
No, still fails. Please take a look at kvm-updates/2.6.34 commit
7f31fad9aa, subject to git.kernel.org rsync delay (was doing
bisectability testing).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-01-10 15:54 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-10 2:27 [PATCH 1/2] KVM: PPC: Pass through program interrupts Alexander Graf
2010-01-10 12:22 ` Avi Kivity
[not found] ` <4B49C684.8080407-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-10 12:32 ` Alexander Graf
[not found] ` <3F51B03C-D36B-49F9-9AF3-EF5227DFAE3F-l3A5Bk7waGM@public.gmane.org>
2010-01-10 12:37 ` Avi Kivity
[not found] ` <4B49CA20.6000303-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-10 12:46 ` Alexander Graf
2010-01-10 14:26 ` Avi Kivity
[not found] ` <4B49E391.60108-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-10 15:06 ` Alexander Graf
[not found] ` <A5862364-1443-4A32-85B8-13B11B2E55DA-l3A5Bk7waGM@public.gmane.org>
2010-01-10 15:09 ` Avi Kivity
[not found] ` <4B49EDBA.9040306-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2010-01-10 15:28 ` Alexander Graf
[not found] ` <A21E3A8F-81D1-468A-BE37-9CB5718E1FB8-l3A5Bk7waGM@public.gmane.org>
2010-01-10 15:37 ` Avi Kivity
2010-01-10 15:54 ` Avi Kivity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).