On Wed, Dec 19, 2012 at 12:01:19AM +0100, Alexander Graf wrote:
>
> On 18.12.2012, at 23:54, Scott Wood wrote:
>
> > On 12/18/2012 06:38:41 AM, Alexander Graf wrote:
> >> When we hit an emulation result that we didn't expect, that is an error,
> >> but it's nothing that warrants a BUG(), because it can be guest triggered.
> >> So instead, let's only WARN() the user that this happened.
> >> Signed-off-by: Alexander Graf <[email protected]>
> >> ---
> >> arch/powerpc/kvm/powerpc.c | 3 ++-
> >> 1 files changed, 2 insertions(+), 1 deletions(-)
> >> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> >> index be83fca..e2225e5 100644
> >> --- a/arch/powerpc/kvm/powerpc.c
> >> +++ b/arch/powerpc/kvm/powerpc.c
> >> @@ -237,7 +237,8 @@ int kvmppc_emulate_mmio(struct kvm_run *run, struct
> >> kvm_vcpu *vcpu)
> >> r = RESUME_HOST;
> >> break;
> >> default:
> >> - BUG();
> >> + WARN_ON(1);
> >> + r = RESUME_GUEST;
> >
> > Do you have a specific way of a guest triggering this in mind, or is it
> > just being cautious? The guest probably shouldn't be allowed to spam the
> > kernel log with WARNs either. Is a traceback even useful here?
>
> For debugging, yes. But maybe we would be better off with a trace point.
> Anyway, a WARN is better than a BUG either way for now.
>
> I was able to provoke this by live patching an instruction without flushing
> the icache, so that the last_inst instruction fetch gets a different
> instruction from the instruction that resulted in the trap we're currently in.
>
If guest can trigger this it better be WARN_ON_ONCE(). Otherwise, as
Scott said, guest will be able to spam host kernel log.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
