From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: [PATCH 7/9] KVM: PPC: Emulate trap SRR1 flags properly Date: Fri, 8 Jan 2010 11:29:47 -0800 Message-ID: References: <1262915889-11526-1-git-send-email-agraf@suse.de> <1262915889-11526-8-git-send-email-agraf@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org, kvm-ppc , Benjamin Herrenschmidt , Liu Yu To: Alexander Graf Return-path: Received: from mail-pw0-f42.google.com ([209.85.160.42]:52189 "EHLO mail-pw0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751379Ab0AHT3s convert rfc822-to-8bit (ORCPT ); Fri, 8 Jan 2010 14:29:48 -0500 In-Reply-To: <1262915889-11526-8-git-send-email-agraf@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jan 7, 2010 at 5:58 PM, Alexander Graf wrote: > Book3S needs some flags in SRR1 to get to know details about an inter= rupt. > > One such example is the trap instruction. It tells the guest kernel t= hat > a program interrupt is due to a trap using a bit in SRR1. > > This patch implements above behavior, making WARN_ON behave like WARN= _ON. =2E.. "for Book S". It already works properly for Book E, thankyouverym= uch. ;) > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c > index 338baf9..e283e44 100644 > --- a/arch/powerpc/kvm/booke.c > +++ b/arch/powerpc/kvm/booke.c > @@ -82,8 +82,9 @@ static void kvmppc_booke_queue_irqprio(struct kvm_v= cpu *vcpu, > =A0 =A0 =A0 =A0set_bit(priority, &vcpu->arch.pending_exceptions); > =A0} > > -void kvmppc_core_queue_program(struct kvm_vcpu *vcpu) > +void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags) > =A0{ > + =A0 =A0 =A0 /* BookE does flags in ESR, so ignore those we get here= */ > =A0 =A0 =A0 =A0kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_PROGRAM= ); > =A0} Actually, I think Book E prematurely sets ESR, since it's done before the program interrupt is actually delivered. Architecturally, I'm not sure if it's a problem, but philosophically I've always wanted it to work the way you've just implemented for Book S. Anyways, since we can't test changes at the moment (Yu, can you?), I'd settle for a comment to the effect that Book E code *should* do this, but doesn't (rather than the comment above that says it's ok). -Hollis From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Fri, 08 Jan 2010 19:29:47 +0000 Subject: Re: [PATCH 7/9] KVM: PPC: Emulate trap SRR1 flags properly Message-Id: List-Id: References: <1262915889-11526-1-git-send-email-agraf@suse.de> <1262915889-11526-8-git-send-email-agraf@suse.de> In-Reply-To: <1262915889-11526-8-git-send-email-agraf@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Alexander Graf Cc: kvm@vger.kernel.org, kvm-ppc , Benjamin Herrenschmidt , Liu Yu On Thu, Jan 7, 2010 at 5:58 PM, Alexander Graf wrote: > Book3S needs some flags in SRR1 to get to know details about an interrupt. > > One such example is the trap instruction. It tells the guest kernel that > a program interrupt is due to a trap using a bit in SRR1. > > This patch implements above behavior, making WARN_ON behave like WARN_ON. ... "for Book S". It already works properly for Book E, thankyouverymuch. ;) > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c > index 338baf9..e283e44 100644 > --- a/arch/powerpc/kvm/booke.c > +++ b/arch/powerpc/kvm/booke.c > @@ -82,8 +82,9 @@ static void kvmppc_booke_queue_irqprio(struct kvm_vcpu = *vcpu, > =A0 =A0 =A0 =A0set_bit(priority, &vcpu->arch.pending_exceptions); > =A0} > > -void kvmppc_core_queue_program(struct kvm_vcpu *vcpu) > +void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags) > =A0{ > + =A0 =A0 =A0 /* BookE does flags in ESR, so ignore those we get here */ > =A0 =A0 =A0 =A0kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_PROGRAM); > =A0} Actually, I think Book E prematurely sets ESR, since it's done before the program interrupt is actually delivered. Architecturally, I'm not sure if it's a problem, but philosophically I've always wanted it to work the way you've just implemented for Book S. Anyways, since we can't test changes at the moment (Yu, can you?), I'd settle for a comment to the effect that Book E code *should* do this, but doesn't (rather than the comment above that says it's ok). -Hollis