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.
