On Thu, Oct 14, 2010 at 01:32:14PM +0200, Avi Kivity wrote: > On 10/14/2010 01:28 PM, Gleb Natapov wrote: > >On Thu, Oct 14, 2010 at 01:11:20PM +0200, Avi Kivity wrote: > >> On 10/14/2010 12:29 PM, Gleb Natapov wrote: > >> >On Thu, Oct 14, 2010 at 12:27:15PM +0200, Avi Kivity wrote: > >> >> On 10/10/2010 05:46 PM, Gleb Natapov wrote: > >> >> >> > >> >> >> We should log both errno and exit_reason. If we want to be clever, > >> >> >> we can display strerror(errno) if it's nonzero, and exit_reason > >> >> >> otherwise (easy to do in a trace-cmd plugin). > >> >> >> > >> >> >For starters we should remove KVM_EXIT_INTR exit reason. Looking into > >> >> >qemu-kvm history it was never used and there is at least one code path > >> >> >that returns -EINTR and does not set KVM_EXIT_INTR, so exit_reason field > >> >> >contains stale info on exit. > >> >> > > >> >> > >> >> The two issues are unrelated. > >> >> > >> >So what do you propose? I see no issue with my original patch. > >> > >> Record both errno and exit_reason. While they're never both valid > >> at the same time, they're both necessary. > >> > >If they can't be valid at the same time, why not record one of them? > > If you record just one, you don't know if the other one happened. > I mean to record type/value. So it can be (type error/value -EINVAL) or (type exit/value HALT). The goal is to not print non-relevant info in ftrace, but we can do the same with recording errno and exit_reason and show only exit_reason is errno>=0 or errno otherwise. > >The > >one that happened? Also any error other then -EINTR will cause qemu to > >stop, so it is not very interesting. And ioctl return value can be > >traced by strace anyway. > > You can't correlate it with ftrace. > True. But given that the only interesting error code in -EINTR I do not know if this is useful, but potentially may generate a lot of events in ftrace. Sometimes too much info is almost as bad as not enough and if we will use the same event for both exit_reason and errno it will be impossible to enable one without the other. -- Gleb. -- 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
