| Message ID | 1372858255-19708-2-git-send-email-mihai.caraman@freescale.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On 03.07.2013, at 15:30, Mihai Caraman wrote: > Some guests are making use of return from machine check instruction > to do crazy things even though the 64-bit kernel doesn't handle yet > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction accordingly. > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> > --- > arch/powerpc/include/asm/kvm_host.h | 1 + > arch/powerpc/kvm/booke_emulate.c | 25 +++++++++++++++++++++++++ > arch/powerpc/kvm/timing.c | 1 + > 3 files changed, 27 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h > index af326cd..0466789 100644 > --- a/arch/powerpc/include/asm/kvm_host.h > +++ b/arch/powerpc/include/asm/kvm_host.h > @@ -148,6 +148,7 @@ enum kvm_exit_types { > EMULATED_TLBWE_EXITS, > EMULATED_RFI_EXITS, > EMULATED_RFCI_EXITS, > + EMULATED_RFMCI_EXITS, I would quite frankly prefer to see us abandon the whole exit timing framework in the kernel and instead use trace points. Then we don't have to maintain all of this randomly exercised code. FWIW I think in this case however, treating RFMCI the same as RFI or random "instruction emulation" shouldn't hurt. This whole table is only about timing measurements. If you want to know for real what's going on, use trace points. Otherwise looks good. Alex > DEC_EXITS, > EXT_INTR_EXITS, > HALT_WAKEUP, > diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c > index 27a4b28..aaff1b7 100644 > --- a/arch/powerpc/kvm/booke_emulate.c > +++ b/arch/powerpc/kvm/booke_emulate.c > @@ -23,6 +23,7 @@ > > #include "booke.h" > > +#define OP_19_XOP_RFMCI 38 > #define OP_19_XOP_RFI 50 > #define OP_19_XOP_RFCI 51 > > @@ -43,6 +44,12 @@ static void kvmppc_emul_rfci(struct kvm_vcpu *vcpu) > kvmppc_set_msr(vcpu, vcpu->arch.csrr1); > } > > +static void kvmppc_emul_rfmci(struct kvm_vcpu *vcpu) > +{ > + vcpu->arch.pc = vcpu->arch.mcsrr0; > + kvmppc_set_msr(vcpu, vcpu->arch.mcsrr1); > +} > + > int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu, > unsigned int inst, int *advance) > { > @@ -65,6 +72,12 @@ int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu, > *advance = 0; > break; > > + case OP_19_XOP_RFMCI: > + kvmppc_emul_rfmci(vcpu); > + kvmppc_set_exit_type(vcpu, EMULATED_RFMCI_EXITS); > + *advance = 0; > + break; > + > default: > emulated = EMULATE_FAIL; > break; > @@ -138,6 +151,12 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val) > case SPRN_DBCR1: > vcpu->arch.dbg_reg.dbcr1 = spr_val; > break; > + case SPRN_MCSRR0: > + vcpu->arch.mcsrr0 = spr_val; > + break; > + case SPRN_MCSRR1: > + vcpu->arch.mcsrr1 = spr_val; > + break; > case SPRN_DBSR: > vcpu->arch.dbsr &= ~spr_val; > break; > @@ -284,6 +303,12 @@ int kvmppc_booke_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val) > case SPRN_DBCR1: > *spr_val = vcpu->arch.dbg_reg.dbcr1; > break; > + case SPRN_MCSRR0: > + *spr_val = vcpu->arch.mcsrr0; > + break; > + case SPRN_MCSRR1: > + *spr_val = vcpu->arch.mcsrr1; > + break; > case SPRN_DBSR: > *spr_val = vcpu->arch.dbsr; > break; > diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c > index c392d26..670f63d 100644 > --- a/arch/powerpc/kvm/timing.c > +++ b/arch/powerpc/kvm/timing.c > @@ -129,6 +129,7 @@ static const char *kvm_exit_names[__NUMBER_OF_KVM_EXIT_TYPES] = { > [EMULATED_TLBSX_EXITS] = "EMUL_TLBSX", > [EMULATED_TLBWE_EXITS] = "EMUL_TLBWE", > [EMULATED_RFI_EXITS] = "EMUL_RFI", > + [EMULATED_RFMCI_EXITS] = "EMUL_RFMCI", > [DEC_EXITS] = "DEC", > [EXT_INTR_EXITS] = "EXTINT", > [HALT_WAKEUP] = "HALT", > -- > 1.7.3.4 > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/08/2013 01:45:58 PM, Alexander Graf wrote: > > On 03.07.2013, at 15:30, Mihai Caraman wrote: > > > Some guests are making use of return from machine check instruction > > to do crazy things even though the 64-bit kernel doesn't handle yet > > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction > accordingly. > > > > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> > > --- > > arch/powerpc/include/asm/kvm_host.h | 1 + > > arch/powerpc/kvm/booke_emulate.c | 25 +++++++++++++++++++++++++ > > arch/powerpc/kvm/timing.c | 1 + > > 3 files changed, 27 insertions(+), 0 deletions(-) > > > > diff --git a/arch/powerpc/include/asm/kvm_host.h > b/arch/powerpc/include/asm/kvm_host.h > > index af326cd..0466789 100644 > > --- a/arch/powerpc/include/asm/kvm_host.h > > +++ b/arch/powerpc/include/asm/kvm_host.h > > @@ -148,6 +148,7 @@ enum kvm_exit_types { > > EMULATED_TLBWE_EXITS, > > EMULATED_RFI_EXITS, > > EMULATED_RFCI_EXITS, > > + EMULATED_RFMCI_EXITS, > > I would quite frankly prefer to see us abandon the whole exit timing > framework in the kernel and instead use trace points. Then we don't > have to maintain all of this randomly exercised code. Would this map well to tracepoints? We're not trying to track discrete events, so much as accumulated time spent in different areas. -Scott
On 07/09/2013 07:16 PM, Scott Wood wrote: > On 07/08/2013 01:45:58 PM, Alexander Graf wrote: >> >> On 03.07.2013, at 15:30, Mihai Caraman wrote: >> >> > Some guests are making use of return from machine check instruction >> > to do crazy things even though the 64-bit kernel doesn't handle yet >> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction >> accordingly. >> > >> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> >> > --- >> > arch/powerpc/include/asm/kvm_host.h | 1 + >> > arch/powerpc/kvm/booke_emulate.c | 25 +++++++++++++++++++++++++ >> > arch/powerpc/kvm/timing.c | 1 + >> > 3 files changed, 27 insertions(+), 0 deletions(-) >> > >> > diff --git a/arch/powerpc/include/asm/kvm_host.h >> b/arch/powerpc/include/asm/kvm_host.h >> > index af326cd..0466789 100644 >> > --- a/arch/powerpc/include/asm/kvm_host.h >> > +++ b/arch/powerpc/include/asm/kvm_host.h >> > @@ -148,6 +148,7 @@ enum kvm_exit_types { >> > EMULATED_TLBWE_EXITS, >> > EMULATED_RFI_EXITS, >> > EMULATED_RFCI_EXITS, >> > + EMULATED_RFMCI_EXITS, >> >> I would quite frankly prefer to see us abandon the whole exit timing >> framework in the kernel and instead use trace points. Then we don't >> have to maintain all of this randomly exercised code. > > Would this map well to tracepoints? We're not trying to track > discrete events, so much as accumulated time spent in different areas. I think so. We'd just have to emit tracepoints as soon as we enter handle_exit and in prepare_to_enter. Then a user space program should have everything it needs to create statistics out of that. It would certainly simplify the entry/exit path. Alex
On 07/09/2013 12:46:32 PM, Alexander Graf wrote: > On 07/09/2013 07:16 PM, Scott Wood wrote: >> On 07/08/2013 01:45:58 PM, Alexander Graf wrote: >>> >>> On 03.07.2013, at 15:30, Mihai Caraman wrote: >>> >>> > Some guests are making use of return from machine check >>> instruction >>> > to do crazy things even though the 64-bit kernel doesn't handle >>> yet >>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction >>> accordingly. >>> > >>> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> >>> > --- >>> > arch/powerpc/include/asm/kvm_host.h | 1 + >>> > arch/powerpc/kvm/booke_emulate.c | 25 >>> +++++++++++++++++++++++++ >>> > arch/powerpc/kvm/timing.c | 1 + >>> > 3 files changed, 27 insertions(+), 0 deletions(-) >>> > >>> > diff --git a/arch/powerpc/include/asm/kvm_host.h >>> b/arch/powerpc/include/asm/kvm_host.h >>> > index af326cd..0466789 100644 >>> > --- a/arch/powerpc/include/asm/kvm_host.h >>> > +++ b/arch/powerpc/include/asm/kvm_host.h >>> > @@ -148,6 +148,7 @@ enum kvm_exit_types { >>> > EMULATED_TLBWE_EXITS, >>> > EMULATED_RFI_EXITS, >>> > EMULATED_RFCI_EXITS, >>> > + EMULATED_RFMCI_EXITS, >>> >>> I would quite frankly prefer to see us abandon the whole exit >>> timing framework in the kernel and instead use trace points. Then >>> we don't have to maintain all of this randomly exercised code. >> >> Would this map well to tracepoints? We're not trying to track >> discrete events, so much as accumulated time spent in different >> areas. > > I think so. We'd just have to emit tracepoints as soon as we enter > handle_exit and in prepare_to_enter. Then a user space program should > have everything it needs to create statistics out of that. It would > certainly simplify the entry/exit path. I was hoping that wasn't going to be your answer. :-) Such a change would introduce a new dependency, more complexity, and the possibility for bad totals to result from a ring buffer filling faster than userspace can drain it. I also don't see how it would simplify entry/exit, since we'd still need to take timestamps in the same places, in order to record a final event that says how long a particular event took. -Scott
On 09.07.2013, at 20:29, Scott Wood wrote: > On 07/09/2013 12:46:32 PM, Alexander Graf wrote: >> On 07/09/2013 07:16 PM, Scott Wood wrote: >>> On 07/08/2013 01:45:58 PM, Alexander Graf wrote: >>>> On 03.07.2013, at 15:30, Mihai Caraman wrote: >>>> > Some guests are making use of return from machine check instruction >>>> > to do crazy things even though the 64-bit kernel doesn't handle yet >>>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction accordingly. >>>> > >>>> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> >>>> > --- >>>> > arch/powerpc/include/asm/kvm_host.h | 1 + >>>> > arch/powerpc/kvm/booke_emulate.c | 25 +++++++++++++++++++++++++ >>>> > arch/powerpc/kvm/timing.c | 1 + >>>> > 3 files changed, 27 insertions(+), 0 deletions(-) >>>> > >>>> > diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h >>>> > index af326cd..0466789 100644 >>>> > --- a/arch/powerpc/include/asm/kvm_host.h >>>> > +++ b/arch/powerpc/include/asm/kvm_host.h >>>> > @@ -148,6 +148,7 @@ enum kvm_exit_types { >>>> > EMULATED_TLBWE_EXITS, >>>> > EMULATED_RFI_EXITS, >>>> > EMULATED_RFCI_EXITS, >>>> > + EMULATED_RFMCI_EXITS, >>>> I would quite frankly prefer to see us abandon the whole exit timing framework in the kernel and instead use trace points. Then we don't have to maintain all of this randomly exercised code. >>> Would this map well to tracepoints? We're not trying to track discrete events, so much as accumulated time spent in different areas. >> I think so. We'd just have to emit tracepoints as soon as we enter handle_exit and in prepare_to_enter. Then a user space program should have everything it needs to create statistics out of that. It would certainly simplify the entry/exit path. > > I was hoping that wasn't going to be your answer. :-) > > Such a change would introduce a new dependency, more complexity, and the possibility for bad totals to result from a ring buffer filling faster than userspace can drain it. Well, at least it would allow for optional tracing :). Today you have to change a compile flag to enable / disable timing stats. > > I also don't see how it would simplify entry/exit, since we'd still need to take timestamps in the same places, in order to record a final event that says how long a particular event took. Not sure I understand. What the timing stats do is that they measure the time between [exit ... entry], right? We'd do the same thing, just all in C code. That means we would become slightly less accurate, but gain dynamic enabling of the traces and get rid of all the timing stat asm code. Alex
On 07/09/2013 04:49:32 PM, Alexander Graf wrote: > > On 09.07.2013, at 20:29, Scott Wood wrote: > > > On 07/09/2013 12:46:32 PM, Alexander Graf wrote: > >> On 07/09/2013 07:16 PM, Scott Wood wrote: > >>> On 07/08/2013 01:45:58 PM, Alexander Graf wrote: > >>>> On 03.07.2013, at 15:30, Mihai Caraman wrote: > >>>> > Some guests are making use of return from machine check > instruction > >>>> > to do crazy things even though the 64-bit kernel doesn't > handle yet > >>>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction > accordingly. > >>>> > > >>>> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> > >>>> > --- > >>>> > arch/powerpc/include/asm/kvm_host.h | 1 + > >>>> > arch/powerpc/kvm/booke_emulate.c | 25 > +++++++++++++++++++++++++ > >>>> > arch/powerpc/kvm/timing.c | 1 + > >>>> > 3 files changed, 27 insertions(+), 0 deletions(-) > >>>> > > >>>> > diff --git a/arch/powerpc/include/asm/kvm_host.h > b/arch/powerpc/include/asm/kvm_host.h > >>>> > index af326cd..0466789 100644 > >>>> > --- a/arch/powerpc/include/asm/kvm_host.h > >>>> > +++ b/arch/powerpc/include/asm/kvm_host.h > >>>> > @@ -148,6 +148,7 @@ enum kvm_exit_types { > >>>> > EMULATED_TLBWE_EXITS, > >>>> > EMULATED_RFI_EXITS, > >>>> > EMULATED_RFCI_EXITS, > >>>> > + EMULATED_RFMCI_EXITS, > >>>> I would quite frankly prefer to see us abandon the whole exit > timing framework in the kernel and instead use trace points. Then we > don't have to maintain all of this randomly exercised code. > >>> Would this map well to tracepoints? We're not trying to track > discrete events, so much as accumulated time spent in different areas. > >> I think so. We'd just have to emit tracepoints as soon as we enter > handle_exit and in prepare_to_enter. Then a user space program should > have everything it needs to create statistics out of that. It would > certainly simplify the entry/exit path. > > > > I was hoping that wasn't going to be your answer. :-) > > > > Such a change would introduce a new dependency, more complexity, > and the possibility for bad totals to result from a ring buffer > filling faster than userspace can drain it. > > Well, at least it would allow for optional tracing :). Today you have > to change a compile flag to enable / disable timing stats. > > > > > I also don't see how it would simplify entry/exit, since we'd still > need to take timestamps in the same places, in order to record a > final event that says how long a particular event took. > > Not sure I understand. What the timing stats do is that they measure > the time between [exit ... entry], right? We'd do the same thing, > just all in C code. That means we would become slightly less > accurate, but gain dynamic enabling of the traces and get rid of all > the timing stat asm code. Compile-time enabling bothers me less than a loss of accuracy (not just a small loss by moving into C code, but a potential for a large loss if we overflow the buffer) and a dependency on a userspace tool (both in terms of the tool needing to be written, and in the hassle of ensuring that it's present in the root filesystem of whatever system I'm testing). And the whole mechanism will be more complicated. Lots of debug options are enabled at build time; why must this be different? -Scott
On 09.07.2013, at 23:54, Scott Wood wrote: > On 07/09/2013 04:49:32 PM, Alexander Graf wrote: >> On 09.07.2013, at 20:29, Scott Wood wrote: >> > On 07/09/2013 12:46:32 PM, Alexander Graf wrote: >> >> On 07/09/2013 07:16 PM, Scott Wood wrote: >> >>> On 07/08/2013 01:45:58 PM, Alexander Graf wrote: >> >>>> On 03.07.2013, at 15:30, Mihai Caraman wrote: >> >>>> > Some guests are making use of return from machine check instruction >> >>>> > to do crazy things even though the 64-bit kernel doesn't handle yet >> >>>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction accordingly. >> >>>> > >> >>>> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> >> >>>> > --- >> >>>> > arch/powerpc/include/asm/kvm_host.h | 1 + >> >>>> > arch/powerpc/kvm/booke_emulate.c | 25 +++++++++++++++++++++++++ >> >>>> > arch/powerpc/kvm/timing.c | 1 + >> >>>> > 3 files changed, 27 insertions(+), 0 deletions(-) >> >>>> > >> >>>> > diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h >> >>>> > index af326cd..0466789 100644 >> >>>> > --- a/arch/powerpc/include/asm/kvm_host.h >> >>>> > +++ b/arch/powerpc/include/asm/kvm_host.h >> >>>> > @@ -148,6 +148,7 @@ enum kvm_exit_types { >> >>>> > EMULATED_TLBWE_EXITS, >> >>>> > EMULATED_RFI_EXITS, >> >>>> > EMULATED_RFCI_EXITS, >> >>>> > + EMULATED_RFMCI_EXITS, >> >>>> I would quite frankly prefer to see us abandon the whole exit timing framework in the kernel and instead use trace points. Then we don't have to maintain all of this randomly exercised code. >> >>> Would this map well to tracepoints? We're not trying to track discrete events, so much as accumulated time spent in different areas. >> >> I think so. We'd just have to emit tracepoints as soon as we enter handle_exit and in prepare_to_enter. Then a user space program should have everything it needs to create statistics out of that. It would certainly simplify the entry/exit path. >> > >> > I was hoping that wasn't going to be your answer. :-) >> > >> > Such a change would introduce a new dependency, more complexity, and the possibility for bad totals to result from a ring buffer filling faster than userspace can drain it. >> Well, at least it would allow for optional tracing :). Today you have to change a compile flag to enable / disable timing stats. >> > >> > I also don't see how it would simplify entry/exit, since we'd still need to take timestamps in the same places, in order to record a final event that says how long a particular event took. >> Not sure I understand. What the timing stats do is that they measure the time between [exit ... entry], right? We'd do the same thing, just all in C code. That means we would become slightly less accurate, but gain dynamic enabling of the traces and get rid of all the timing stat asm code. > > Compile-time enabling bothers me less than a loss of accuracy (not just a small loss by moving into C code, but a potential for a large loss if we overflow the buffer) Then don't overflow the buffer. Make it large enough. IIRC ftrace improved recently to dynamically increase the buffer size too. Steven, do I remember correctly here? > and a dependency on a userspace tool We already have that for kvm_stat. It's a simple python script - and you surely have python on your rootfs, no? > (both in terms of the tool needing to be written, and in the hassle of ensuring that it's present in the root filesystem of whatever system I'm testing). And the whole mechanism will be more complicated. It'll also be more flexible at the same time. You could take the logs and actually check what's going on to debug issues that you're encountering for example. We could even go as far as sharing the same tool with other architectures, so that we only have to learn how to debug things once. > Lots of debug options are enabled at build time; why must this be different? Because I think it's valuable as debug tool for cases where compile time switches are not the best way of debugging things. It's not a high profile thing to tackle for me tbh, but I don't really think working heavily on the timing stat thing is the correct path to walk along. Alex
On Wed, 2013-07-10 at 00:00 +0200, Alexander Graf wrote: > Then don't overflow the buffer. Make it large enough. IIRC ftrace improved recently to dynamically increase the buffer size too. > > Steven, do I remember correctly here? Not really. Ftrace only dynamically increases the buffer when the trace is first used. Other than that, the size is static. I also wouldn't suggest allocating the buffer when needed as that has the overhead of allocating memory. -- Steve
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h index af326cd..0466789 100644 --- a/arch/powerpc/include/asm/kvm_host.h +++ b/arch/powerpc/include/asm/kvm_host.h @@ -148,6 +148,7 @@ enum kvm_exit_types { EMULATED_TLBWE_EXITS, EMULATED_RFI_EXITS, EMULATED_RFCI_EXITS, + EMULATED_RFMCI_EXITS, DEC_EXITS, EXT_INTR_EXITS, HALT_WAKEUP, diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c index 27a4b28..aaff1b7 100644 --- a/arch/powerpc/kvm/booke_emulate.c +++ b/arch/powerpc/kvm/booke_emulate.c @@ -23,6 +23,7 @@ #include "booke.h" +#define OP_19_XOP_RFMCI 38 #define OP_19_XOP_RFI 50 #define OP_19_XOP_RFCI 51 @@ -43,6 +44,12 @@ static void kvmppc_emul_rfci(struct kvm_vcpu *vcpu) kvmppc_set_msr(vcpu, vcpu->arch.csrr1); } +static void kvmppc_emul_rfmci(struct kvm_vcpu *vcpu) +{ + vcpu->arch.pc = vcpu->arch.mcsrr0; + kvmppc_set_msr(vcpu, vcpu->arch.mcsrr1); +} + int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu, unsigned int inst, int *advance) { @@ -65,6 +72,12 @@ int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu, *advance = 0; break; + case OP_19_XOP_RFMCI: + kvmppc_emul_rfmci(vcpu); + kvmppc_set_exit_type(vcpu, EMULATED_RFMCI_EXITS); + *advance = 0; + break; + default: emulated = EMULATE_FAIL; break; @@ -138,6 +151,12 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val) case SPRN_DBCR1: vcpu->arch.dbg_reg.dbcr1 = spr_val; break; + case SPRN_MCSRR0: + vcpu->arch.mcsrr0 = spr_val; + break; + case SPRN_MCSRR1: + vcpu->arch.mcsrr1 = spr_val; + break; case SPRN_DBSR: vcpu->arch.dbsr &= ~spr_val; break; @@ -284,6 +303,12 @@ int kvmppc_booke_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val) case SPRN_DBCR1: *spr_val = vcpu->arch.dbg_reg.dbcr1; break; + case SPRN_MCSRR0: + *spr_val = vcpu->arch.mcsrr0; + break; + case SPRN_MCSRR1: + *spr_val = vcpu->arch.mcsrr1; + break; case SPRN_DBSR: *spr_val = vcpu->arch.dbsr; break; diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c index c392d26..670f63d 100644 --- a/arch/powerpc/kvm/timing.c +++ b/arch/powerpc/kvm/timing.c @@ -129,6 +129,7 @@ static const char *kvm_exit_names[__NUMBER_OF_KVM_EXIT_TYPES] = { [EMULATED_TLBSX_EXITS] = "EMUL_TLBSX", [EMULATED_TLBWE_EXITS] = "EMUL_TLBWE", [EMULATED_RFI_EXITS] = "EMUL_RFI", + [EMULATED_RFMCI_EXITS] = "EMUL_RFMCI", [DEC_EXITS] = "DEC", [EXT_INTR_EXITS] = "EXTINT", [HALT_WAKEUP] = "HALT",
Some guests are making use of return from machine check instruction to do crazy things even though the 64-bit kernel doesn't handle yet this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction accordingly. Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> --- arch/powerpc/include/asm/kvm_host.h | 1 + arch/powerpc/kvm/booke_emulate.c | 25 +++++++++++++++++++++++++ arch/powerpc/kvm/timing.c | 1 + 3 files changed, 27 insertions(+), 0 deletions(-)