It's hard for me to argue against a hypothetical implementation, but all
user-space driven solutions for resource enumeration i've seen so far had
weaknesses that kernel-based solutions dont have.
I think you didnt understand my point. I am talking about 'perf kvm top'
hanging if Qemu hangs.
With a proper in-kernel enumeration the kernel would always guarantee the
functionality, even if the vcpu does not make progress (i.e. it's "hung").
With this implemented in Qemu we lose that kind of robustness guarantee.
And especially during development (when developers use instrumentation the
most) is it important to have robust instrumentation that does not hang along
with the Qemu process.
How on earth can you justify a bug ("perf kvm top" hanging) with that there
are other bugs as well?
Basically you are arguing the equivalent that a gdb session would be fine to
become unresponsive if the debugged task hangs. Fortunately ptrace is
kernel-based and it never 'hangs' if the user-space process hangs somewhere.
This is an essential property of good instrumentation.
So the enumeration method you suggested is a poor, sub-part solution, simple
as that.
We can still profile any of those tools without the profiler breaking if the
debugged tool breaks ...
(Then you'll be enjoyed to hear that perf has enabled exactly that, and that we
are working towards that precise usecase.)
Ingo
--
