* Avi Kivity <avi@xxxxxxxxxx> wrote: > > I think you didnt understand my point. I am talking about 'perf kvm top' > > hanging if Qemu hangs. > > Use non-blocking I/O, report that guest as dead. No point in profiling it, > it isn't making any progress. Erm, at what point do i decide that a guest is 'dead' versus 'just lagged due to lots of IO' ? Also, do you realize that you increase complexity (the use of non-blocking IO), just to protect against something that wouldnt happen if the right solution was used in the first place? > > 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. > > If qemu has a bug in the resource enumeration code, you can't profile one > guest. If the kernel has a bug in the resource enumeration code, the system > either panics or needs to be rebooted later. This is really simple code, not rocket science. If there's a bug in it we'll fix it. On the other hand a 500KLOC+ piece of Qemu code has lots of places to hang, so that is a large cross section. Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
