Re: Deadlock due to EPT_VIOLATION

[Sean Christopherson <seanjc@google.com>]

On Fri, May 26, 2023, Brian Rak wrote:
> 
> On 5/24/2023 9:39 AM, Brian Rak wrote:
> > 
> > On 5/23/2023 12:22 PM, Sean Christopherson wrote:
> > > The other thing that would be helpful would be getting kernel stack
> > > traces of the
> > > relevant tasks/threads.� The vCPU stack traces won't be interesting,
> > > but it'll
> > > likely help to see what the fallocate() tasks are doing.
> > I'll see what I can come up with here, I was running into some
> > difficulty getting useful stack traces out of the VM
> 
> I didn't have any luck gathering guest-level stack traces - kaslr makes it
> pretty difficult even if I have the guest kernel symbols.

Sorry, I was hoping to get host stack traces, not guest stack traces.  I am hoping
to see what the fallocate() in the *host* is doing.

Another datapoint that might provide insight would be seeing if/how KVM's page
faults stats change, e.g. look at /sys/kernel/debug/kvm/pf_* multiple times when
the guest is stuck.

Are you able to run modified host kernels?  If so, the easiest next step, assuming
stack traces don't provide a smoking gun, would be to add printks into the page
fault path to see why KVM is retrying instead of installing a SPTE.