[Bug 206579] KVM with passthrough generates "BUG: kernel NULL pointer dereference" and crashes

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=206579

--- Comment #44 from muncrief (rmuncrief@humanavance.com) ---
(In reply to Paolo Bonzini from comment #43)
> Hey, this should fix the warning (not sure because it's untested and I'd
> wait for Suravee to confirm it's the intended behavior): ...
> 

Thanks Paolo. I assumed you meant "svm->avic_is_running == 1" because "is_run"
isn't defined, but along the way I could see that functions like
"avic_set_running" actually called "avic_vcpu_load" with "is_true" set to true.

So, being confused about the intended logic, I spent an interesting day trying
to figure out why the stack trace seemed to show "avic_vcpu_load" being called
by "kvm_vcpu_block", which didn't have any obvious calls to "avic_vcpu_load".

I don't know how to setup gdb to debug the kernel, and after doing a quick
search it looked pretty difficult, so I just used an old fashioned technique of
defining a global unsigned integer and setting/clearing tracking bits
throughout "kvm_vcpu_block" to trace the real time flow of the code. I then
output the bits from "avic_vcpu_load" when the error condition occurred so I
could see where "kvm_vcpu_block" was when the warning condition was triggered.

And what I found was that "avic_vcpu_load" is branched to after the
"schedule()" call in "kvm_vcpu_block". There's a for loop that executes
"prepare_to_swait_exclusive" and then "schedule()", and that's when
"avic_vcpu_load" is executed.

When I saw that I realized that tracking bits wouldn't do, as it appears to be
some kind of preemption issue. So I'm seriously thinking about setting up my
system for gdb kernel debugging because it really pissed me off that I couldn't
figure it out! :)

Anyway, yes, I'm crazy like that :) I spent the whole day sprinkling tracking
bits throughout the code and then recompiling the kernel over and over so I
could decipher real time code flow. Hey! Don't laugh! That's the way we used to
do it in the olden days ... :)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.