Re: [PATCH 0/8] KVM: BOOKE/BOOKEHV : Added debug stub support
On 01.02.2013, at 10:09, Bhushan Bharat-R65777 wrote: -Original Message- From: Alexander Graf [mailto:ag...@suse.de] Sent: Friday, February 01, 2013 1:34 PM To: Bhushan Bharat-R65777 Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org Subject: Re: [PATCH 0/8] KVM: BOOKE/BOOKEHV : Added debug stub support On 01.02.2013, at 04:49, Bhushan Bharat-R65777 wrote: -Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf Sent: Friday, January 25, 2013 6:08 PM To: Bhushan Bharat-R65777 Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Bhushan Bharat-R65777 Subject: Re: [PATCH 0/8] KVM: BOOKE/BOOKEHV : Added debug stub support On 16.01.2013, at 09:20, Bharat Bhushan wrote: This patchset adds the QEMU debug stub support for powerpc (booke/bookehv). [1/8] KVM: PPC: booke: use vcpu reference from thread_struct - This is a cleanup patch to use vcpu reference from thread struct [2/8] KVM: PPC: booke: Allow multiple exception types [3/8] KVM: PPC: booke: Added debug handler - These two patches install the KVM debug handler. [4/8] Added ONE_REG interface for debug instruction - Add the ioctl interface to get the debug instruction for setting software breakpoint from QEMU debug stub. [5/8] KVM: PPC: debug stub interface parameter defined [6/8] booke: Added DBCR4 SPR number [7/8] KVM: booke/bookehv: Add debug stub support - Add the debug stub interface on booke/bookehv [8/8] KVM:PPC:booke: Allow debug interrupt injection to guest -- with this qemu can inject debug interrupt to guest Thanks, applied 1/8, 2/8, 6/8. Alex I cannot see these 3 patches on kvm-ppc-next branch. Are those applied on some other branch ? Yes, my staging tree is now kvm-ppc-queue, as I'm not allowed to rebase kvm-ppc- next... On which branch we should send our patches on kvm-ppc-queue or kmv-ppc-next? Kvm-ppc-queue is what used to be kvm-ppc-next. Kvm-ppc-next is the staging tree for linux-next. Please send patches against kvm-ppc-queue. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: One reg interface for Timer register
On 04.02.2013, at 07:12, Bhushan Bharat-R65777 wrote: Hi Alex/Scott, Below is my understanding about the ONE_REG interface requirement for timer registers. Define the below 2 ONE_REG interface for TSR access: KVM_REG_SET_TSR, // Set the specified bits in TSR s/SET/OR/ KVM_REG_CLEAR_TSR, // Clear the specified bits in TSR QEMU will use the above ioctl call to selectively set/clear bits of TSR. Exactly :). We do not need the similar interface for TCR as there is no race issue with TCR. So for TCR QEMU will keep on using the SREGS interface. Good point, yes :). Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/8] KVM: PPC: booke: Added debug handler
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Friday, January 25, 2013 5:13 PM
To: Bhushan Bharat-R65777
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Bhushan
Bharat-R65777
Subject: Re: [PATCH 3/8] KVM: PPC: booke: Added debug handler
On 16.01.2013, at 09:24, Bharat Bhushan wrote:
From: Bharat Bhushan bharat.bhus...@freescale.com
Installed debug handler will be used for guest debug support
and debug facility emulation features (patches for these
features will follow this patch).
Signed-off-by: Liu Yu yu@freescale.com
[bharat.bhus...@freescale.com: Substantial changes]
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
arch/powerpc/include/asm/kvm_host.h |1 +
arch/powerpc/kernel/asm-offsets.c |1 +
arch/powerpc/kvm/booke_interrupts.S | 49
++-
--
--
3 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 8a72d59..f4ba881 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -503,6 +503,7 @@ struct kvm_vcpu_arch {
u32 tlbcfg[4];
u32 mmucfg;
u32 epr;
+ u32 crit_save;
struct kvmppc_booke_debug_reg dbg_reg; #endif
gpa_t paddr_accessed;
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 46f6afd..02048f3 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -562,6 +562,7 @@ int main(void)
DEFINE(VCPU_LAST_INST, offsetof(struct kvm_vcpu,
arch.last_inst));
DEFINE(VCPU_FAULT_DEAR, offsetof(struct kvm_vcpu,
arch.fault_dear));
DEFINE(VCPU_FAULT_ESR, offsetof(struct kvm_vcpu,
arch.fault_esr));
+ DEFINE(VCPU_CRIT_SAVE, offsetof(struct kvm_vcpu,
+arch.crit_save));
#endif /* CONFIG_PPC_BOOK3S */ #endif /* CONFIG_KVM */
diff --git a/arch/powerpc/kvm/booke_interrupts.S
b/arch/powerpc/kvm/booke_interrupts.S
index eae8483..dd9c5d4 100644
--- a/arch/powerpc/kvm/booke_interrupts.S
+++ b/arch/powerpc/kvm/booke_interrupts.S
@@ -52,12 +52,7 @@
(1BOOKE_INTERRUPT_PROGRAM) | \
(1BOOKE_INTERRUPT_DTLB_MISS))
-.macro KVM_HANDLER ivor_nr scratch srr0
-_GLOBAL(kvmppc_handler_\ivor_nr)
- /* Get pointer to vcpu and record exit number. */
- mtspr \scratch , r4
- mfspr r4, SPRN_SPRG_THREAD
- lwz r4, THREAD_KVM_VCPU(r4)
+.macro __KVM_HANDLER ivor_nr scratch srr0
stw r3, VCPU_GPR(R3)(r4)
stw r5, VCPU_GPR(R5)(r4)
stw r6, VCPU_GPR(R6)(r4)
@@ -74,6 +69,46 @@ _GLOBAL(kvmppc_handler_\ivor_nr)
bctr
.endm
+.macro KVM_HANDLER ivor_nr scratch srr0
+_GLOBAL(kvmppc_handler_\ivor_nr)
+ /* Get pointer to vcpu and record exit number. */
+ mtspr \scratch , r4
+ mfspr r4, SPRN_SPRG_THREAD
+ lwz r4, THREAD_KVM_VCPU(r4)
+ __KVM_HANDLER \ivor_nr \scratch \srr0 .endm
+
+.macro KVM_DBG_HANDLER ivor_nr scratch srr0
+_GLOBAL(kvmppc_handler_\ivor_nr)
+ mtspr \scratch, r4
+ mfspr r4, SPRN_SPRG_THREAD
+ lwz r4, THREAD_KVM_VCPU(r4)
+ stw r3, VCPU_CRIT_SAVE(r4)
+ mfcrr3
+ mfspr r4, SPRN_CSRR1
+ andi. r4, r4, MSR_PR
+ bne 1f
+ /* debug interrupt happened in enter/exit path */
+ mfspr r4, SPRN_CSRR1
+ rlwinm r4, r4, 0, ~MSR_DE
+ mtspr SPRN_CSRR1, r4
+ lis r4, 0x
+ ori r4, r4, 0x
+ mtspr SPRN_DBSR, r4
+ mfspr r4, SPRN_SPRG_THREAD
+ lwz r4, THREAD_KVM_VCPU(r4)
+ mtcrr3
+ lwz r3, VCPU_CRIT_SAVE(r4)
+ mfspr r4, \scratch
+ rfci
What is this part doing? Try to ignore the debug exit?
As BOOKE doesn't have hardware support for virtualization,
hardware never know
current pc is in guest or in host.
So when enable hardware single step for guest, it cannot be
disabled at the
time guest exit. Thus, we'll see that an single step interrupt
happens at the beginning of guest exit path.
With the above code we recognize this kind of single step
interrupt disable
single step and rfci.
Why would we have MSR_DE
enabled in the first place when we can't handle it?
When QEMU is using hardware debug resource then we always set
MSR_DE during
guest is running.
Right, but why is MSR_DE enabled during the exit path? If MSR_DE
wasn't set, you wouldn't get a single step exit.
We always set MSR_DE in hw MSR when qemu using the debug resource.
In the _guest_ MSR, yes. But once we exit the guest, it shouldn't
be set anymore, because we're in an interrupt handler, no? Or is
MSR_DE kept alive on interrupts?
During the exit code path, you could then swap DBSR back to what
the host expects (which means no single step). Only after that
enable MSR_DE again.
We do not support deferred debug
Re: [PATCH 8/8] KVM:PPC:booke: Allow debug interrupt injection to guest
On 07.02.2013, at 16:00, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, February 02, 2013 4:09 AM
To: Alexander Graf
Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; k...@vger.kernel.org
Subject: Re: [PATCH 8/8] KVM:PPC:booke: Allow debug interrupt injection to
guest
On 01/31/2013 06:11:32 PM, Alexander Graf wrote:
On 31.01.2013, at 23:40, Scott Wood wrote:
On 01/31/2013 01:20:39 PM, Alexander Graf wrote:
On 31.01.2013, at 20:05, Alexander Graf wrote:
On 31.01.2013, at 19:54, Scott Wood wrote:
On 01/31/2013 12:52:41 PM, Alexander Graf wrote:
On 31.01.2013, at 19:43, Scott Wood wrote:
On 01/31/2013 12:21:07 PM, Alexander Graf wrote:
How about something like this? Then both targets at least
suck as much :).
I'm not sure that should be the goal...
Thanks to e500mc's awful hardware design, we don't know who
sets the MSR_DE bit. Once we forced it onto the guest, we have no
change to know whether the guest also set it or not. We could only
guess.
MSRP[DEP] can prevent the guest from modifying MSR[DE] -- but
we still need to set it in the first place.
According to ISA V2.06B, the hypervisor should set DBCR0[EDM]
to let the guest know that the debug resources are not available, and
that the value of MSR[DE] is not specified and not modifiable.
So what would the guest do then to tell the hypervisor that it
actually wants to know about debug events?
The guest is out of luck, just as if a JTAG were in use.
Hrm.
Can we somehow generalize this out of luck behavior?
Every time we would set or clear an MSR bit in shadow_msr on
e500v2, we would instead set or clear it in the real MSR. That way
only e500mc is out of luck, but the code would still be shared.
I don't follow. e500v2 is just as out-of-luck. The mechanism
simply does not support sharing debug resources.
For e500v2 we have 2 fields
* MSR as the guest sees it
* MSR as we execute when the guest runs
Since we know the MSR when the guest sees it, we can decide what to do
when we get an unhandled debug interrupt.
That's not the same thing as making the real MSR[DE] show up in the guest
MSR[DE].
There are other problems with sharing -- what happens when both host and
guest
try to write to a particular IAC or DAC?
Also, performance would be pretty awful if the guest has e.g. single
stepping in
DBCR0 enabled but MSR[DE]=0, and the host doesn't care about single stepping
(but does want debugging enabled in general).
What do you mean by the real MSR? The real MSR is shadow_msr,
and MSR_DE must always be set there if the host is debugging the
guest. As for reflecting it into the guest MSR, we could, but I don't
really see the point. We're never going to actually send a debug
exception to the guest when the host owns the debug resources.
Why not? That's the whole point of jumping through user space.
That's still needed for software breakpoints, which don't rely on the debug
resources.
1) guest exits with debug interrupt
2) QEMU gets a debug exit
3) QEMU checks in its list whether it belongs to its own debug
points
4) if not, it reinjects the interrupt into the guest
Step 4 is pretty difficult to do when we don't know whether the guest
is actually capable of handling debug interrupts at that moment.
Software breakpoints take a Program interrupt rather than a Debug interrupt,
unless MSR[DE]=1 and DBCR0[TRAP]=1. If the guest does not own debug
resources
we should always send it to the Program interrupt, so MSR[DE] doesn't matter.
The = ~MSR_DE line is pointless on bookehv, and makes it harder
to read. I had to stare at it a while before noticing that you
initially set is_debug from the guest MSR and that you'd never really
clear MSR_DE here on bookehv.
Well, I'm mostly bouncing ideas here to find a way to express what
we're trying to say in a way that someone who hasn't read this email
thread would still understand what's going on :).
I think it's already straightforward enough if you accept that shared debug
resources aren't supported, and that we are either in a mode where the real
MSR[DE] reflects the guest MSR[DE], or a mode where the real MSR[DE] is
always
on in guest mode and the guest MSR[DE] is irrelevant.
How about this version?
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c index
38a62ef..9929c41 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -133,6 +133,28 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu
*vcpu)
#endif
}
+static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu) { #ifndef
+CONFIG_KVM_BOOKE_HV
+ /* Synchronize guest's desire to get debug interrupts into
shadow MSR */
+ vcpu-arch.shadow_msr = ~MSR_DE;
+ vcpu-arch.shadow_msr |= vcpu-arch.shared-msr MSR_DE; #endif
+
+ /* Force enable debug interrupts when user space wants to debug
*/
+ if (vcpu-guest_debug) {
RE: [PATCH 8/8] KVM:PPC:booke: Allow debug interrupt injection to guest
-Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf Sent: Thursday, February 07, 2013 8:29 PM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; k...@vger.kernel.org Subject: Re: [PATCH 8/8] KVM:PPC:booke: Allow debug interrupt injection to guest On 01.02.2013, at 23:38, Scott Wood wrote: On 01/31/2013 06:11:32 PM, Alexander Graf wrote: On 31.01.2013, at 23:40, Scott Wood wrote: On 01/31/2013 01:20:39 PM, Alexander Graf wrote: On 31.01.2013, at 20:05, Alexander Graf wrote: On 31.01.2013, at 19:54, Scott Wood wrote: On 01/31/2013 12:52:41 PM, Alexander Graf wrote: On 31.01.2013, at 19:43, Scott Wood wrote: On 01/31/2013 12:21:07 PM, Alexander Graf wrote: How about something like this? Then both targets at least suck as much :). I'm not sure that should be the goal... Thanks to e500mc's awful hardware design, we don't know who sets the MSR_DE bit. Once we forced it onto the guest, we have no change to know whether the guest also set it or not. We could only guess. MSRP[DEP] can prevent the guest from modifying MSR[DE] -- but we still need to set it in the first place. According to ISA V2.06B, the hypervisor should set DBCR0[EDM] to let the guest know that the debug resources are not available, and that the value of MSR[DE] is not specified and not modifiable. So what would the guest do then to tell the hypervisor that it actually wants to know about debug events? The guest is out of luck, just as if a JTAG were in use. Hrm. Can we somehow generalize this out of luck behavior? Every time we would set or clear an MSR bit in shadow_msr on e500v2, we would instead set or clear it in the real MSR. That way only e500mc is out of luck, but the code would still be shared. I don't follow. e500v2 is just as out-of-luck. The mechanism simply does not support sharing debug resources. For e500v2 we have 2 fields * MSR as the guest sees it * MSR as we execute when the guest runs Since we know the MSR when the guest sees it, we can decide what to do when we get an unhandled debug interrupt. That's not the same thing as making the real MSR[DE] show up in the guest MSR[DE]. There are other problems with sharing -- what happens when both host and guest try to write to a particular IAC or DAC? Also, performance would be pretty awful if the guest has e.g. single stepping in DBCR0 enabled but MSR[DE]=0, and the host doesn't care about single stepping (but does want debugging enabled in general). What do you mean by the real MSR? The real MSR is shadow_msr, and MSR_DE must always be set there if the host is debugging the guest. As for reflecting it into the guest MSR, we could, but I don't really see the point. We're never going to actually send a debug exception to the guest when the host owns the debug resources. Why not? That's the whole point of jumping through user space. That's still needed for software breakpoints, which don't rely on the debug resources. 1) guest exits with debug interrupt 2) QEMU gets a debug exit 3) QEMU checks in its list whether it belongs to its own debug points 4) if not, it reinjects the interrupt into the guest Step 4 is pretty difficult to do when we don't know whether the guest is actually capable of handling debug interrupts at that moment. Software breakpoints take a Program interrupt rather than a Debug interrupt, unless MSR[DE]=1 and DBCR0[TRAP]=1. If the guest does not own debug resources we should always send it to the Program interrupt, so MSR[DE] doesn't matter. The = ~MSR_DE line is pointless on bookehv, and makes it harder to read. I had to stare at it a while before noticing that you initially set is_debug from the guest MSR and that you'd never really clear MSR_DE here on bookehv. Well, I'm mostly bouncing ideas here to find a way to express what we're trying to say in a way that someone who hasn't read this email thread would still understand what's going on :). I think it's already straightforward enough if you accept that shared debug resources aren't supported, and that we are either in a mode where the real MSR[DE] reflects the guest MSR[DE], or a mode where the real MSR[DE] is always on in guest mode and the guest MSR[DE] is irrelevant. I think I'm starting to grasp what you're suggesting: On e500mc, have 2 modes 1) guest owns debug This is the normal operation. Here the guest defines the value of MSR_DE. The guest gets debug interrupts directly. 2) host owns debug In this case, take away any debug capabilities from the guest. Everything debug related goes straight to QEMU. On e500v2, have 2 modes 1) guest owns debug This is the normal operation. Here the guest
Re: [PATCH 8/8] KVM:PPC:booke: Allow debug interrupt injection to guest
On 07.02.2013, at 16:25, Bhushan Bharat-R65777 wrote: -Original Message- From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf Sent: Thursday, February 07, 2013 8:29 PM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; k...@vger.kernel.org Subject: Re: [PATCH 8/8] KVM:PPC:booke: Allow debug interrupt injection to guest On 01.02.2013, at 23:38, Scott Wood wrote: On 01/31/2013 06:11:32 PM, Alexander Graf wrote: On 31.01.2013, at 23:40, Scott Wood wrote: On 01/31/2013 01:20:39 PM, Alexander Graf wrote: On 31.01.2013, at 20:05, Alexander Graf wrote: On 31.01.2013, at 19:54, Scott Wood wrote: On 01/31/2013 12:52:41 PM, Alexander Graf wrote: On 31.01.2013, at 19:43, Scott Wood wrote: On 01/31/2013 12:21:07 PM, Alexander Graf wrote: How about something like this? Then both targets at least suck as much :). I'm not sure that should be the goal... Thanks to e500mc's awful hardware design, we don't know who sets the MSR_DE bit. Once we forced it onto the guest, we have no change to know whether the guest also set it or not. We could only guess. MSRP[DEP] can prevent the guest from modifying MSR[DE] -- but we still need to set it in the first place. According to ISA V2.06B, the hypervisor should set DBCR0[EDM] to let the guest know that the debug resources are not available, and that the value of MSR[DE] is not specified and not modifiable. So what would the guest do then to tell the hypervisor that it actually wants to know about debug events? The guest is out of luck, just as if a JTAG were in use. Hrm. Can we somehow generalize this out of luck behavior? Every time we would set or clear an MSR bit in shadow_msr on e500v2, we would instead set or clear it in the real MSR. That way only e500mc is out of luck, but the code would still be shared. I don't follow. e500v2 is just as out-of-luck. The mechanism simply does not support sharing debug resources. For e500v2 we have 2 fields * MSR as the guest sees it * MSR as we execute when the guest runs Since we know the MSR when the guest sees it, we can decide what to do when we get an unhandled debug interrupt. That's not the same thing as making the real MSR[DE] show up in the guest MSR[DE]. There are other problems with sharing -- what happens when both host and guest try to write to a particular IAC or DAC? Also, performance would be pretty awful if the guest has e.g. single stepping in DBCR0 enabled but MSR[DE]=0, and the host doesn't care about single stepping (but does want debugging enabled in general). What do you mean by the real MSR? The real MSR is shadow_msr, and MSR_DE must always be set there if the host is debugging the guest. As for reflecting it into the guest MSR, we could, but I don't really see the point. We're never going to actually send a debug exception to the guest when the host owns the debug resources. Why not? That's the whole point of jumping through user space. That's still needed for software breakpoints, which don't rely on the debug resources. 1) guest exits with debug interrupt 2) QEMU gets a debug exit 3) QEMU checks in its list whether it belongs to its own debug points 4) if not, it reinjects the interrupt into the guest Step 4 is pretty difficult to do when we don't know whether the guest is actually capable of handling debug interrupts at that moment. Software breakpoints take a Program interrupt rather than a Debug interrupt, unless MSR[DE]=1 and DBCR0[TRAP]=1. If the guest does not own debug resources we should always send it to the Program interrupt, so MSR[DE] doesn't matter. The = ~MSR_DE line is pointless on bookehv, and makes it harder to read. I had to stare at it a while before noticing that you initially set is_debug from the guest MSR and that you'd never really clear MSR_DE here on bookehv. Well, I'm mostly bouncing ideas here to find a way to express what we're trying to say in a way that someone who hasn't read this email thread would still understand what's going on :). I think it's already straightforward enough if you accept that shared debug resources aren't supported, and that we are either in a mode where the real MSR[DE] reflects the guest MSR[DE], or a mode where the real MSR[DE] is always on in guest mode and the guest MSR[DE] is irrelevant. I think I'm starting to grasp what you're suggesting: On e500mc, have 2 modes 1) guest owns debug This is the normal operation. Here the guest defines the value of MSR_DE. The guest gets debug interrupts directly. 2) host owns debug In this case, take away any debug capabilities from the guest. Everything debug related goes straight to QEMU. On e500v2, have 2 modes 1) guest owns debug This is the normal operation. Here the guest defines the value of MSR_DE. The guest gets debug interrupts
Re: [PATCH] KVM: PPC: e500: fix BOOKE_INTERRUPT_ALIGNMENT build break
On 02/07/2013 06:20:33 PM, Alexander Graf wrote: On 07.02.2013, at 23:17, Scott Wood wrote: Commit 2765788fcc3dc64920dd2be3d32319b50b1e2813 (KVM: PPC: BookE: Handle alignment interrupts) broke the build by adding mismatched parentheses. Signed-off-by: Scott Wood scottw...@freescale.com Thanks a lot for catching this. This patch hasn't gone into kvm-ppc-next yet and is still in my (partially untested) kvm-ppc-queue branch. Would you mind if I just squash this fix with the original commit? That way we don't break bisectability later. Go ahead. -Scott -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: PPC: e500: fix BOOKE_INTERRUPT_ALIGNMENT build break
On 08.02.2013, at 01:22, Scott Wood wrote: On 02/07/2013 06:20:33 PM, Alexander Graf wrote: On 07.02.2013, at 23:17, Scott Wood wrote: Commit 2765788fcc3dc64920dd2be3d32319b50b1e2813 (KVM: PPC: BookE: Handle alignment interrupts) broke the build by adding mismatched parentheses. Signed-off-by: Scott Wood scottw...@freescale.com Thanks a lot for catching this. This patch hasn't gone into kvm-ppc-next yet and is still in my (partially untested) kvm-ppc-queue branch. Would you mind if I just squash this fix with the original commit? That way we don't break bisectability later. Go ahead. Thanks, done :) Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
